Agent Identity is Not One Problem

In a previous post I argued that a lot of the trouble in AI governance comes from everyone using the same words to mean different things. Identity is another one of those words, and it is quietly being overloaded in exactly the same way.

This one has been bothering me for a long time, from well before agents. When a bank talks about a customer’s identity, it means at least two different things that it usually keeps carefully apart. There is the identity in the directory: the account, the login, the credential, the permissions. And there is the legal identity behind it: the passport, the national ID number, the actual person a court can hold responsible. In banking these are handled by different machinery. The directory does authentication and authorisation. A separate KYC programme does the work of tying that directory record to a real legal person. They are related, but they are not the same thing, and mature institutions do not pretend they are.

The government ID space is where this gets blurred in confusing ways. Sometimes you have to validate legal documents in order to authenticate at all, so the legal identity effectively is the credential. Sometimes the legal identity is treated as a set of attributes hanging off a directory record, with a KYC-style programme wrapped over the top. Sometimes it is buried inside a business process like customer lifecycle or churn management. Same underlying concepts, arranged in genuinely different architectures.

Agents bring this straight back to the surface, and make it harder. So I want to do the same thing I did with governance and compliance: separate the concepts, define them plainly, and show how they relate. Because if we do not, we will build agent identity systems that look finished when they have only solved a fraction of the problem.

A quick note on vocabulary, since this is a post about not multiplying confusing words. Where a plain, established term already exists I have used it — identification, authentication, attestation, entitlements, mandates — rather than inventing new ones. I have coined nothing; the only slightly unusual move is using accountability for one layer, for a reason I will explain when I get there.

A note on precision, too. Most of the standards in this space are fast-moving Internet-Drafts or vendor protocols. I have tried to be careful about what is a settled standard, what is an individual draft with no formal standing, and what is a vendor announcement. That distinction matters, because a lot of writing in this area makes these things sound more equivalent and more finished than they are.

The short version

The simplest version I have found is that “agent identity” is not one thing. It is a set of different questions. They sort into three layers, and the third comes in two forms:

1. Technical identity — is this the same entity we saw before, can it prove it, and is it what it claims to be? (identification, authentication, attestation)
2. Accountability — who in the real world is answerable for what it does? (the binding to a legal person — established by KYC for humans, and by Know Your Agent for agents)
3. Authority — what is it allowed to do? This splits in two:
   • entitlements — the standing permissions it holds, looked up from its identity (roles, scopes);
   • mandates — per-action authorisation, minted for a specific task and then spent; because no human is present at the moment of action, these need to be cryptographically verifiable.

And two threads that run across all of them, easy to forget and painful to retrofit:

• Delegation — how authority moves along a chain of user → agent → sub-agent → tool → downstream service, with each hop accounted for.
• Evidence — the audit record left behind, which is how accountability and authority become provable after the fact rather than merely asserted.

Or, in plainer language:

Technical identity tells you who is asking and what is running. Accountability tells you who is answerable. Entitlements tell you what it may generally do. Mandates tell you whether this particular action is permitted right now. Delegation records how the authority got there. Evidence lets you prove all of it later.

That distinction does a lot of work, and most of the rest of this post is really just taking it seriously.

Why this gets confusing

The reason nobody explains this cleanly is that three different communities each own one slice of it, and each uses the word “identity” to mean their slice.

Ask an identity engineer and identity means the technical kind — directories, tokens, federation, SPIFFE, OIDC — and maybe some standing entitlements on top. Ask an AML or compliance person and identity means the KYC binding: proving there is a real, sanctioned-checked person behind the account. Ask a lawyer and identity means accountability: whose acts are these, who can be held liable. None of them is wrong. They are just describing different layers and calling all of them “identity”.

For humans this rarely bites, because a person can be all three at once and we have decades of practice keeping the machinery aligned. Agents are the first thing that forces all three communities into the same artefact at the same time, at machine speed. That is when the vocabulary collision turns into a delivery problem.

So let me take the layers one at a time.

Technical identity

Technical identity is a system’s ability to identify a persistent entity, challenge it to prove it is that entity, and — for agents especially — verify what it is actually running.

This is the layer most people mean when they say “identity”, and for agents it is the one that is closest to mature. At its core are an identifier and a credential, and authentication is the act of proving control of that credential. For a human it is OIDC, SAML, a directory record, a passkey. For an agent it is increasingly a workload identity: SPIFFE and SPIRE issuing short-lived credentials, the IETF’s WIMSE work building workload-to-workload authentication on top, and emerging SCIM drafts exploring how to provision agents as first-class directory resources.

Two cautions here, because this is where people overclaim. First, provisioning is not the credential. A useful line from the SCIM working-group discussions puts it well: SCIM provisions the right to an identity, not the identity itself; the credential is obtained separately, for example from SPIFFE. Second, discovery metadata is not identity. A2A Agent Cards are sometimes described as giving an agent a verifiable identity, but that is too strong. Agent Cards are discovery metadata that advertise an endpoint’s identity, capabilities, skills and security requirements, and they may be signed for integrity and provenance. The actual authentication and authorisation still happen through the declared security schemes and server policy. A signed card tells you the card has not been tampered with; it is not an accountability framework.

There is also a part of technical identity that is specific to agents and easy to miss. For a human, “is this the same person?” is usually enough. For an agent, a relying party will increasingly want to know: same code? same model? same tool configuration? same policy bundle? the same version that was approved? That is attestation, and it belongs inside technical identity — it is the third component alongside identification and authentication, and the one that has almost no analogue for humans.

Technical identity should include not only a stable workload subject, but also attestable claims about the runtime, code, model, policy version and tool configuration. Otherwise the system recognises a familiar name while running a materially different agent.

The important thing about this layer is what it does not tell you. It says “this is the same entity, it can prove it, and this is what it is”. It says nothing about who is responsible, and nothing about what the entity is allowed to do. It is necessary for everything above it, and sufficient for none of it. Hold on to that, because it is the trap I will come back to.

Accountability is the legal identity

Accountability is the binding from a technical identity to a real-world party who can be held answerable for its actions.

This is the layer the identity engineers do not own, and it is where the technical-vs-legal distinction actually lives. For a human, accountability is KYC, eIDAS, a verifiable credential like a mobile driving licence. The key point is that a human can occupy this layer directly: the person is both the authenticated account and the accountable legal entity. Technical identity and accountability can collapse onto the same subject.

For an agent this is impossible, and the impossibility is the most important thing on the whole map. An agent has no legal personhood. There is no version of this where the agent itself is the accountable party. Accountability for an agent is therefore never “the agent’s legal identity” — it is always a binding to a different entity, the human or organisation that owns it.

This is where Know Your Agent comes in, and the name is a deliberate nod to Know Your Customer. That analogy is a good one — it is the point of the name. The one thing it does not carry over is that a customer is a legal person and an agent is not. So the job is not to certify the agent as a responsible party. It is to establish the chain from the agent to the person or organisation who is accountable for it, and to keep re-verifying it as the agent drifts. The agent, throughout, is closer to an instrument than an actor.

Accountability is the property — a live binding to a responsible party. Know Your Agent is the practice that establishes and maintains it.

United States electronic transactions law has a useful analogue here, and it is worth being precise about what it does and does not say. The E-SIGN Act and the state-level UETA both define an “electronic agent” as an automated process that acts without review by an individual, and both recognise transactions involving electronic agents where the action is legally attributable to the person to be bound. The UETA drafting notes are blunt about where the intent comes from: when a machine acts, the required intention flows from the programming and deployment of the machine, not from the machine itself. It is treated as a tool whose acts are the owner’s acts, following ordinary agency law. Remarkably, the 1999 drafters even anticipated agents that might one day act autonomously rather than merely automatically.

That is not a complete AI-agent liability regime, and it is not a global rule or a runtime identity model. But it supports the basic conceptual point exactly: the software is not the legal person, and accountability runs to a human or organisation.

This is also where the one piece of deliberate vocabulary comes in. I use accountability for this layer rather than the more obvious attribution, because “attribution” carries two meanings that pull in opposite directions. Technical, or forensic, attribution asks which agent emitted this action — a question of identification and evidence, and it lives in technical identity. Legal attribution — what E-SIGN means by “legally attributable” — asks who is answerable for the agent, which is this layer. A system can have perfect forensic attribution, knowing exactly which agent acted, and still have no legal accountability, because nobody is bound to answer for it. That gap is precisely why the two are separate layers, and reusing one word for both is exactly the collapse this post exists to prevent — so the forensic sense keeps the name “attribution”, and this layer gets “accountability”.

What is new is that we now need to prove that binding to a machine, at runtime, rather than argue it after the fact in front of a court. That is what an individual WIMSE-related Internet-Draft is reaching for with what it calls a dual-identity credential: a single credential carrying the identifiers and public keys of both the agent and its owner, cryptographically bound to both. It is promising, and worth reading, but the caveats need to be sharp. It is an individual draft, not a WIMSE working-group document or an endorsed standard. Its security considerations are still marked TODO. And its definition of “owner” is broad enough to include an individual, an organisation, a device, or a policy engine — which means the draft does not, by itself, establish legal accountability to an accountable legal person. It gives you a mechanism for binding, not an answer to which binding is the legally responsible one.

There is a detail in that draft that reinforces the argument of this post: it explicitly puts inheritance of the user’s permissions out of scope. It is trying to bind the agent to its owner, and it deliberately refuses to also decide what the agent is then allowed to do. The spec authors are keeping accountability and authority apart. So should we.

The two things fit together rather neatly. UETA says attribution can be shown by “the efficacy of any security procedure” applied to determine the responsible person. A dual-identity credential is exactly such a security procedure. One is the runtime cryptographic artefact that establishes the binding; the other is the legal doctrine that gives the binding consequence. And when the binding is missing or stale, both fail at once: you have a technical credential that will not validate and a legal attribution gap, at the same moment, for the same reason.

The owner is not always the principal

The word “owner” is doing too much work, in this post and in the drafts. In a real deployment an agent does not have one principal. It has several, and they are frequently different parties:

• the legally accountable organisation;
• the business owner or operator running the agent;
• the human delegating a particular task;
• the resource owner or data owner whose systems are touched;
• the software or model provider;
• the payment account holder, where money moves;
• the merchant, issuer or relying party on the other side;
• the policy engine that actually issued the authorisation.

This matters because “Know Your Agent” cannot just bind agent → owner. It has to say which principal, for which purpose, under which authority, and visible to which relying party. The broad “owner” definition in the WIMSE draft and the owner and resource relationships in the SCIM agent drafts both point in this direction without fully resolving it.

The owner is not always the principal. An agent may be built by one party, operated by another, delegated by a user, authorised by a resource owner, and paid for by a different account holder. Accountability needs a principal stack, not a single owner field.

One identity, many accountabilities

There is a sharper way to put that point, and it changes how the binding should be built. An agent has one technical identity — the “which agent” is singular and stable — but many principal relationships. So the shape is not a tree with the agent hanging off a single owner; it is a star, with one agent at the hub and a set of edges out to different principals.

Those edges are not the same kind of binding, which is why “agent plus owner” undersells it. They live at different layers and use different mechanisms:

• agent ↔ accountable organisation or operator — a durable accountability binding; this is the dual-identity credential’s proper domain, long-lived, “who answers for this agent”;
• agent ↔ delegating user — a scoped authority binding: per-task and expiring (an ID-JAG or on-behalf-of token, not a standing credential);
• agent ↔ payment account holder — a mandate, per transaction;
• agent ↔ resource owner — a grant at that resource, exchanged and audience-bound;
• agent ↔ model or software provider — a provenance claim, which is really attestation at the technical-identity layer rather than an accountability binding at all.

So it is not many copies of one “dual” credential; it is one stable identity with many typed, contextual edges.

And even a single edge is often not dual. A real high-consequence action usually has to assert several principals at once — the accountable organisation, the delegating user, the payment holder — bound to one intent. AP2 already works this way: its mandate binds agent, user and intent into a single signed credential. So “dual” is a floor, not the shape; the artefact for a given action is n-ary and contextual — the agent identity, plus whichever principals that action implicates, plus the purpose and the window.

This is also why the dual-identity draft’s broad “owner” definition is the wrong shape rather than merely vague. A single “owner” field cannot simultaneously be the accountable organisation and the delegating user and the resource owner; those are different edges with different lifetimes and purposes. Collapsing them into one slot is the same category error as collapsing technical identity into authentication — one field pretending to be a structure.

An agent has one identity and many accountabilities. The job of the accountability layer is not to record an owner, but to resolve, per action, which principals are in scope and bind them — which is exactly what a single owner field cannot do.

Delegation, and the no-borrowed-identity rule

Agent identity gets genuinely hard the moment authority passes through a chain: a user delegates to an agent, which calls a sub-agent, which calls a tool, which calls a downstream service. Each hop is a place where accountability can quietly evaporate.

The standards that have thought about this are consistent on the principle. WIMSE discusses act-on-behalf-of patterns, token exchange, actor chains and down-scoping credentials across hops, and warns that each hop needs its own authentication and authorisation check. The ID-JAG / Cross-App Access draft is explicit that a grant issued for one downstream service must not be reused as the authorisation grant for a different one. A2A prefers out-of-band credentials and warns that passing credentials in-band through an agent chain can expose them, recommending they be bound to the originating agent and encrypted for the target.

The rule of thumb I would take from all of this is simple:

No borrowed identity. Every delegation hop needs its own actor, scope, expiry, audience, audit record and revocation path.

This is also where the earlier point about sub-agents becomes concrete. A child agent acting under a parent’s borrowed credential is the fastest way to break the accountability chain at exactly the point where you most need it intact.

Authority comes in two forms

Authority is what the entity is permitted to do. Entitlements are a property of the identity; mandates are a property of a specific action.

Here is the part I think is least well understood, and it is where a lot of agent governance is still looking at the wrong object. The distinction is simply about where the permission lives: an entitlement sits on the identity and is looked up, while a mandate travels with a single action and is spent.

Entitlements are the familiar form. They are roles, groups, OAuth scopes, RBAC and ABAC, and policy-decision APIs. AuthZEN is worth naming precisely here: it is an authorisation decision API — a way for a policy enforcement point to ask a policy decision point “is this allowed?” — not an entitlement store or an identity system. An entitlement is derived from the identity: you present who you are, and a policy keyed on that identity decides what you may generally do. For agents the substrate is much the same as for humans, with a translation step bolted on: OAuth 2.0 Token Exchange (RFC 8693) for delegation and impersonation patterns, or ID-JAG / Cross-App Access to turn an identity assertion into a scoped grant at another application without a consent redirect. If you are going to get leverage out of your existing IAM investment, this is where it happens.

Mandates are different in kind. Whether an agent may spend a set amount at an approved merchant this afternoon is not really a fact about the agent. It is a fact about a specific tuple of principal, intent, scope and time. It gets minted for a task and then spent. This is the world of payment mandates and, underneath, the old idea of capabilities: authority as a token you hold and present, attenuated down to a narrow task, rather than a standing entitlement sitting on your identity.

For humans this form barely exists, because a human is usually present at the moment of consequence. You are standing at the checkout; you click confirm; step-up authentication is the exception, not the rule. Presence substitutes for proof. For agents there is no one present, so authority at the moment of action has to become an explicit, cryptographic, per-transaction artefact. The form that is almost invisible for humans becomes load-bearing for agents.

The clean way to say it: a standing identity tells you an agent could act; only a mandate tells you it may act here. Do not try to express “may spend this much at approved merchants this month” as a directory entitlement. It is a mandate. It should be minted, scoped and burned.

Mandates are not only about payments

Payments are the cleanest example, and they can make this form look narrower than it is, because money already has mandate vocabulary. The same pattern applies to any high-consequence action: deleting records, exporting a dataset, sending an external email, raising a purchase order, deploying code, changing payroll or HR data, filing a regulatory submission, or invoking any destructive tool.

MCP is the obvious place this connects for non-payment actions. The MCP authorisation model uses OAuth 2.1 patterns — protected-resource metadata, resource indicators, token audience validation and scope checks — and the MCP auth community is explicitly working through the gaps around delegated and agentic access, on-behalf-of token exchange, downstream access, consent in agent and tool chains, and per-tool or per-resource scopes.

Payments are only the easiest case because money already has mandate vocabulary. The same pattern applies to any high-consequence tool call: the authorisation artefact should bind actor, principal, resource, action, purpose, expiry, audience, replay constraints and the policy decision.

The payment protocols themselves are worth distinguishing, because they are not all the same kind of thing. Google’s AP2 uses signed “mandates” — including intent and cart mandates — as tamper-resistant evidence of what the user instructed. Mastercard’s Verifiable Intent is framed similarly, as a tamper-resistant record of what the cardholder authorised an agent to do. Visa’s Trusted Agent Protocol is related but different in purpose: it is more about letting merchants distinguish trusted agents from bots and verify signed agent, intent and payment messages, with time-bound, merchant- and purpose-specific signatures. It should not be presented as the same construct as AP2’s mandate model.

The more useful reference point is that this is consolidating. In April 2026 the FIDO Alliance stood up an Agentic Authentication working group and a payments workstream, with Google contributing AP2 and Mastercard contributing Verifiable Intent, around three focus areas: verifiable user instructions, agent authentication, and trusted delegation for commerce. That is a better way to read the space than treating the vendor protocols as isolated competitors.

A valid identity is not a valid intention

Identity does not solve semantics. This is the failure that a clean layer model can accidentally hide, so it is worth stating directly.

A perfectly identified agent, bound to the right owner, carrying a valid scoped token, can still be pointed at the wrong action by prompt injection, goal hijacking, tool misuse, or a confused-deputy chain. OWASP’s 2026 agentic-application work is useful precisely because it frames agent risk around autonomy, tool access, memory and misuse, rather than just authentication.

A valid identity is not the same as a valid intention. Prompt injection and goal hijacking can cause the right agent, with the right credential, to request the wrong action. The mandate must be checked at the tool or resource boundary against the declared intent, not inferred from login state.

This is the same lesson from my agent risk management post in a different costume: authenticating the actor is not the same as bounding the action.

Evidence, and the audit receipt

The layers above explain decisioning. They do not, on their own, leave a trace. For agent governance the audit record is not incidental; it is how accountability and authority become provable after the event, which is the whole point of having them.

A good audit receipt for an agent action would capture:

• the agent identity and the credential issuer;
• the accountable principal, and the delegating user where applicable;
• the mandate or token ID, and the policy decision ID;
• the action, resource, scope, expiry and audience;
• the model, code and tool versions in effect;
• a timestamp and replay protection;
• the result of the action;
• the full delegation chain, including any sub-agents.

WIMSE has audit-trail guidance for workloads and their security contexts, and AP2’s mandate model is explicitly designed to produce a non-repudiable audit trail for agentic commerce. The instinct is the same one I keep coming back to: evidence should be a trace of real control operation, not theatre.

The same layers, but not the same shape

If you lay human identity and agent identity side by side across these layers, the standards look reassuringly similar in places and diverge sharply in others.

Three things fall out of reading the table across, rather than down.

The first is the asymmetry at accountability. For a human, technical identity and accountability can be the same subject; an agent structurally cannot, and its accountability is always an edge to another party. That single fact is why “agent identity” cannot be modelled the way we model human identity, however tempting the analogy.

The second is where the genuinely new work is. Technical identity borrowed from workload identity. Entitlements borrowed from OAuth. But mandates for agents are being invented largely from scratch, because humans never needed them in the same way. If you want to know where the frontier is, it is at the bottom of that table.

The third is a maturity gradient that doubles as a risk heat-map, as long as we do not overclaim it. The human column is comparatively mature, though far from perfect — account takeover, weak delegated-authority models, imperfect KYC, synthetic-identity fraud and session problems are all still real. The agent column is production-grade only where it borrows directly from workload identity; the agent-specific layer built on top — provisioning, owner binding, delegation chains and runtime mandates — is still emerging. Read the agent side as “how settled is this?” and you have a reasonable, if rough, picture of where to be careful.

The trap: stopping at technical identity

Here is the failure mode I keep seeing. An organisation adopts SPIFFE, gets federation working, issues workload credentials, and stops. Sometimes they bolt a legal identity onto the human login and feel they have covered accountability. But the upper layers never get built.

I do not think this is laziness. I think it is because technical identity produces a very strong completion signal. The credential is issued, mutual TLS is working, the dashboard is green. Everything looks done. But technical identity is the one layer that stands on its own; the layers that carry accountability and per-action authority produce no such signal, so their absence is invisible.

To be fair to SPIFFE, it is careful about its own scope. SPIRE does have real controls — registration and attestation determine which workloads are issued which identities. What SPIFFE deliberately does not provide is application or resource authorisation. It gives you an authenticated workload subject and an attestation-backed identity to write policy against; it does not decide whether that subject may perform a particular business action. WIMSE makes the same separation explicit: authentication establishes identity, and resource authorisation needs a separate policy decision using context, action and policy.

And the “link the legal identity in the login” shortcut has a subtle problem for agents specifically. That binding lands on the human session, captured once at login. The moment the agent acts autonomously — no human in the loop, hours after that login — the binding is stale, and the agent’s own action has no fresh accountability chain. You have attached the legal identity to the wrong subject at the wrong time.

So the two seams that the “identity-only” shops skip are the two that matter most: an ownership record that binds each agent to an accountable principal and keeps a live on-behalf-of binding at action time, and a step where a workload credential is exchanged for a scoped, short-lived grant, with per-action mandates minted per task rather than expressed as standing entitlements. Technical identity without those is an industrial-grade answer to which agent sitting on top of reconstructed-after-the-fact accountability and implicit-allow authority.

Where this connects to risk and governance

This is where the identity discussion rejoins the agent risk management argument. The reason the layers matter operationally is that different lifecycle and governance processes attach at different layers, and treating them as one thing causes tooling to either over-govern or under-govern.

• Discovery, registration, credential rotation and deprovisioning attach at technical identity. This is workload and directory hygiene.
• Ownership, accountable-principal assignment, KYC of the owner, risk classification and audit attribution — tying an action to the accountable principal — attach at accountability. These are the processes that “rely on technical identity but go broader”: they need a stable technical identity to hang on, but the content is accountability, not identification.
• Entitlements — standing permissions — attach at the authority layer, and behave like classic IAM.
• Spend limits, step-up, intent verification and other mandates are the per-action side of authority, and belong at a decision point at call time, not in the directory.

Two governance points deserve to be explicit rather than implied.

The first is lifecycle and revocation, which is where agent identity gets operationally nasty. The hard cases are not the happy path; they are: the owner leaves the organisation, the agent is cloned, the model or prompt changes materially, a key is compromised, tool permissions drift, a mandate expires but cached tokens remain, a sub-agent keeps running after the parent task ends, or an agent is suspended but still holds downstream credentials. Each of these breaks one of the layers while the others look fine. This is also where the “fail closed” instinct earns its keep: when an agent’s accountability chain is broken — the owner is gone, the binding has gone stale, no responsible party can be identified — the safest default is to stop the agent, because in both the technical and the legal sense it is now acting for nobody. That is a management decision, not a technical default, but I think it is the right one.

The second is privacy and data minimisation, which agent identity systems tend to get wrong by leaking too much. An identity or mandate claim can carry internal service names, user identity, business purpose, customer detail, merchant intent, or organisational topology. The design principle is the same as everywhere else in least privilege: a relying party should receive the minimum identity, accountability and mandate claims needed for the action, and no more.

And this is the right home for the regulatory frameworks, which are often misfiled as if they were identity mechanisms. The EU AI Act, for example, is not a runtime identity or an owner-binding credential; it is a regulatory framework that assigns obligations to actors such as providers and deployers — Article 26 sets out deployer duties around instructions for use, human oversight, logging and incident reporting for high-risk systems. That belongs in the governance conversation as an accountability obligation, not in the identity-layer table as though it were equivalent to KYC or a verifiable credential. Regulation tells you who must be accountable; the identity layers are part of how you make that accountability real and provable.

You can already see this separation in how the market is structuring itself, even where nobody names it. Independent governance platforms — Aigentsphere is one example — place Know Your Agent at what we call [“Layer 3, central governance” and “Layer 4, risk management,”] (https://www.aigentsphere.com/resources/sustainable-safe-and-scalable) explicitly above their engineering and operational layers, which treats KYA as an accountability-and-governance overlay sitting on top of the technical stack rather than as the technical-identity layer itself. That is the separation this post argues for, expressed as a product boundary — and it carries the same warning from the other direction, because a governance overlay delivers nothing if the technical identity it assumes was never built in the layers beneath it.

Conclusion

Agent identity is not one problem. It is technical identity, accountability and authority; authority is itself two forms, entitlements and mandates; and delegation and evidence run across all of them. The standards line up cleanly against those layers once you stop trying to make one word carry all of them:

Technical identity tells you which actor is present and that its credential checks out. Attestation tells you what is actually running. Accountability tells you which real-world principal is answerable. Entitlements tell you what class of actions may be attempted. Mandates tell you whether this action is allowed now. Delegation records show how authority moved through agents and tools. Audit receipts prove what happened afterwards.

The mature identity world already keeps the technical and the legal apart for customers, with the directory on one side and KYC on the other. Agents make it tempting to fold everything back into “the agent’s identity” and be done. That instinct is the mistake. The seams between technical identity, accountability and authority are load-bearing, and the whole point of drawing the map is to stop building on top of a layer that was never designed to hold the weight.

References

The IETF drafts, vendor protocols and framework references below move quickly; the citations marked “verify” should be checked against the latest version as this post may be out of date.

1. SPIFFE, Secure Production Identity Framework for Everyone. Provides authenticated workload identity within a trust domain; deliberately leaves application/resource authorisation to systems built on top. https://spiffe.io/
2. IETF WIMSE Working Group, Workload Identity in a Multi System Environment (WIMSE) Architecture, draft-ietf-wimse-arch (‑08 as of mid‑2026; verify current version). Separates authenticated identity from resource authorisation. https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/
3. Y. Ni and C. P. Liu (Huawei), WIMSE Applicability for AI Agents, draft-ni-wimse-ai-agent-identity-02, 28 February 2026. Individual Internet-Draft; no formal IETF standing; introduces a “dual-identity credential”; owner model broader than legal accountability; security considerations still TODO; permission inheritance explicitly out of scope. https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-identity/
4. A. Messous, L. Morand and C. P. Liu, Entity Attestation Token (EAT) Profile for Autonomous AI Agents, draft-messous-eat-ai (verify current version). Attestation claims for agent integrity, model and provenance.
5. J. Rosenberg et al., CHEQ: Confirming AI Agent Decisions with Human in the Loop (individual draft; the original draft-rosenberg-cheq-00 appears expired — verify whether a newer draft supersedes it).
6. United States, Electronic Signatures in Global and National Commerce Act (E-SIGN), 15 U.S.C. § 7001 et seq., 2000; and Uniform Law Commission, Uniform Electronic Transactions Act (UETA), 1999, §§ 2(6), 9, 14 and official comments. U.S. electronic-transactions law only; recognises transactions involving electronic agents where the action is legally attributable to the person to be bound. https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section7001
7. NIST, AI Agent Standards Initiative (Center for AI Standards and Innovation), and NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper), 2026. Argues existing enterprise identity standards can be extended to agents rather than replaced. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
8. IETF OAuth Working Group, Identity Assertion JWT Authorization Grant (ID-JAG), draft-ietf-oauth-identity-assertion-authz-grant-04; the Cross-App Access (XAA) profile. Still a draft. https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ With M. Jones et al., OAuth 2.0 Token Exchange, RFC 8693. https://www.rfc-editor.org/info/rfc8693/
9. M. Wahl, D. Zollner, P. Dingle and I. Kazzouzi, AI Agent Resource Extension for SCIM, draft-wzdk-scim-agent-resource-00, 5 June 2026. Individual Internet-Draft; no formal IETF standing. The earlier draft-abbey-scim-agent-extension-00 expired in April 2026; SCIM agent work is currently being consolidated in the working group. https://datatracker.ietf.org/doc/draft-wzdk-scim-agent-resource/
10. A2A Project, Agent2Agent (A2A) Protocol Specification. Agent Cards as discovery metadata (endpoint, capabilities, skills, security requirements), optionally signed for integrity/provenance; authentication/authorisation via declared schemes. https://github.com/a2aproject/A2A/blob/main/docs/specification.md
11. FIDO Alliance, FIDO Alliance to Develop Standards for Trusted AI Agent Interactions, 28 April 2026. Agentic Authentication and payments workstreams; Google (AP2) and Mastercard (Verifiable Intent) contributions; focus areas of verifiable user instructions, agent authentication, and trusted delegation for commerce. https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/
12. Google Cloud, Announcing Agent Payments Protocol (AP2). Signed intent and cart mandates as tamper-resistant evidence of user instructions. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
13. Mastercard, Verifiable Intent. Tamper-resistant record of what a cardholder authorised an agent to do. https://verifiableintent.dev/
14. Visa, Visa Introduces Trusted Agent Protocol. Distinguishing trusted agents from bots; verifying signed agent/intent/payment messages with time-bound, purpose-specific signatures. https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx
15. Model Context Protocol, Authorization, spec version 2025-06-18. OAuth 2.1 patterns: protected-resource metadata, resource indicators, audience validation, scope checks; ongoing work on delegated/agentic access. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
16. OpenID Foundation, Authorization API (AuthZEN). A PDP/PEP authorisation decision API, not an entitlement store.
17. OWASP Gen AI Security Project, OWASP Top 10 for Agentic Applications (2026). Frames agent risk around autonomy, tool access, memory/context and misuse. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
18. European Commission, AI Act, incl. Article 26 (deployer obligations for high-risk systems). Regulatory accountability, not an identity mechanism. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
19. IMDA Singapore, Model AI Governance Framework for Agentic AI (verify exact version/date before publishing). https://www.imda.gov.sg/

Credits

This post was prepared in conjunction with Claude (Anthropic) and incorporates external review feedback. The concepts and writing are my own.