The agent identity crisis, four months later.

In February I wrote that AI agents don't have identities, and that it was already a security crisis. The argument was practical, not philosophical: we were giving systems the ability to read files, call APIs and chain tools, while answering "who exactly is acting right now?" with a shared account and an API key scoped far wider than the task.

Four months later, here is what shipped. I think every strong claim deserves that check: go back and grade it against the record.

The diagnosis held, and the industry started building. Between March and June, agent identity went from a complaint in blog posts to protocol releases, enterprise features and papers with measured results. Unfinished, but no longer ignored.

What did A2A v1.0 actually fix?

It made Agent Card integrity cryptographically verifiable across organizational boundaries, provided the verifier can establish trust in the signing key. The A2A project reached its first stable specification with v1.0.0 on March 12, and the security content of that release is dense: the legacy OAuth implicit and password flows are gone, Device Code (RFC 8628) and PKCE came in, mTLS joined the security schemes and multitenancy became native.

The piece that matters most to me is Agent Card signing. The v0.3.0 specification already included an optional signatures field. Version 1.0 formalized signing and canonicalization; it did not introduce signed cards from scratch. In v1.0, cards can be signed with JWS over a canonicalized JSON payload, so a client can verify the card's integrity and, when the signing key is anchored to a trusted publisher, authenticate who published the metadata before trusting the interaction. The spec also standardized a way for an agent to pause in the middle of a task when an operation needs a human's approval.

What did MCP ship for identity?

MCP attacked the enterprise end of the problem. The 2026 roadmap published on March 9 did not make authorization a priority: it named four (transport, agent communication, governance and enterprise readiness) and left deeper security and authorization work "on the horizon", where core maintainers would support a community working group rather than lead one, with two proposals, DPoP and Workload Identity Federation, already in review.

The April maintainer expansion credited one appointee with the authorization specification and the Security Interest Group, and the release candidate for the 2026-07-28 revision was described by the maintainers as the largest since launch: a stateless core, Tasks and Apps as extensions, a formal deprecation policy and six proposals hardening authorization to match how OAuth 2.0 and OpenID Connect really get deployed.

Update, September 3, 2026: the 2026-07-28 revision shipped as final on July 28. I covered what it moves onto server implementations in MCP 2026-07-28 moves the security boundary to the server.

The concrete piece is Enterprise-Managed Authorization, stable since June 18. EMA moves MCP server access under the organization's identity provider: log in once, inherit access to every approved server, lose it all when IT deprovisions you. Okta is the first supported identity provider. Anthropic turned it on across Claude, Claude Code and Cowork, VS Code added support in the IDE and servers from Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase supported it at launch.

I want to be precise about what this fixes, because it is the biggest practical improvement since my original piece. EMA can reduce reliance on separately configured credentials for supported connections. Existing service tokens can be scoped and revoked, but shared credentials make attribution and lifecycle management harder. What EMA answers is which people in this organization may connect to which servers. What it still cannot answer is which agent instance exercised which delegated authority inside a chain of tools.

Connection governance improved. Per-action attribution still depends on the deployment.

Research ahead of the protocols

Two papers from March address task scope and delegation beyond the protocol features described above.

PAuth targets overprivilege at its root. A broad OAuth transfer scope may permit more than a single payment. OAuth does not require unlimited access: applications can enforce amount, recipient and task constraints. PAuth explores deriving authorization from the task itself, so submitting "pay Bob $100" authorizes exactly the operations that task requires. On AuthBench, a benchmark the authors built on top of AgentDojo, all 100 benign tasks were authorized without extra grants and all 634 adversarial calls were blocked. That is the policy layer at the level of individual operations that my February piece could only sketch, now running as a prototype.

AIP is the closest thing to a direct confirmation of the thesis. It opens by stating that neither MCP nor A2A natively verifies agent identity, and cites a scan by Knostic of roughly 2,000 internet exposed MCP servers in which not one had authentication. Its proposal, capability tokens bound to each invocation, fuses identity, attenuated authority and provenance into a single append only cryptographic chain, with bindings for MCP, A2A and plain HTTP. Measured cost: 2.35 milliseconds in a live deployment with multiple agents and a 100% rejection rate across 600 adversarial attempts. The proposal is an individual Internet-Draft, not an adopted IETF standard. Its benchmark results apply to the authors’ prototype and test conditions.

How did the February claims hold up?

I made five. Grading each:

1. Agents don't fit human, service or bot identity models. Held. The papers reviewed here address limitations in task scoping and delegated authority.
2. Delegation on behalf of a user is badly modeled. Held, with nuance. MCP still builds on standard OAuth 2.1; EMA made operating those flows dramatically better without introducing an agent native identity. Better plumbing over the same conceptual gap.
3. Composing several tools creates privileges nobody approved. Held, and the ecosystem caught up: the MCP maintainers framed tool annotations as a risk vocabulary, with the caveat that annotations are hints an untrusted server can lie about, and A2A added authorization inside a task. These changes address concrete trust questions in the reviewed specifications.
4. You can't reliably audit who did what. Partially fixed. Signed cards and AIP style records add provenance, but no audit standard per instance dominates across stacks yet.
5. The fix is a layered stack, not one patch. Held completely. MCP is building authorization, A2A is building declarative trust, research is building task scoping and verifiable delegation. A deployment needs to connect those layers and test the resulting guarantees.

What should defenders do now?

Three things I would do now, without waiting for the specs to finish.

1. Put MCP server access under your identity provider. Where your clients and servers support EMA, turn it on and retire the shared service accounts and the long lived tokens in .env files it replaces.
2. Log identity per call, not per connection. Neither protocol gives you identity per running instance yet, so record the authenticated user, the client, the tool and the arguments for every tool call. Keep that record where the agent cannot edit it.
3. Verify Agent Cards before trusting them. Check the JWS signature, pin the publisher keys you accept and treat an unsigned card, or one signed by an unknown key, as a description rather than a credential.

The identity work still ahead

The useful question is which identity guarantees a deployment provides today and which still require integration.

My current map: enterprise authorization for MCP exists and works. A real foundation for trust between agents exists in A2A v1.0. Task scoping and verifiable delegation exist as measured prototypes. The remaining integration requirement is a binding layer: identity per running instance, authority that attenuates correctly hop by hop and provenance across the whole chain that doesn't require trusting every intermediary.

In February I wrote that the best time to close this gap was before deployment. The update I owe that line: we are no longer starting from zero. The ecosystem now concedes, in specs and in shipped code, that an agent is neither a strange user nor just another service. Verifiable identity, bounded authority and auditable provenance are still not the default. The specifications document useful building blocks; verify how they are implemented in each production environment.

Disclosure: I founded Oktsec, which builds security for AI agent work, so I have an obvious stake in this problem getting solved. It is also why I keep tracking it.