Credential brokering for AI agents, without running a vault
Patterns
Credential brokering is the practice of never letting a workload hold a credential it uses. The workload holds a placeholder; something else substitutes the real value at the network boundary, checks that the request is allowed, and records that it happened.
The pattern predates agents — it's a close cousin of tokenization in payments — but agents are what made it urgent. A conventional service that holds an API key uses it the way you told it to. An agent that holds an API key uses it the way it was persuaded to, and the persuasion arrives in the same channel as the work.
This post is about what a broker actually has to do, and about the question most comparisons skip: not whether to broker, but who holds the plaintext behind the broker.
The shape
The 2026 Internet-Draft Credential Broker for Agents (CB4A) gives the pattern a vocabulary: a policy decision point that decides whether a request is allowed, and a credential delivery point that attaches the secret, kept separate from each other and from the agent. (It's an individual submission, not an IETF work product — but it's the clearest write-up, and it named the thing.)
In practice, for most people, it looks like this:
agent ──▶ Authorization: Bearer {{seekrit:STRIPE_KEY}}
│
broker ── is this secret allowed toward this host,
│ by this method, on this path?
▼
api.stripe.com Authorization: Bearer sk_live_…
Two ways to wire it up, and the choice matters more than it looks:
Forward proxy. Set HTTPS_PROXY and the agent's HTTP client routes
everything through the broker. It terminates TLS with a locally generated CA and
mints per-host certificates on the fly. Transparent — the agent's code is
unchanged — but it means the broker sees every request the agent makes, and you
have to trust a CA on that machine.
Reverse proxy. Point the agent at a base URL you control and let the broker forward upstream. Nothing to intercept and no CA, but you configure it per service, and an agent that constructs its own URLs can route around it.
Neither is strictly better. The forward proxy is stronger for a workload you don't control; the reverse proxy is simpler and has a smaller trust footprint when you know the handful of APIs in play.
Four properties, or it isn't a broker
A proxy that swaps in any secret for any request is not a security control — it's an exfiltration oracle with good ergonomics. The agent asks it to resolve a placeholder toward a host the attacker owns, and it obliges.
Default-deny per upstream. Each route names which secrets may be injected toward which host. Anything else is refused, not forwarded. This is the property that turns a convenience into a control, and it's the one worth checking first in any implementation you're evaluating.
Operation-level bounds. api.github.com is one host and a hundred different
authorities. If your rules stop at the hostname, an agent allowed to read issues
can delete a branch with the same credential. Bounding methods and paths is what
makes "scoped access" mean anything at the broker layer.
Fail closed. Resolve and decrypt at startup. Bad token, unreachable vault, a value that won't decrypt — refuse to start. A broker that boots degraded and forwards unsubstituted placeholders has failed at the only moment that mattered, and it will do it quietly.
Audit by name, never by value. Record which secret went to which host, with what method, when. Never record what it was. A credential broker with verbose request logging is a credential warehouse with extra steps.
The question underneath: who holds the plaintext?
Here is where most of the discussion stops too early. A broker keeps the credential away from your agent. It says nothing about who else can read it.
Every broker resolves its placeholders from somewhere. That somewhere is a secrets store, and the store has an architecture:
- Your own file or database. Total custody, and now you're running a secrets store: backups, rotation, access control, an encryption key that lives somewhere, and a 3am page when it's down.
- A managed store that holds your keys. Most of the market. Good security engineering, real operational maturity — and the vendor is technically able to decrypt your secrets, whatever their policies say about not doing so.
- A zero-knowledge store. Encryption happens on your side before anything is uploaded; the server holds ciphertext it has no key for. The vendor cannot read your secrets because there is nothing there to read.
If your reason for adopting a broker is "a system that holds this credential will eventually leak it," then the third option is the only one that applies the same reasoning consistently. Otherwise you have moved the plaintext from a system you don't fully trust to a different system you don't fully trust, and declared the problem solved.
That's the argument for the shape seekrit takes: you run the broker, and the vault behind it can't read your secrets either. The proxy is a small binary on your machine or beside your workload. The values it resolves were encrypted in your browser or CLI before they were ever stored, so a full dump of our database reveals nothing.
It extends to the rules, too. Egress policy is signed client-side and verified against signers pinned in the proxy's own config, so we can't rewrite where your credentials are allowed to go. A service that could quietly redirect your plaintext has the same authority as one that can read it.
Without running a vault
The "without running a vault" part is the practical half. Self-hosting a secrets store is a real answer, and it is not a free one — you inherit an availability requirement on the thing every deployment blocks on, plus key management, plus the backup story you'll discover you didn't have.
The alternative used to require trusting a vendor with plaintext. It doesn't anymore. Zero-knowledge means the hosted option and the custody option stop being opposites: someone else runs the uptime, and nobody but you can read the values.
To try the broker half:
npx -y @seekrit/cli proxy run --preset openai
That resolves your environment, starts a proxy with a default-deny allowlist, and substitutes placeholders on the way out. The guide covers both modes, and agent access policy covers the signed bundles.
If you'd rather self-host the whole thing, Infisical's agent-vault is MIT-licensed and does the brokering half well. The pattern is more important than the implementation. Just check those four properties before you trust one, and then ask the question underneath: after the broker, who can still read the key?