The identity stack for AI agents: what shipped, what didn't.
Agent identity stopped being a debate and became a construction site. Here is the stack as it stands in mid-2026, layer by layer, with what each one answers and where the gaps sit.
The short version
- The question "who exactly is this agent acting as?" now has partial answers in shipped software: A2A v1.0 verifies who published an agent, MCP's Enterprise-Managed Authorization governs who may connect to what.
- Research prototypes cover the next layer: task-scoped authorization (PAuth) and verifiable delegation chains (AIP, now an IETF draft).
- No layer yet identifies a specific running instance, attenuates authority hop by hop, or gives you provenance without trusting intermediaries.
- Until those exist as defaults, the audit answer is per-call evidence recorded at the boundary.
When we review an agent environment, one question decides how hard everything else is: when this system acts, can anyone say precisely who acted, under whose authority, and with what limits? Through 2025 the honest answer was almost always no. The agent ran as a shared service account, held a long-lived token, and carried permissions sized for the operator rather than the operation.
The first half of 2026 changed the landscape enough that the answer deserves an update. Not because the problem got solved, but because it moved from complaint to construction. Reading the releases as a stack makes both the progress and the holes visible.
Layer 1: who published this agent
This is the layer A2A v1.0 shipped in March. Agent Cards, the metadata an agent presents about itself, went from self-declared to verifiable: signed with JWS over canonicalized JSON, so a client can check who published an agent's claimed identity and capabilities before trusting it across an organizational boundary. The same release dropped the legacy OAuth implicit and password flows, added PKCE and Device Code support, and brought mTLS into the security schemes.
What this layer answers: is this agent's description authentic, and who stands behind it. What it cannot answer: anything about a particular running copy of that agent. A signed card is a passport for the species, not for the individual.
Layer 2: who may connect to what
This is MCP's contribution, and for enterprises it is the year's most useful shipment. Enterprise-Managed Authorization, stable since June 18, puts MCP server access under the organization's identity provider: one login, access inherited by group membership, revoked at offboarding. Okta went first, Anthropic enabled it across its products, Microsoft shipped it in VS Code, and servers from Asana, Atlassian, Figma, Linear and Supabase supported it at launch.
The pattern EMA retires is one we find in most audits: a service account shared by every agent, authenticated by a token that lives in a file and never expires. Killing that pattern removes a whole class of findings.
The forthcoming spec revision points the same direction: the 2026-07-28 release candidate pairs a stateless core with a batch of authorization hardening, which makes per-request identity more necessary, not less.
Layer 3: what this task may do
Above connection governance sits the layer research attacked this year. PAuth starts from the observation that OAuth scopes attach to operators rather than operations: an agent that needs to move $100 to one recipient gets a permission that covers any amount to anyone. Its alternative derives authorization from the task itself, so the natural-language instruction authorizes exactly the operations needed to carry it out. In the AgentDojo evaluation, benign tasks completed without extra grants and every injected attack tripped a warning, with zero false positives and zero false negatives.
This is the same principle we apply as deterministic policy at the boundary: the unit of authorization is the operation, not the identity that requests it.
Layer 4: proving the chain
AIP goes after delegation. The paper opens with the blunt observation that neither MCP nor A2A natively verifies agent identity, citing a scan of roughly 2,000 internet-exposed MCP servers in which none had authentication. Its mechanism, Invocation-Bound Capability Tokens, chains identity, attenuated authority and provenance into one verifiable artifact with bindings for MCP, A2A and plain HTTP. Measured cost in a live deployment: 2.35 milliseconds per call, with all 600 adversarial attempts rejected. It is now an IETF Internet-Draft.
The layer nobody ships
Stack the four layers and the hole is precise. Verifying the publisher exists. Governing the connection exists. Scoping the task and proving the chain exist as prototypes. What no protocol ships as a default is identity for the running instance: this copy of this agent, on this task, for this principal, with authority that shrinks correctly at every hop, leaving a record you can audit without trusting each intermediary.
Every layer that shipped this year narrows who could have acted. None of them yet records who did act, per call, in a form that survives across stacks.
That gap is not a reason to wait. It defines what to operate at the boundary today: record the authenticated identity, the tool, the arguments and the policy version on every call, deterministically, where the agent meets your systems. When per-instance identity arrives as a standard, that evidence stream is what it will plug into. Until then, it is the only audit trail that exists. We covered what that looks like in practice in Agent work needs evidence, not trust.
The takeaway
Agent identity in mid-2026 is a stack under construction, being built roughly in the right order: publisher verification and enterprise governance first, task scoping and delegation proofs behind them. Plan for the missing layer instead of assuming it: per-call evidence at the boundary is what makes today's agents auditable, and what tomorrow's per-instance identity will attach to.
Founder's companion piece, grading the original February claims one by one: The agent identity crisis, four months later.