The Identity Layer for AI Agents Is Finally Being Built

In March I published a piece arguing that AI agents don't have identities and that this was already a security crisis. The claim was operational. We were deploying systems that read files, call APIs and chain tools together, while the answer to the most basic security question, who exactly is acting right now, was still a shared account, a reused API key and permissions far broader than any single task required. Four months later the diagnosis holds. Agent identity is not solved end to end. What changed is that the problem became explicit. Between March and July 2026 it showed up in protocol releases, enterprise features and papers with measured results. The identity layer for AI agents is finally being built. It just isn't finished. A2A grew up first The first milestone landed almost on top of my original article. On March 12, the A2A project shipped v1.0.0, its first stable specification. The release touches security directly: it removes the legacy OAuth implicit and password flows, adds Device Code (RFC 8628) and PKCE support, introduces native multi-tenancy, adds mTLS to the security schemes and formalizes Agent Card signature verification using JWS and JSON Canonicalization. The signed Agent Cards are the piece I care about most. In v0.x, an Agent Card was self-declared metadata. Any agent could claim to be anything. With v1.0, clients can cryptographically verify agent identity and metadata before trusting an interaction across organizational boundaries. The spec also formalizes in-task authorization through the TASK_STATE_AUTH_REQUIRED state, which gives agents a standard fallback when an operation needs human or client approval mid-flight. The limitation is that Agent Cards remain a declarative layer. The signature proves who published the card. It says nothing about what a specific running instance of that agent is doing right now, or under whose delegated authority. Identity per instance, portable across heterogeneous stacks, still doesn't exist in the spec. MCP put authorization at the center MCP moved on a different front. On March 9, the maintainers published their 2026 roadmap, acknowledging that the protocol had outgrown its "connect local tools" phase and was now production infrastructure with governance to match. In April the project expanded its maintainer team, citing the move to the Agentic AI Foundation and a growing volume of Specification Enhancement Proposals. When a protocol starts adding lead maintainers to handle SEP throughput, it has stopped being an experiment. On May 21, the maintainers published the release candidate for MCP 2026-07-28 and described it as the largest revision since launch. It brings a stateless core, Tasks and MCP Apps as extensions, a formal deprecation policy and six SEPs hardening authorization to align with how OAuth 2.0 and OpenID Connect actually get deployed in production, including issuer validation per RFC 9207. The most tangible piece landed on June 18, when Enterprise-Managed Authorization went stable. EMA lets organizations control MCP server access centrally through their identity provider. Users log in once and inherit access to every approved server, with no per-app OAuth consent screens. Okta is the first supported IdP through Cross App Access. Anthropic implemented it across Claude, Claude Code and Cowork, Microsoft shipped it in VS Code, and MCP servers from Asana, Atlassian, Figma, Linear and Supabase support it at launch. EMA fixes something real. Before it, the typical enterprise pattern was a shared service account with a long-lived token in a .env file. No audit trail, no role scoping, no revocation path. EMA replaces that with IdP-governed access: group membership, conditional access rules, deprovisioning on offboarding. For anyone running agents in an enterprise, this is the most important practical improvement since my original article. What EMA answers is which humans in this org may connect to which servers. What it doesn't answer is which agent instance received which delegated authority to perform which specific action inside a chain of tools. Provisioning and governance improved dramatically. Per-action, per-instance identity did not. Research went where the protocols don't reach While the protocols hardened their edges, academic work attacked the middle. Two papers stand out. PAuth (arXiv 2603.17170, March 17) goes straight at overprivilege. Its argument: OAuth scopes are bound to operators, not operations. If your agent needs to transfer $100 to Bob, OAuth forces you to grant a blanket TRANSFER permission that covers any amount to any recipient. PAuth proposes task-scoped implicit authorization instead. Submitting a natural-language task authorizes only the concrete operations required to execute it faithfully. In the AgentDojo evaluation, all benign tasks complete without extra permissions and all injected attack operations trigger warnings, with zero false positives and zero false negatives. This is the operation-level policy layer I sketched in March, now with a working prototype. AIP (arXiv 2603.24775, March 25) is the most direct confirmation of the original thesis. The paper states that neither MCP nor A2A natively verifies agent identity, and cites a Knostic scan of roughly 2,000 internet-exposed MCP servers in which every single one lacked authentication. Its answer is Invocation-Bound Capability Tokens: an append-only chain that fuses identity, attenuated authorization and provenance into one cryptographic artifact, with bindings for MCP, A2A and plain HTTP. The measured overhead is 2.35ms in a real multi-agent deployment, 0.086% of end-to-end latency, with a 100% rejection rate across 600 adversarial attempts. AIP is now also an IETF Internet-Draft, which tells you where this conversation is heading. Around these two, a broader research cluster is forming: decentralized identity approaches built on DIDs and verifiable credentials, IETF drafts on attenuating authorization tokens for delegation chains, and work reframing the problem from "who are you" to "what portable authority can you prove". None of it is deployed at scale. All of it targets the layers the protocols still leave open. Scoring my March claims The original article made five claims. This is how they held up. Agents don't fit the identity models for humans, services or bots. Confirmed. Every serious paper published since starts from this exact insufficiency and proposes agent-specific frameworks. Delegation on behalf of a user is badly modeled *.* Confirmed, with nuance. MCP's authorization is still built on standard OAuth 2.1 flows. EMA improves the enterprise operation of those flows enormously without introducing universal agentic identity. Better plumbing, same conceptual gap. Multi-tool composition creates emergent privileges nobody approved. Confirmed and expanded. MCP elevated tool annotations as a risk vocabulary, threat modeling work flagged tool poisoning as a critical client-side vulnerability, and A2A added in-task authorization. The ecosystem now agrees this is where attacks live. You can't reliably audit who did what *.* Partially mitigated. Signed Agent Cards and AIP-style completion records add provenance. There is still no dominant standard for per-instance audit across stacks. The fix is a layered stack, not a single patch. Confirmed. MCP is building the authorization layer. A2A is building declarative identity and inter-agent trust. Research is building task scoping, verifiable delegation and portable authority. Nobody is shipping one magic fix, because there isn't one. The right question for July 2026 The question is no longer whether agents have an identity crisis. They do, and now everyone from protocol maintainers to IETF draft authors says so in writing. The right question is which parts of the stack finally exist and which parts remain aspirational. My answer today: enterprise authorization for MCP exists and works. A serious foundation for inter-agent trust exists in A2A v1.0. Measured proposals exist for task scoping and verifiable delegation. What still doesn't exist is the layer that binds them into an interoperable default: identity per running instance, authority that attenuates correctly across multi-hop delegation and provenance you can audit end to end without trusting every intermediary. In March I wrote that the best time to close this gap was before deployment, and the second best time was now. That line deserves an update. We're no longer starting from zero. We're starting from an ecosystem that finally admits, in specs and in code, that an agent can't keep being treated as a weird user or as just another service. An agent needs verifiable identity, bounded authority and auditable provenance. Until that's the default behavior in production, the crisis hasn't ended. It has started to professionalize. References Original article: AI Agents Don't Have Identities, and That's a Security Crisis (HackerNoon, March 2026) The 2026 MCP Roadmap (MCP Blog, March 9, 2026) A2A Protocol v1.0 announcement and What's New in v1.0 PAuth: Precise Task-Scoped Authorization For Agents (arXiv, March 17, 2026) AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A (arXiv, March 25, 2026) and IETF draft-prakash-aip The 2026-07-28 MCP Specification Release Candidate (MCP Blog, May 21, 2026) Enterprise-Managed Authorization: Zero-touch OAuth for MCP (MCP Blog, June 18, 2026)