There is no adopted standard for AI agent identity. As of August 2026, every AI-agent identity draft at the IETF is an individual submission with no formal standing, two of the four most-cited ones have already expired, and no working group has adopted any of them. What actually ships today is a claim defined in 2020 and whatever naming discipline you impose yourself. Here is the honest inventory, and the pattern worth building now.
What identity does your AI agent actually have today?
In almost every small-business agent deployment we look at, the answer is: your identity, or a shared one.
The agent runs in n8n, Make or a small custom service. It reaches Exact Online, AFAS or e-Boekhouden through a single API key or one integration user created when the workflow was first built. The agent does not have an identity. It borrows one, and it borrows the whole of it.
Three things follow, and only the third is usually a surprise.
The first is blast radius. The agent can do everything that credential can do, not just the two things the workflow needs. The second is revocation granularity: when something goes wrong, the only lever is to disable the credential, which stops every workflow using it. Both are familiar problems and both have familiar answers.
The third is attribution, and it is the one that bites. Your ERP's audit log records that integration user, or worse, the human whose key was reused. Six months later somebody asks whether a credit note was approved by a person or generated by a model running unattended, and the log cannot tell them. That question is never asked in advance. It is asked after an incident, when the logs are already written. We covered the adjacent attack surface in the threat model most SMEs miss; this is the accounting problem underneath it.
Which AI agent identity standards actually exist in 2026?
This is where most write-ups go wrong, because a long list of draft names reads like a converging standard. It is not one. Checked against the IETF Datatracker this week:
- **No `draft-ietf-oauth-*` document concerns AI agents.** The OAuth working group's document list contains no adopted agent identity work at all. The two drafts most often cited as agent standards, `identity-chaining` (now in the RFC Editor queue as a Proposed Standard, no RFC number assigned) and `transaction-tokens-11`, are genuinely adopted, but neither is agent-specific. They solve cross-domain token exchange and call-chain context, and they would exist without AI.
- WIMSE is a real working group that is not doing this. Workload Identity in Multi System Environments is active, its charter was approved in March 2026, it has six working group drafts plus one at the IESG, and it has published zero RFCs. Its charter defines a workload as "a running instance of software executing for a specific purpose" and never uses the words "AI" or "agent". A draft called "WIMSE Applicability for AI Agents" exists, but it is an individual submission. At the June 2026 interim the chair recorded that this was "not a call for adoption yet".
- `agentproto` is a BOF, not a working group. It held a WG-forming session at IETF 126 in Vienna in July 2026 and is not chartered.
Datatracker states the position plainly on every one of these individual drafts: not endorsed by the IETF, no formal standing.
Why did two of the four OAuth agent drafts expire?
Four documents get cited as the emerging agent authorisation stack. Their actual status, verified this week:
- On-Behalf-Of User Authorization for AI Agents (Senarath and Dissanayaka, WSO2). Adds a `requested_actor` parameter at the authorisation endpoint and an `actor_token` at the token endpoint, so the consent screen can name the agent. Published August 2025, expired February 2026.
- Agent Authorization Profile (AAP). Structured claims for agent identity, task context and human oversight, layered on OAuth 2.0 and JWT. Expired.
- OAuth Actor Profile for Delegation (Karl McGuinness). Active, revised April 2026, expires November 2026. Profiles the existing `act` claim into a consistent shape across JWT grants, access tokens and transaction tokens. It explicitly does not standardise the policy for deciding whether an actor may act for a subject.
- Attenuating Authorization Tokens (Niyikiza, Tenuo). Active, revised June 2026, expires December 2026, Standards Track intent. A signed token encodes which tools an agent may invoke and with what argument constraints, and a holder can derive a narrower token offline. The chain verifies against the root trust anchor with no network call.
Internet-Drafts expire after six months as a matter of routine, so expiry alone is not failure. Two expiring with no working group picking them up is the signal: nobody is driving convergence.
More useful than the status is what the split tells you. These documents are not four attempts at the same thing. The first two answer who is acting for whom, which is an identity and consent question. The fourth answers what this agent may call, with which arguments, which is a capability question. The AAT draft says so itself: approaches built on `requested_actor` "do not constrain which tools the agent may invoke or with what argument values", and it positions itself as complementary rather than competing.
Underneath sits a real architectural disagreement. RFC 8693 token exchange requires a synchronous round trip to the authorisation server at every delegation hop, which makes that server a participant in every hop and couples your agent topology to its availability. Offline attenuation removes that coupling and gives up central mediation in exchange. If you are designing a multi-agent system now, that trade-off is the decision you actually have to make. The token format is the part that will change.
Does MCP solve agent identity?
No, and it does not try to.
In the current 2026-07-28 specification, authorization is OPTIONAL. Where it is used, the MCP server acts as an OAuth 2.1 resource server and the client as an OAuth 2.1 client making requests on behalf of a resource owner. Servers MUST implement RFC 9728 Protected Resource Metadata, clients MUST send an RFC 8707 resource indicator whether or not the authorisation server supports it, and PKCE is required.
The July release tightened that layer rather than extending it: RFC 9207 issuer validation to close an authorisation-server mix-up, client credentials bound to the issuer that minted them, and Dynamic Client Registration formally deprecated in favour of Client ID Metadata Documents. Migration detail is in our note on what breaks in 2026-07-28.
RFC 8693 is not cited in the core specification at all. Delegation appears only in an opt-in extension, Enterprise-Managed Authorization, which chains single sign-on, RFC 8693 token exchange and an RFC 7523 JWT grant so an identity provider can decide whether a client may act for a user. Extensions are never active by default.
The design is defensible. MCP standardises the transport and pushes identity into your identity provider. But it means "which user is this agent acting for" is your problem, not the protocol's, and it will stay your problem.
What can you build today, without waiting?
Five things, all available now, none dependent on a draft landing.
One credential per agent, per purpose. Not one key for the company and not one key for the automation platform. If your ERP will only issue a handful of API users, spend them on workflows rather than on departments.
Never let the agent hold a person's credential. If the agent needs a human's authority, it should carry a token issued for that delegation, not a copy of their login. This is the line that turns an incident into a contained one.
Use token exchange if your identity provider supports it, and log the `act` claim. RFC 8693 distinguishes delegation, where the agent keeps its own identity and is annotated as acting for someone, from impersonation, where the log simply says the human did it. Check what your provider actually implements before you design around it.
Where the downstream system cannot carry an actor claim, record it at the application layer. Exact Online, AFAS and e-Boekhouden will not show you an `act` claim. So every write your agent performs should carry an agent identifier, a task identifier and the person who authorised it, stored on your side. This is a small change at the start of a project and a migration afterwards. The same discipline that makes connecting AI to Exact, AFAS or e-Boekhouden survive an audit.
Cap authority at the invocation boundary, not the credential boundary. The AAT draft may never become an RFC, but its design goal is worth stealing: the authority an agent uses for a task should describe the tools that task needs, not everything the calling principal could do.
If you run agents through n8n, the credential-store concentration risk is a separate and prior problem, which we covered in n8n security in 2026.
What this means for a Dutch SME
If you have an agent touching Exact, AFAS or a WMS today, you already have the attribution problem, and no vendor is going to remove it for you this year.
On the regulatory side, be careful with the dates. Record-keeping under Article 12 is a high-risk obligation, and Regulation (EU) 2026/1744, in force since 27 July 2026, moved most high-risk application to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Transparency duties under Article 50 and the GPAI penalty regime did begin on 2 August 2026. So no regulator is about to fine a Dutch SME for a thin agent audit trail. Build it anyway, because the deferral buys you time to do it properly and you cannot reconstruct actor identity from a year of logs that never recorded it.
For a 20 to 50 person company running its first agent against a Dutch accounting stack, this is roughly a day of design work: name the agents, scope their credentials, and write actor, task and approver on every mutation. It is unglamorous, it survives every standard that eventually lands, and it is the difference between an audit you can answer and one you cannot. If you want that designed properly the first time, that is what our AI agent development work is for.