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? A common failure mode is insufficient attribution: 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. The identity layer is now being built. 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.0 shipped on March 12. Agent Cards, the metadata an agent presents about itself, formalized signed cards, building on the signatures field introduced in v0.3.0: the specification signs them with JWS over JSON canonicalized per RFC 8785, 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 (EMA), 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 is the first supported identity provider, Anthropic implemented it in its shared MCP layer for Claude, Microsoft added it in VS Code and servers from Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase supported it at launch.
Where supported, EMA can replace some individually managed server connections with access governed through an organization’s identity provider. Verify client, server and identity-provider support before relying on revocation and group policy.
The next spec revision points the same direction: the 2026-07-28 specification pairs a stateless core with authorization hardening (issuer validation per RFC 9207, client credentials bound to the authorization server that minted them, Dynamic Client Registration deprecated in favor of CIMD), which makes per request identity more necessary, not less.
Update, September 3, 2026: when this was written the 2026-07-28 revision was a release candidate. It shipped as the final specification on July 28 with the stateless core intact: the initialize handshake and the Mcp-Session-Id header are gone and each request carries protocol metadata, including client information and capabilities. That client information is not a substitute for authenticated identity. We cover the boundary it draws in a separate piece.
Layer 3: what this task may do
Above connection governance sits the layer research attacked this year. PAuth (Sharma, Jiang, Chen and Lin, March 2026, a preprint) 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. On AuthBench, a benchmark the authors built on top of AgentDojo and cross validated on OpenClaw, all 100 benign tasks were authorized without extra grants and all 634 adversarial calls were blocked.
This is the same principle we apply as deterministic policy at the boundary: authorization needs to evaluate the operation in the context of the authenticated identity and delegated task.
Layer 4: proving the chain
AIP (Prakash, March 2026, a preprint) goes after delegation. The paper's premise is that neither MCP nor A2A verifies agent identity, and it cites a scan of roughly 2,000 MCP servers in which none had authentication. Read that as a claim about the agent rather than the caller: both protocols authenticate callers through OAuth and transport security, and what they do not do is bind that authentication to a specific agent instance. Its mechanism, capability tokens bound to each invocation, chains identity, attenuated authority and provenance into one verifiable artifact with bindings for MCP, A2A and plain HTTP. The authors report: 0.22 ms of overhead per call in a real MCP over HTTP deployment and 2.35 ms per call in a multi agent deployment, with all 600 adversarial attempts in their evaluation rejected. These results describe the tested prototype and workload, not a general guarantee. It is also an IETF draft, and the label matters: an individual submission by one author, not adopted by any working group and not endorsed by the IETF.
Update, September 3, 2026: the draft is now at revision 01, dated August 19, 2026, and remains an individual submission with no intended RFC status.
The integration work that remains
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. The reviewed protocol features do not by themselves provide the complete combination of 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.
Publisher verification and connection governance do not, by themselves, establish which running agent performed an action. That requires per-request attribution and correlated execution records.
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. Correlate it with workload identity, application logs and infrastructure telemetry; it is one part of the audit trail. 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 that is now 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.