secret-guard

name

secret-guard

description

Lets an agent authenticate to APIs and MCP servers WITHOUT ever seeing secret values. Use whenever a task needs an API token, MCP token, password, or key. The agent passes a credential *reference* (a name); a trusted non-LLM broker resolves it from the OS keyring, injects it into the request, scrubs the response, and returns only scrubbed output. The secret value never enters the agent's context or the LLM.

Secret Guard

Core Principle

You never possess a secret value. You only pass references (names).

A secret must never enter the model's context window. Do not read secret files, do not print values, do not reconstruct them. To authenticate, you emit a credential reference by name and let a trusted, non-LLM broker resolve→inject→scrub. This is architectural, not advisory: the value stays inside the broker process and is never returned to you.

Secrets live in the OS keyring (Keychain / libsecret / Windows Credential Manager). They are stored out-of-band by a human, e.g.:

keyring set agent-secrets github_token
keyring set agent-secrets openai_api_key

You reference them by name only — e.g. github_token. You never see the value.

---

Mechanism (a): Resolve-and-Inject — PRIMARY

Use this for all API and MCP token use. The broker resolves the named credential, injects it into the request header, performs the call, scrubs the response, and returns only the scrubbed body. The secret exists only inside the broker process for the duration of one request.

python3 scripts/keyring_broker.py request \
    --name github_token \
    --url https://api.github.com/user \
    --header "Authorization: Bearer {secret}"

• --name is a reference, never a value.
• {secret} is a placeholder the broker fills internally; you never type the token.