There are around twenty specifications for giving an AI agent an identity. Almost none of them are finished. But the serious problem isn’t what’s missing: it’s that the two pieces that do exist — SCIM and SPIFFE — operate on incompatible timescales, and nobody covers the point where they meet. I went out to trace the map against the IETF datatracker and came back with nine corrections.
I’ve spent the last few weeks deep in the agentic identity problem. The starting question looked well-bounded: how do you authenticate and authorise an agent acting as someone’s digital delegate. The usual starting point, in almost any organisation, is SCIM for provisioning and not much else.
The first thing I learned is that the question was in the wrong order.
When you sit down to wire up real connectors — an agent that’s going to read a production table, not a demo — the real order of questions doesn’t start with authentication:
- This agent that’s about to read the table, who answers for it?
- When that person leaves the company, what happens to the agent?
- And only then: how does it authenticate, and what is it allowed to do?
Authentication and authorisation are the third question. The first two are governance, and that’s exactly where the hole is. This article is about why.
A note on method, because on this topic it matters more than usual: everything cited here has been checked against the IETF datatracker, the OpenID Foundation specs and official product documentation, as of 27 August 2026. Internet-Drafts expire every six months, and a document’s real status is half the information. The other half — the nine things that turned out not to be quite as I’d been told — is in a table further down.
The map already exists, and nobody needs to redraw it
The anchor document is draft-klrc-aiagent-auth-03, AI Agent Authentication and Authorization, dated 6 July 2026. Signed by Pieter Kasselman (Defakto Security), Jeff Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI) and Aaron Parecki (Okta).
Worth being precise about what it is and isn’t: it’s an individual draft with intended status Informational. Not a working group document, not on the standards track, binding on nobody. What gives it weight isn’t its formal position, it’s the author list: AWS, OpenAI, Okta, Ping and Zscaler sitting at the same table. It’s the sector’s de facto convergence point, and that’s worth more than a stamp.
It defines a conceptual model called AIMS — Agent Identity Management System — with eight layers: agent identifier, agent credentials, credential provisioning, authentication, authorisation, monitoring and remediation, authentication and authorisation policy, and compliance.
Those eight layers are the useful skeleton. And out of them comes the underlying decision, which I think is right for almost anyone:
There is no need to define a new agentic identity protocol. What is needed is a profile: which specific standard goes in each layer, with which parameters, and where the extension points sit.
We don’t need another protocol. We need decisions. The sector is already producing specifications faster than it implements them.
The non-negotiable principle: delegation, not impersonation
Before the detail, the invariant everything else hangs from.
The agent is never the human. In a well-built token, the agent goes in client_id and the delegating human or system goes in sub. The resource server uses both to decide. The moment you issue a token where the agent impersonates the person, you’ve lost traceability permanently, and no amount of downstream logging gives it back.
The standard piece that represents this is the act (actor) claim from RFC 8693, OAuth 2.0 Token Exchange. And here’s a detail that rarely gets mentioned and matters a lot: the RFC does allow nesting one act inside another to express a delegation chain — “the outermost act claim represents the current actor while nested act claims represent prior actors” — but it also says that for access control only the outermost should be evaluated. The nested ones are informative history, not accumulated authority. If you were planning to enforce policy by reading the whole chain, the standard isn’t with you.
The anchor draft also flags two anti-patterns explicitly, and both deserve to be prohibited by design:
- Static API keys as an agent credential. In the draft’s own words: they’re bearer artefacts that aren’t cryptographically bound, don’t convey identity, are typically long-lived and are operationally difficult to rotate.
- A tool forwarding downstream the token it received from the agent. “It is an anti-pattern for Tools to forward access tokens it received from the Agent to Services or Resources.” Translated into an operating rule: at every boundary you exchange the token for a narrower one, you don’t propagate the same one.
To those two I’d add a third that isn’t in the draft in those words but is the structural defence against prompt injection: the LLM should not have access to credentials, neither its own nor those of the tools it invokes. The strongest formulation available in a primary source is OWASP Top 10 for LLM Applications, LLM01:2025 Prompt Injection: “Provide the application with its own API tokens for extensible functionality, and handle these functions in code rather than providing them to the model.” OWASP doesn’t literally say “never give the model credentials” — it says least privilege and mediation in code — but it admits on the same page that it’s unclear whether fool-proof methods of preventing prompt injection exist at all. When mitigation isn’t reliable, what’s left is reducing the blast radius: make sure the model isn’t holding anything worth stealing.
The standards map, with its real maturity
This is the table that’s actually useful, and the value is in the third column, not the second.
| Layer | Standard | Real status (27 Aug 2026) |
|---|---|---|
| Identifier | WIMSE Workload Identifier | WG draft, rev -03 |
| Credential | WIMSE Workload Credentials | WG draft, rev -02 |
| Transport authN | RFC 8705 (mTLS) | RFC, Standards Track |
| Application authN | WIMSE Proof Token / RFC 9421 | draft -02 / RFC |
| Human→agent delegation | OAuth 2.1 authorization code + PKCE, RFC 9700 | BCP 240 |
| Delegation chain | RFC 8693, act claim | RFC, Standards Track |
| Intra-domain propagation | Transaction Tokens | WG draft, rev -11 |
| Cross-domain | Identity and Authorization Chaining | rev -17, IESG-approved, in RFC Editor Queue |
| Enterprise cross-app | ID-JAG | WG draft, rev -04 |
| Human-in-the-loop | Transaction Authorization Challenge | individual draft, rev -00 |
| Async HITL | CIBA Core 1.0 | Final, Sep 2021 |
| Live revocation | SSF / CAEP / RISC | Final, Sep 2025 |
| Fine-grained authZ | AuthZEN Authorization API 1.0 | Final (COAZ and AARP: WG drafts, Jun 2026) |
| Provisioning | SCIM Agent Resource Extension | individual draft, rev -00 |
| Discovery | RFC 9728 / Client ID Metadata Document | RFC / draft -02 |
Read it for a moment with your eyes half closed. What carries weight today is the RFC column: mTLS, token exchange, HTTP message signatures, protected resource metadata, the OAuth security BCP, and the three final shared-signals specs. Everything else — including the pieces most quoted in agentic identity talks — is a draft. Perfectly healthy drafts, but drafts.
If you’re building today, that column is your real budget.
The two planes, which is what this article is actually about
Here’s the part that took me weeks to see and that reorders everything above.
In classic enterprise, provisioning an identity and giving it credentials are practically the same operation. You create someone in the directory and they can already authenticate. In the agentic world that splits into two planes with incompatible lifecycles:
| Administrative plane | Runtime plane | |
|---|---|---|
| Timescale | Days or months | Minutes or seconds |
| What it holds | Agent registration, human owner, access reviews, deprovisioning | Credential issued after posture evaluation, short-lived |
| Who rules | SCIM | SPIFFE / WIMSE |
| Withdrawal model | Revocation | Continuous rotation |
The line that best captures it I found on a slide presented at the SCIM working group session at IETF 125 (Shenzhen, March 2026), in the deck SCIM Agentic Schema — Draft Consolidation Progress:
“SCIM provisions the right to an identity, not the identity itself; for SPIFFE, the credential is obtained separately.”
Rigour on the attribution, because it matters: that’s a bullet from the presenters’ slides, not a working group conclusion or an IETF consensus. The minutes for that session don’t even record it. But as a formulation of the problem, it’s the best I’ve read.
The seam, and why it breaks exactly there
All the design complexity lives at the point where the two planes touch. And there’s no standard there.
The concrete case: an orchestrator spawns an ephemeral subagent for a subtask. It lives ninety seconds and disappears.
That subagent doesn’t fit in the administrative plane. Nobody is going to create a SCIM record, assign it an owner and put it in the access review cycle for ninety seconds of life. But if it isn’t registered anywhere, it has no owner, and the audit trail breaks exactly where it matters: at the specific action somebody is going to ask who authorised.
And this isn’t a theoretical problem about imaginary latencies. The numbers from SPIFFE/SPIRE — the reference implementation of the runtime plane — give you the measure of the mismatch:
- The SPIRE agent syncs with the server every 5 seconds, and the scaling documentation itself points at the datastore as the biggest bottleneck precisely because of the per-sync authorisation check.
- Default TTLs are one hour for an X.509-SVID and five minutes for a JWT-SVID. There’s no documented minimum TTL and no mechanism designed for second-scale identities.
- Under pathological conditions it stretches much further: there’s an issue in the SPIRE repository — reported against SPIRE Server v1.14.4 and since closed by PR #6994 — documenting newly attested agents not receiving authorised entries for 70-90+ seconds during cache reload spikes, with workloads failing on “no identity issued”. One cited case: node attestation at 09:37:23, X.509-SVID signed at 09:38:54. Ninety-one seconds.
That’s a GitHub issue, not an official figure — spiffe.io doesn’t publish issuance latency percentiles — and under normal conditions agents get their SVID within seconds. But the order of magnitude is what it is: the infrastructure designed to give the runtime plane its identity has, in its worst case, a latency comparable to the entire lifetime of the subject it’s supposed to identify. When that happens, “issue a fresh credential per subagent” stops being a design option.
The SPIFFE project acknowledges it in its own way: its August 2026 roadmap mentions AI agents as motivation for work on transaction tokens and a remote Workload API. Both are twelve-month items, not closed specs. And — a detail that caught my eye — that roadmap doesn’t mention WIMSE or propose convergence with the IETF’s work, beyond linking the transaction tokens draft.
What gets registered, what gets inherited, what gets derived
Since there’s no standard, you have to design. This is the proposal I’d put on the table, and I’m offering it as provisional on purpose: if anyone has a better one, I want it.
The rule rests on a three-way distinction.
You register the orchestrator, not the subagent. The administrative plane only knows long-lived entities. The SCIM draft for agents — individual, revision -00, from June 2026, signed by people at Microsoft, Okta and Nextident — defines an /Agents endpoint with attributes active, displayName, agentUserName, description and, the one that matters here, the multi-valued owners. A detail worth not romanticising: owners is not strictly “the responsible human”. The text allows it to reference a user, a group or another resource. If you want to guarantee there’s a person at the end of the chain, that’s a constraint you impose in your profile, not something the draft gives you.
You inherit the owner, not the credential. The subagent has no administrative identity of its own. It has a derived runtime identity whose token carries the parent orchestrator’s identifier and, unbroken, the original human’s sub. No long-lived credential travels down that chain.
You derive scope, always downward. At each boundary you exchange the token, you don’t forward it. Intra-domain, transaction tokens bound to the transaction with its parameters. Crossing a domain boundary, Identity Chaining with claim minimisation: the authorisation server consumes the full internal context, strips what the other side shouldn’t see, and issues a grant with the minimum. The transaction token never crosses the boundary.
And the field that makes all of this auditable: a correlation identifier that travels from the original human authorisation to the last leaf of the tree. For any given tool call, the audit log has to be able to answer who the authenticated agent is, what the delegated subject is, which resource, which action, which decision, when, with what posture state and under what correlation. Miss that last field and you have six correct fields and no story.
A note on chain depth, since it’s the question everyone asks next: with the standards in the table you cannot enforce a max_depth without inventing something. RFC 8693 lets you nest act for the record, but tells you to evaluate only the outermost. Counting hops and rejecting the fourth is your own extension. It can be done — an additional claim in the transaction token, verified by the authorisation server at every exchange — but it has to be written down as a declared extension, not smuggled in as if it were standard.
The question that decides your architecture before any other
Everything above assumes your authorisation server can represent a delegation chain. It’s worth checking before you draw anything, because the answer changes the whole design.
Two concrete yes/no questions, per platform:
- Does it support full RFC 8693, including the nested
actclaim? Without that there’s no representable delegation chain. - Does it support RAR (RFC 9396, the
authorization_detailsparameter)? Without that there’s no transactional authorisation, because a scope doesn’t describe an operation with its parameters: “transfer” is not the same as “transfer €4,000 to this account”.
I went to the official documentation to look. Here’s what I found:
RFC 8693 with nested act | RAR (authorization_details) | |
|---|---|---|
| Amazon Cognito (IdP option in Bedrock AgentCore) | No. The token endpoint accepts only authorization_code, refresh_token and client_credentials; any other grant_type returns unsupported_grant_type | Not documented |
| Microsoft Entra ID | No. Delegation runs through On-Behalf-Of, which uses grant_type=jwt-bearer, not token-exchange. No mention of RFC 8693 or act | Not documented |
| Okta | Yes. Supports grant_type=token-exchange, and its agent guide explicitly documents the act claim as a delegation chain across multiple agents | Not documented |
Cognito’s “no” is the strongest of the three because it’s explicit: the grant list is closed in the documentation. So much so that AWS publishes a sample implementing token exchange outside Cognito, with API Gateway and Lambda. The other two are evidence by absence in official docs, which is weaker, but it’s the evidence available.
Watch out for one very easy confusion: the Entra Agent ID documentation does use the phrase “token exchange” when talking about federated identity credentials. That’s generic terminology, not RFC 8693. They aren’t the same thing, and mixing them gets you an architecture that doesn’t compile.
The practical consequence: if your authorisation server can’t issue nested act, the delegation chain isn’t represented in the token, and then either you maintain it in a parallel plane — with everything that implies about a proprietary system you’ll have to defend to an auditor — or you don’t have it.
What I found when I traced the map
This is my favourite section to write, because it’s the one that pays best. I started from a well-made working document, with all its references, and went to check them one by one. Nine didn’t hold up as written. None is a serious error; they’re all the same kind of error, which is the expensive kind: the claim is almost true, and the missing nuance is exactly the one that decides.
| What the source document said | What I found when I traced it |
|---|---|
| Identity Chaining “is already Proposed Standard” | Qualify. Revision -17, IESG-approved and in the RFC Editor Queue. “Proposed Standard” is the intended status; it still has no RFC number. The safe wording is “approved, pending publication” |
| WIMSE defines X.509-SVID and JWT-SVID | False. SVIDs are SPIFFE artefacts. WIMSE defines the WIT (Workload Identity Token, a signed JWT binding a public key to the workload identity) and the WIC (Workload Identity Certificate, X.509). The draft itself says the WIC is “fully compatible with the X509-SVID” — compatible, not the same |
| The WIMSE ID is based on the SPIFFE ID | Inverted. WIMSE defines its own wimse:// scheme and accepts spiffe:// as one valid scheme among others |
| The MCP spec hardened OAuth with six SEPs | Qualify. The current version is 2026-07-28 and brings three authorisation SEPs (SEP-2468, SEP-837, SEP-2352) plus the deprecation of DCR via a PR. The other big changes in that revision are about statelessness and transport |
| NIST flags multi-hop A→B→C delegation as an open question | Qualify. The document is an NCCoE concept paper from February 2026, with no publication number. It asks about “on behalf of” delegation generically and about binding agent identity to human identity. The three-hop chain isn’t in the text |
| The Transaction Authorization Challenge draft notes CIBA fits poorly | Unsupported. That draft (rev -00, June 2026) doesn’t mention CIBA anywhere. The only thing it explicitly compares itself to is step-up authentication. The CIBA argument stands on its own — initiation is always by the client, it’s in the name of the flow — but it’s your own analysis, not a citation |
| AgentCore Identity is built on Cognito | No documentary support. Official docs present Cognito as one IdP option among several, alongside Auth0 and others. The word “default” doesn’t appear |
| Entra Agent ID GA since April 2026 | Correct to May. The official “what’s new” declares it generally available, with a page date of 1 May 2026. And parts remain labelled (Preview) after GA, such as creating blueprints or agent identities from the admin center |
| Okta ships Cross App Access in the core at no extra cost | Sources conflict. The 24 August 2026 press release says so; the admin documentation marks it Early Access, “Contact Okta Support for details”. Three days’ difference might explain it, but today the docs don’t back the announcement |
One cross-cutting observation, because it’s the most useful error pattern to know: in six of the nine cases the number or name was right and what had changed was the subject or the status. “Approved” for “published”. “Compatible with” for “is”. “One option” for “the foundation”. It’s exactly the same failure mode I found the last time I traced the figures in a whitepaper: the data doesn’t get invented, the subject gets swapped along the way.
The small print
Four uncomfortable things I don’t want to gloss over.
Aggregate maturity is lower than the conference talks suggest. The anchor document is an individual Informational draft. The SCIM agent draft is individual, revision -00. The Transaction Authorization Challenge is individual, revision -00. COAZ and AARP — the AuthZEN profiles for, respectively, mapping MCP tool authorisation and handling up-front access requests and approvals — were approved as working group drafts in June 2026, the lowest maturity rung at the OpenID Foundation; the foundation itself says they still have to go through Implementer’s Draft before aspiring to a final version. Betting architecture on that today is a legitimate decision, but you should take it knowing what you’re betting.
Holder-side attenuation doesn’t exist in this family. A JWT is immutable once signed. A delegate can’t narrow its own scope without minting a new token, and minting one breaks the chain. Technology that does solve it exists — Biscuit tokens, with offline attenuation over Ed25519 signatures, conceptual heirs of Google’s Macaroons (NDSS 2014) — but Biscuit is a small project under the Eclipse Foundation, spec v3.3, with one well-known reference deployment. It’s an excellent idea and a very different infrastructure bet from adopting an RFC.
MCP doesn’t cover agent identity, and says so. The current specification defines its authorisation explicitly at the transport level, with the classic OAuth model of client, resource server and authorisation server, and adds that the implementation details of the authorisation server are beyond scope. Agent identity, per-request authorisation, delegation provenance and audit aren’t there. It’s not an oversight: the 22 August 2026 roadmap admits it in as many words — “MCP authorization today is built around a person approving access in a browser… but more and more of the callers are agents running as cloud workloads with their own identity” — and places the work in the future.
And the European regulatory gap, which makes the least noise and will hurt the most. I went to check whether eIDAS 2.0 and the EUDI Wallet treat an agent as a first-class principal. They don’t. The November 2024 implementing regulations don’t recognise the figure; the Architecture and Reference Framework v2.4.0 doesn’t mention “AI agent”, “autonomous agent” or “software agent” anywhere, and in fact assumes the opposite — that the user’s device is personal and not shared; and ENISA’s March 2026 candidate certification scheme doesn’t either. The Commission’s Apply AI Strategy talks about agents but never connects them to digital identity or the wallet. There are third-party and consortium proposals; Commission documents, no. For anyone deploying in Europe, that’s a risk you can’t close today, only register.
What I’d do on Monday
Four things, in order of return.
- Locate every secret and check whether any of them enters the model’s context. System prompt, tool description, tool result, trace log. It’s the cheapest audit there is and the most critical possible finding. If a key travels in context, every other conversation about identity is premature.
- Check nested
actand RAR on your authorisation server before you draw the architecture. Yes or no, with the documentation in front of you. That answer conditions everything else and it’s half an hour of work. - Write the profile, layer by layer, with each standard’s real status next to it. Eight layers, eight explicit decisions, none blank. And a column saying whether what you picked is an RFC, a working group draft or an individual draft, because in six months someone is going to ask why you chose it.
- Design the seam, even provisionally. What gets registered, what gets inherited, what gets derived, and the correlation identifier that runs the length of the chain. It’s the first thing an auditor will look at and the only item on this list no standard will give you.
What I’m taking away
I went out looking for which protocol to adopt and came back with a different conclusion: the agentic identity problem isn’t neglected, it’s fragmented. There’s more specification than anyone is implementing, and the missing work isn’t inventing another one — it’s deciding which goes where and writing it down.
But the part no standard in the table solves, and none of the three big platforms either, is the seam between the plane that governs and the plane that executes. An agent that lives ninety seconds doesn’t fit in a quarterly access review cycle, and yet somebody has to answer for what it did. That isn’t a library wrapping OAuth and managing token lifecycles — that already exists, and it’ll increasingly live inside the providers’ SDKs. It’s an architectural decision about what gets registered, what gets inherited and what gets derived.
Which brings it back to the first question, the one that was in the wrong order at the start: who answers for this agent? It turns out it wasn’t a governance question you answer at the end. It was the one that fixes the design.
Ideas over code; evidence over hype.
Sources
- Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N. and Parecki, A. (6 Jul 2026). AI Agent Authentication and Authorization —
draft-klrc-aiagent-auth-03, IETF, individual draft, Informational - IETF OAuth WG. OAuth Identity and Authorization Chaining Across Domains (rev -17, RFC Editor Queue) · Transaction Tokens (rev -11) · Identity Assertion JWT Authorization Grant (rev -04) · OAuth Transaction Authorization Challenge (rev -00)
- IETF WIMSE WG. Charter · Workload Identifier (rev -03) · Workload Credentials (rev -02) · Workload Proof Token (rev -02)
- Wahl, M., Zollner, D., Dingle, P. and Kazzouzi, I. (5 Jun 2026). AI Agent Resource Extension for SCIM —
draft-wzdk-scim-agent-resource-00 - IETF 125 (Shenzhen, March 2026), SCIM WG session. SCIM Agentic Schema — Draft Consolidation Progress — presenters’ slides
- RFCs: 8693 Token Exchange · 9396 Rich Authorization Requests · 8705 mTLS · 9421 HTTP Message Signatures · 9728 Protected Resource Metadata · 9700 OAuth Security BCP
- OpenID Foundation. Three final Shared Signals specs: SSF, CAEP and RISC (Sep 2025) · CIBA Core 1.0 (final, Sep 2021) · New AuthZEN WG drafts: AARP and COAZ (Jun 2026)
- SPIFFE. Scaling SPIRE · Server configuration · Issue #6876 on issuance latency (closed, fixed in PR #6994) · Roadmap, Aug 2026
- Model Context Protocol. Specification 2026-07-28 · Changelog · Roadmap, 22 Aug 2026
- NCCoE / NIST (Feb 2026). Accelerating the Adoption of Software and AI Agent Identity and Authorization — concept paper
- OWASP Gen AI Security Project. LLM01:2025 Prompt Injection
- Platform documentation: Cognito token endpoint · AgentCore identity providers · Entra Agent ID what’s new and service principals · Okta AI agent token exchange · Okta Cross App Access
- McGuinness, K. (17 Mar 2026). The Mission Shaping Problem — Control Plane blog
- Biscuit (Eclipse Foundation, spec v3.3) · Birgisson, A. et al. (2014). Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud — NDSS
- EUDI Wallet. Architecture and Reference Framework v2.4.0 · Commission Implementing Regulation (EU) 2024/2979
Leave a Reply