What is a credential broker for AI agents (and why you need one)
There’s a new category of security tooling appearing alongside AI coding agents, and it doesn’t have a great name yet: the credential broker. It solves a problem that didn’t exist before agents — and it’s worth knowing what it is before you need it.
The problem agents created
Traditional secret management assumed a trusted process reads a secret and uses it. Agents break that assumption in two ways:
They read everything. Claude Code, OpenCode, Codex load
.envfiles, config, and environment variables — because that’s how tools get credentials. Whatever they read enters the context window, which gets summarized and sent to third-party model APIs.They spawn everything. Every subprocess an agent runs inherits its environment. A build script that echoes
DATABASE_URLisn’t a bug — it’s Tuesday.
The result: the standard “give the process a secret” model now delivers secrets into the most exposed software on your machine.
What a credential broker does
A credential broker sits between the agent and its credentials. The agent references a secret by name; the broker resolves the actual value at the moment and layer where it’s needed:
| Layer | Mechanism | What the agent sees |
|---|---|---|
| Process | Inject secret into subprocess env, scrub stdout/stderr | The API response — never the key |
| Transport | Local proxy injects per-host headers/query | A normal HTTP proxy |
| Egress | DLP scan masks secret patterns in outbound requests | Masked traffic |
| Storage | Retroactive scrubbing of session DBs and logs | Erased history |
The defining property: the agent never holds plaintext. It can use the credential, but it cannot read, copy, or leak it — because it was never given the value.
Why existing tools aren’t enough
Password managers store secrets but don’t inject them safely into agent subprocesses — they hand the value to whoever asks. Vault-style tools introduce a new server, a new secret format, and a migration. Most “agent-secret” tools solve only one slice (usually process injection) and leave the context window, the transport layer, and the logs unprotected.
A broker ties the slices together: existing store as the backend (pass or Bitwarden — no migration), injection and sanitization at the process layer, DLP on outbound traffic, and retroactive erasure for what already leaked.
Do you need one?
If your agent only calls one model API with a key that never changes and you never paste untrusted text, maybe not. If you have multiple services, keys that rotate, OAuth tokens, or an agent that reads the internet — the question isn’t whether a key will end up in context, but when.
trustless is a zero-dependency
implementation of this pattern — one Go binary, 321 tests with -race,
cosign-signed releases with SBOM, reading your existing pass or Bitwarden
store. The architecture docs explain how the layers
fit together.
The mental model worth adopting: your agent is an untrusted caller with legitimate access needs. Treat it like a contractor — give it access, never the keys.