Dora NodaA deploy-from-chat request just hit your MCP server: roll back production to the previous release. The call came from a deploy sub-agent, which was spawned by an orchestrator agent, which was acting on a human's chat message three hops ago. Your server has to answer two questions before it touches anything: which agent is calling, and under whose authority is it acting? Most MCP servers today can barely answer the first — and the second is usually a static API key that proves nothing about either.
In March 2026, engineers from Defakto, AWS, Zscaler, and Ping Identity published an IETF Internet-Draft, draft-klrc-aiagent-auth, that gives this problem a name and a shape: the Agent Identity Management System (AIMS). Now at revision -03 and presented to the WIMSE working group at IETF 126 in Vienna in July 2026, with contributors from OpenAI and Okta joining along the way, its core move is restraint. It invents no new protocol. Instead it composes three existing standards — a WIMSE identifier as the agent's single stable identity, SPIFFE/SPIRE as the mature machinery for issuing short-lived credentials bound to that identity, and OAuth 2.0 as the delegation framework that carries a human's authority through a multi-hop agent call.
Here is the full borrow list up front — what each AIMS piece concretely changes on a deploy/rollback MCP server — with the worked delegation trace and the honest gaps further down.
| AIMS concept | What the MCP server borrows |
|---|---|
| Exactly-one WIMSE identifier per agent | Require one stable URI identity per calling agent; log and audit on it |
| Short-lived SPIFFE/SPIRE credentials | Accept auto-rotated SVIDs or WITs; reject static API keys outright |
| Transport + application authentication | mTLS where the channel is end-to-end; proof tokens or message signatures past any TLS-terminating proxy |
| OAuth 2.0 delegated authorization | Agent identity in client_id, human principal in sub; narrow scope at every hop via token exchange |
| Transaction tokens, no token forwarding | Exchange broad access tokens for transaction-bound tokens; never pass a received token downstream |
Why agents break the old auth model
Enterprise access control was built for humans plus service accounts, and both halves fail agents in different ways. OAuth scopes authorize broad categories of actions, not "this agent may touch exactly this deployment, for the next ten minutes, on behalf of this named human." Service accounts are worse: credential-holding entities with no persistent binding to a human principal, whose permissions accrete over time as teams add scopes and never remove them. When an AI agent inherits a service account or an API key, it inherits the over-broad access and the missing attribution together.
AIMS says the quiet part in normative language: "Static API keys are an antipattern for agent identity. They are bearer tokens that are not cryptographically bound, do not convey identity, are typically long-lived and are operationally difficult to rotate." That sentence alone is worth adopting as policy, because the failure mode is not theoretical. In April 2026, CVE-2026-20205 disclosed that a Splunk MCP server was logging session and authorization tokens in plaintext to internal indexes, where any admin-level user could harvest and replay them. Long-lived bearer tokens that can be copied out of a log file are exactly the credential shape AIMS wants gone: short-lived, cryptographically bound, auto-rotated credentials shrink both the theft window and the blast radius when theft happens anyway.
SpruceID put the deeper point sharply in September 2026: agents have an authorization problem, not just an identity problem. Proving which agent is calling answers provenance. It says nothing about permission — what the agent is allowed to do, for whom, for how long. A deploy MCP server needs both answers on every tool call, and it needs them in machine-readable form, not as a judgment call in a policy file.
The composition, layer by layer
AIMS is a conceptual model, not a product: eight components in a stack — identifier, credentials, provisioning, authentication, authorization, observability and remediation, policy, compliance — where each layer depends on the guarantees of the ones below it. The three standards it composes each own specific layers, and the division of labor is the whole insight.
WIMSE supplies the identifier. Every agent gets exactly one WIMSE identifier: a URI that names the workload within a trust domain and stays stable for the lifetime of that identity, because authorization decisions, delegation semantics, and audit records all key off it. A SPIFFE ID (spiffe://trust-domain/path) is explicitly called out as the widely deployed, operationally mature instance of this model. One agent, one URI, no aliases — that constraint is what makes the audit trail later joinable.
SPIFFE/SPIRE supplies the credentials and provisioning. An identifier alone proves nothing; the agent needs a cryptographic binding between the URI and key material it controls. WIMSE defines two credential formats (the Workload Identity Token and the X.509 Workload Identity Certificate); SPIFFE defines three (X.509-SVID, WIT-SVID, JWT-SVID), with the X.509-SVID compatible with the WIMSE certificate. The operational properties matter more than the menu: credentials must be short-lived with explicit expiry, and SPIRE's attested issuance plus automatic rotation — one-hour default TTLs renewed in the background over the Workload API, no human in the loop — is why the draft treats SPIFFE as the "how this actually runs" answer rather than a second competing standard.
OAuth 2.0 supplies delegation. This is the layer bare workload identity never had. The agent acts as an OAuth client and obtains access tokens in three patterns: a user delegates via the authorization-code grant (with phishing-resistant authentication like passkeys recommended); the agent gets its own token via client credentials or a JWT grant; or a system or another agent invokes an agent-as-resource. The token's claims carry the two answers the MCP server needs: the agent's identity goes in client_id, and the human or system on whose behalf it acts goes in sub. Down the chain, RFC 8693 token exchange and transaction tokens narrow authority at each hop — a downscoped token bound to one transaction that cannot be replayed against another transaction or with modified parameters.
Two more AIMS details deserve attention from anyone running tools. First, authentication happens at two layers — mTLS at the transport layer, proof tokens or HTTP message signatures at the application layer — precisely because TLS-terminating intermediaries (proxies, gateways, load balancers) break end-to-end transport identity. If your MCP server sits behind anything that terminates TLS, transport identity alone cannot bind the request to the credential.
Second, the draft names another antipattern alongside static keys: tools forwarding a received access token downstream to services. Exchange it or transaction-scope it; never pass it along.
The delegation chain, worked end to end
Take the rollback request from the opening: a human types "roll back production" in chat. An orchestrator agent plans the work, a deploy sub-agent executes it, and the MCP server's rollback tool touches production.
Three hops, and at each one the two questions need fresh answers.
Hop one, human to orchestrator, is a standard user-delegation grant: the authorization-code flow, ideally with a passkey, producing an access token with the orchestrator's identity in client_id and the human in sub. Hop two, orchestrator to deploy sub-agent, is where naive designs just forward that token — and where AIMS says to exchange it instead. The orchestrator uses token exchange to mint a narrower token for the sub-agent: same human in sub, so the authority's origin is preserved, but a scope reduced to "execute this rollback plan" and an audience restricted to the deploy agent. Hop three, sub-agent to the MCP tool, narrows once more: the sub-agent exchanges for a transaction token bound to this specific rollback — this service, this target revision, this transaction ID — so that even a leaked token cannot be replayed against a different deployment or with different parameters.
Notice what this buys the MCP server at the moment of the tool call. It does not merely see "a valid token." It sees which agent is invoking (client_id), whose authority it spends (sub), how much authority the token carries (a scope narrowed twice, not the human's full grant), and which transaction it is bound to.
And the audit record writes itself: one stable identifier per agent, one human principal per chain, one transaction ID per production touch. Compare that with the status quo — a shared service-account key where the log line says only that someone called rollback — and the gap between "authenticated" and "accountable" becomes obvious.
This is also the question bare SPIFFE identity cannot answer on its own. SPIFFE proves the workload is who it claims to be, with excellent machinery for issuance and rotation. But "this is deploy-agent-7" is not "deploy-agent-7 acts for on-call engineer Maya under grant G." The composition is the point: SPIFFE answers the first question with operational maturity, OAuth answers the second with delegation semantics, and WIMSE gives both a single stable identifier to hang from.
The borrow checklist for a deploy-from-chat MCP server
Distilled to server-side rules, each traceable to a section of the draft:
- Require exactly one identifier per calling agent. Accept the WIMSE URI (a SPIFFE ID in practice), key all authz decisions and audit records off it, and reject anonymous or multi-identity callers. This is the join key for everything below.
- Accept short-lived credentials; reject static keys. Take X.509-SVIDs or WITs with explicit expiries, validate them against the trust bundle, and refuse long-lived bearer tokens at the tool boundary. The Splunk CVE is your incident-review slide for why.
- Enforce the
client_id/subsplit. Every production-touching tool call must present both who is calling and on whose behalf. A token with an agent identity but no human principal is not authorized to spend human authority. - Never forward access tokens downstream. If your tool implementation fans out to internal services, exchange for transaction tokens first. Forwarding the received token widens the theft surface to every log file and crash dump in the chain.
- Bind user-approval prompts to real OAuth grants. MCP-style elicitation — pausing to ask the user "approve this rollback?" — is a UI event, not an authorization. AIMS is explicit: translate the confirmation into an OAuth authorization event (step-up via CIBA is the suggested shape) before touching the resource, and never treat a local click as sufficient authorization on its own.
None of this requires waiting for the draft to become an RFC. SPIRE runs today, OAuth authorization servers are commodities, and token-exchange libraries exist in every major stack — Red Hat's June 2026 Kagenti demo already wires SPIFFE identity together with token exchange in exactly this two-layer shape. What AIMS contributes is the composition contract: which standard answers which question, so implementations stop improvising incompatible answers.
What AIMS still doesn't settle
Adopting the composition does not mean the work is done, and the honest gaps should shape what a self-hosted operator builds around it.
| Gap | Status | Interim operator default |
|---|---|---|
| No mandated token format | Deliberate: JWT and opaque-with-introspection both supported | Pick JWT access tokens so the MCP server validates locally without an introspection round trip |
| Multi-hop delegation semantics are thin | The companion dual-identity draft covers two parties, not A-to-B-to-C chains | Cap delegation depth (three hops is plenty for deploy flows), and log the full chain for audit |
| Mid-execution user confirmation | The draft itself flags that CIBA only models client initiation, not mid-task approval | Bind elicitation approvals to fresh short-lived grants; re-confirm when scope widens mid-execution |
| Mission-to-scope translation | Explicitly out of scope: turning "roll back production" into a scope request is the agent framework's job | Constrain tool scopes server-side so an over-broad agent request still lands on least privilege |
The pattern across all four rows is the same: where the standards are still converging, push the enforcement point as close to the production touch as possible — the MCP server's own tool boundary — rather than trusting the agent chain to have gotten it right three hops upstream.
Identity is table stakes; delegated authority is the product
The trajectory here is clear. Workload identity for agents is converging fast: WIMSE standardizes the identifier shape, SPIFFE/SPIRE is the running code, and OWASP's agent-security guidance already points implementations at the AIMS composition for both orchestration identity and MCP authentication. Within a year, "which agent is calling" will be a solved problem with boring, interoperable answers — and the servers still authenticating agents with static keys will look the way password-in-URL endpoints look today.
The differentiator is the second question. A deploy-from-chat MCP server that can show, per tool call, which agent acted, whose authority it spent, how that authority narrowed at each hop, and which transaction bound it — that server can offer tenants something no shared-key design can: an audit trail a compliance team will actually accept for production changes made by agents. Borrow the composition now, enforce it at the tool boundary, and let the unfinished standards converge underneath you.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent-operated deploys need agent-grade identity, and AIMS is the shape of it. Star the repo on GitHub or deploy your first app today.
