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 over-scoped API key.

Four months is nothing in security and an eternity in this ecosystem. Time to do what I think every strong claim deserves: go back and grade it against what actually shipped.

The short version: 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 metadata verifiable across organizational boundaries. The A2A project reached its first stable specification in March, 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 multi-tenancy became native.

The piece that matters most to me is Agent Card signing. Under v0.x, an Agent Card was a self-description; nothing stopped an agent from claiming to be anything it liked. With v1.0, cards are signed with JWS over a canonicalized JSON payload, so a client can verify who published an agent's identity and capabilities before trusting the interaction. The spec also standardized a way for an agent to pause mid-task when an operation needs a human's approval.

Here is the honest limit: a signed card proves who published the description. It proves nothing about what a specific running instance is doing right now, or on whose delegated authority. Instance-level identity, portable across stacks, is still absent from the spec.

What did MCP ship for identity?

MCP attacked the enterprise end of the problem. The project's 2026 roadmap made authorization a first-class workstream, the maintainer team grew to handle proposal throughput, and the release candidate for the 2026-07-28 revision is 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.

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 IdP, Anthropic turned it on across Claude, Claude Code and Cowork, Microsoft shipped it in VS Code, and servers from Asana, Atlassian, Figma, 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. The pattern EMA kills is the shared service account with a long-lived token in a .env file: unauditable, unscoped, unrevocable. 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. Governance improved enormously. Per-action identity did not.

Where did research get ahead of the protocols?

In the middle layer both protocols leave open. Two papers from March stand out.

PAuth targets overprivilege at its root. OAuth scopes attach to operators, not operations: if your agent needs to send $100 to one person, OAuth makes you grant transfer permission for any amount to anyone. PAuth derives authorization from the task itself, so submitting "pay Bob $100" authorizes exactly the operations that task requires. On the AgentDojo benchmark, benign tasks ran without extra grants and every injected attack operation triggered a warning, with zero false positives or negatives. That is the operation-level policy layer 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, Invocation-Bound Capability Tokens, 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 multi-agent deployment, and a 100% rejection rate across 600 adversarial attempts. There is now an IETF Internet-Draft, which tells you which room this conversation is moving into.

How did the February claims hold up?

I made five. Grading each:

Agents don't fit human, service or bot identity models. Held. Every serious paper since starts from exactly this insufficiency.

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.

Multi-tool composition creates privileges nobody approved. Held, and the ecosystem caught up: tool annotations became a risk vocabulary, tool poisoning got named as a critical client-side vector, and A2A added in-task authorization. This is now consensus about where attacks live.

You can't reliably audit who did what. Partially fixed. Signed cards and AIP-style records add provenance, but no per-instance audit standard dominates across stacks yet.

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. Nobody is shipping a single fix because there isn't one.

What is the right question for the rest of 2026?

Not "do agents have an identity crisis?", that debate is over and the specs say so in writing. The question is which layers exist and which are still aspirational.

My current map: enterprise authorization for MCP exists and works. A real foundation for inter-agent trust exists in A2A v1.0. Task scoping and verifiable delegation exist as measured prototypes. What does not exist is the binding layer: identity per running instance, authority that attenuates correctly hop by hop, and end-to-end provenance 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. Until verifiable identity, bounded authority and auditable provenance are the default in production, the crisis hasn't ended. It has started to professionalize.

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.