Here is a question worth sitting with. When one of your AI agents calls an API, where does the key live?
For most teams the honest answer is: in the agent. In an environment variable, a config file, or a vault the agent can read whenever it likes. One process, holding the keys to a dozen systems, deciding for itself which one to reach for next.
That is a new shape of risk, and the standards world has started work on it. In March 2026 an Internet-Draft appeared at the IETF: Credential Broker for Agents (CB4A), by K. Hartman of the SANS Institute. It is an individual draft, not a standard, and by the IETF’s own rules it should be cited only as work in progress. We are writing about it anyway, because the problem it names is one we keep meeting in real systems, and the shape of the answer looks right.
The problem has a name now: credential sprawl
The draft opens with an incident rather than a theory. It describes a March 2026 supply chain campaign against LiteLLM, an AI gateway used to route requests to model providers. The draft’s account is blunt about why that target was attractive: an AI gateway’s entire job is to hold API keys for dozens of providers, which makes it one of the highest density credential targets in any infrastructure. Per the draft, the attackers shipped a credential stealer through package infrastructure and harvested SSH keys, cloud credentials, model API keys and database passwords from every machine that ran the compromised versions.
We have not independently verified those figures, and we would not repeat them as our own finding. The structural point stands on its own: concentrate long lived credentials in one process, and compromising that process gives away everything at once.
Why agents are not just microservices
The draft is careful to explain why this is not solved by the service to service auth we already have. Four differences, in its words: agents are semi-autonomous and choose which APIs to call, rather than following fixed call patterns. Their compromise vectors are novel, including prompt injection and tool-calling manipulation, which simply do not exist in a traditional service. Their scope is unpredictable, so static scoping is insufficient. And user delegation is implicit: the agent acts for a person who is not present at the moment of action.
That last one is the part we find most interesting. A microservice never has to explain itself. An agent, acting on someone’s behalf while they sleep, probably should.
The idea: the agent never holds the real key
CB4A’s answer is a broker that sits between the agent and the credential vault, and a deliberate split inside that broker. One component decides whether the request is allowed. A different component delivers the credential. The deciding half never touches credentials at all.
The agent’s request is not a bare API call. It is a signed envelope declaring who is asking, what they want to do, to which resource, why, and for how long. The draft is strict about one detail we think is easy to get wrong: the justification text is evidence for forensics, not an input to the decision. The policy engine must not read the agent’s explanation and be persuaded by it. Approval rests on identity, on the requested scope matching policy, on behavioural baseline, and on which approval tier the request lands in. An agent cannot talk its way past the gate by writing a convincing reason.
Approval itself is tiered: automatic in under ten milliseconds for routine requests, a push to a human for riskier ones, and a hardware backed MFA challenge for the most sensitive. The draft explicitly rules out SMS and TOTP for that top tier.
Three ways to hand over a key, and only one good one
The draft sets out three models, and is refreshingly willing to say which are weak.
Model C is the one most teams would reach for first, because it works with anything: hand over the real key, then revoke it afterwards. The draft calls it the weakest model and says plainly that it is not recommended for new integrations. If revocation fails, the key simply stays live. We like a specification that is willing to include the option people will actually be tempted by, and then tell them not to.
The line we keep coming back to
Buried in the bypass prevention section is the sentence that made us sit up:
Relying solely on the agent’s cooperation to use the broker is insufficient; a compromised agent will attempt to call services directly if network-level controls do not prevent it.
That is not an AI insight. That is thirty years of security engineering, arriving in a new place. The draft’s recommendation is to enforce brokering in the infrastructure, not in the agent: network policy that blocks agent to service traffic, service mesh sidecars that validate tokens, DNS that resolves brokered endpoints to the broker. If the agent cannot reach the credential store, it cannot bypass the broker, however cleverly it has been talked into trying.
Anyone who has built a platform knows this instinct. A control that depends on the well behaved component staying well behaved is not a control. It is a convention.
Why this one excites us
Two reasons, and they are both practical.
The first is that we run AI inside our own delivery every day. It writes code and tests, triages security findings across a codebase in a sitting, and drafts the unglamorous artefacts that used to eat a week. Every line it touches is reviewed by a senior engineer before it ships. But the moment any of that tooling needs to reach a real system, the question in this draft becomes our question: what exactly is that process holding, for how long, and who would know if it were taken?
The second is that our day job is joining systems that were never designed to meet. POS to ERP to commerce to loyalty to payments, kept in step, in production, for years. Machine to machine credentials are not a footnote in that work; they are most of the hard part. We already live with the consequences of long lived keys in integration estates that predate anybody’s interest in agents. Watching a standards body take that problem seriously, and start from “the thing acting must not hold the key”, is genuinely good news.
We are optimists about where agentic systems go. This is what the optimism should look like in practice: not slower adoption, but better plumbing underneath it, so the interesting work can be done safely rather than carefully avoided.
The honest caveat
This is an individual Internet-Draft at version zero. It expires in September 2026 unless it is revised. It has not been adopted by a working group, it is not a standard, and parts of it are explicitly sketched for future work. Treat it as a good argument, not a specification to build against.
But arguments are how this always starts. And this one is asking exactly the right question: not how do we give agents access, but how do we give them just enough, for just long enough, with a record of who agreed.
If you are running agents against production systems today and cannot answer where the keys live, that is worth a conversation. It is the sort of problem we like.