Can AI agents prove who they are and what they're allowed to do, using identity tools we already have?

This explores whether NIST's plan to reuse existing identity standards for AI agents can fix the practical problem of agents proving who they are and what they're allowed to do across services they don't own. The short answer from the corpus is that it handles part of the problem well. The rest is about who gets to see, refuse, and profit from agent traffic, and identity standards don't settle that.

NIST's starting point is conservative on purpose. Its NCCoE concept paper argues against inventing new protocols. It wants to apply OAuth 2.0/2.1, OpenID Connect, and SPIFFE/SPIRE to agents, and it names five priority areas: identification, authorization, delegation, logging, and data flow tracking Can existing identity standards work for AI agents?. That bet is better grounded than it might look. MCP, one of the most widely adopted agent protocols, already uses these standards as its foundation. Research on agent coordination finds that standards spread by wrapping and bridging the protocols people already run, not by replacing them Should coordination protocols wrap existing systems or replace them?. Academic work shows how far the existing tools can stretch: a three-token scheme (a user ID, an agent ID, and a delegation token signed by the human) extends OAuth and OpenID Connect so that any service can check who authorized an agent, what it may do, and whether that permission has been revoked How can AI agents prove who authorized their actions?.

The Amazon–Meta Muse dispute shows where this approach runs out. Amazon blocked Meta's shopping agent through its terms of service, not through any negotiated protocol. The argument drawn from that case is that agents need a standard way to identify themselves to merchants, which is a different problem from keeping consumers' credentials safe What identity standards do shopping agents actually need?. OAuth-style delegation can prove that a user authorized an agent. It can't make a retailer accept that agent. Interoperability fails here for commercial reasons: a technically valid agent can still be turned away.

The reused standards also bring a side effect their own proposers point out. If every agent authenticates through an OpenID Provider such as Google or Facebook, that provider can watch and profile agent activity across every service the agent touches Do OpenID Providers gain surveillance power over AI agents?. A design meant as a security fix ends up concentrating visibility in a few identity gatekeepers, so choosing a standard also means deciding who gets to observe the agent economy.

The wider framing is that identity is one layer of a larger infrastructure stack. Chan et al. describe agent infrastructure as doing three jobs: attributing actions to agents, shaping how agents interact, and detecting and fixing harm What infrastructure must exist beyond training agents?. NIST's standards cover the first job well and the third only partly, through logging. Shaping interactions, meaning which agents may deal with which services and on what terms, is closer to what classical multi-agent systems research calls institutional design: protocols, mechanism design, and explicit norms Can classical agent architectures fix agentic AI accountability?. So NIST's approach can remove the technical barrier to agents proving who they are. The barriers left over are about trust and market access, and identity plumbing on its own won't remove them.