AI Agent Identity Standards and the Emerging Agent Identity Layer

Human identity has one thing going for it that no spec ever had to invent: continuity. A person wakes up, goes to work, changes roles, and is still recognizably the same person a login system can track over years. That biological fact is the quiet foundation under every major identity system built since the 1990s.

Agents don't get that continuity, and pretending otherwise is where most of this goes wrong. They're nondeterministic: the same model weights fed the same input can produce different output on different runs, so a credential that confirms what an agent is tells you nothing about what it's about to do. They're also cloneable. Copy the weights, spin up five more instances, and there's no hardware-level way to say "this is the one true agent" without tying identity to physical infrastructure, which almost nobody does yet. Agents are also often sessionless, with no memory between calls by default, so there's no stable thing to anchor identity to in the first place. The session model behind OAuth and SAML, a person opens a browser, logs in, does stuff, logs out, doesn't map onto a process that acts on its own and chains calls across a dozen services and sub-agents inside a single task.

You cannot patch this by bolting extra scopes onto an existing OAuth flow. Authenticating the container (a token, a certificate, a signed agent card) is not the same as authenticating the content, which includes the model weights, the system prompt, and the actual intent behind the next tool call. Nothing on the market checks that second thing today. Call this what it is: a structural mismatch between what identity infrastructure was built to check and what an agent actually is, not a gap some vendor forgot to close.

The attack surface that opens when agents operate on credentials built for a different threat model

Give an agent a credential built for a different threat model and attackers stop guessing passwords. They redirect behavior instead. The whole game now is cheaper than the one it replaced.

The credentials sitting underneath all of this are themselves the weak point. Long-lived secrets aren't a hypothetical risk sitting in a slide deck somewhere. They're sitting in repos, working, right now, scoped far wider than the task that ever needed them. Overprivileged agents and secrets that never expire are the two categories that let an attacker walk straight past whatever restrictions were supposed to apply, because the restriction existed only as an assumption, never as an enforced control.

The attack techniques that exploit this are specific: indirect prompt injection, where a poisoned tool response redirects what an agent does next; memory poisoning; identity spoofing between agents; supply-chain attacks aimed at the tools agents call. An agent with permission to draft and send email can be talked into exfiltrating data through that same inbox. An agent with database query access can get steered, via a booby-trapped response from some other tool, into altering records outside its intended scope. None of this requires breaking encryption or guessing a password. It just requires convincing the agent that the next step is the one it was supposed to take anyway.

The failure modes aren't always single-agent, either. Multi-agent systems can produce deceptive or collusive behavior that no one explicitly rewarded, because the deception lives in the interaction between agents, not in any one component. Trace the root cause across all of it and it comes back to the same two things: agents running without a forensic trail of what they did and why, on credentials scoped to their container instead of their task. Fix the credential model and most of what follows gets fixed with it. Leave it, and every other control is decoration.

Where the standards landscape currently stands and what it leaves unresolved

Governments and standards bodies noticed, eventually. Several parallel efforts are now underway to stitch together existing pieces, OAuth 2.0, SPIFFE/SPIRE, MCP, OIDC, SCIM, into something that looks like formal guidance for agentic systems, alongside proposed control overlays for single-agent and multi-agent deployments that could eventually feed into broader compliance frameworks.

Internationally, ISO/IEC 42001 sets requirements for an AI management system, with companion standards adding impact assessments and defining who's qualified to audit against them, together pointing toward AI governance that's checkable by someone other than the vendor grading its own homework. The Cloud Security Alliance has published its own AI Controls Matrix with a dedicated domain for identity and access management. On the regulatory side, financial-sector rules already in force across the EU impose obligations directly relevant to any bank connecting agents to outside services or MCP integrations. Regulated industries are among the most exposed to gaps in agentic identity governance, which is where the compliance pressure is most concentrated.

Here's the honest part: existing control families cover identity, access, audit, and supply-chain risk in general terms, but none of them were written with a way to tell an AI agent apart from a human operator, scope its permissions to the task it's doing right now, or trace an action back to a non-human principal for forensic purposes. The framework predates production-scale agent deployment, full stop. Enterprises shouldn't wait for a finished version of any of this. The draft guidance already circulating signals where auditors and regulators are going to point next, and that's close enough to build against.

The five structural gaps that no current standard or product fully closes

Strip away the acronyms and five gaps remain open across every current approach.

First, nothing verifies semantic intent. Current mechanisms check the token or the certificate, the container, not whether the tool call an agent is about to make actually matches the task it was granted access for. Second, recursive delegation has no accountability trail. When one agent spawns three sub-agents, and one of those spawns two more, nothing standardized tracks that chain, so responsibility evaporates as the depth increases. Third, there's no enforced sense of agent identity integrity: agents are nondeterministic and cloneable, and a credential tied to a model's weights at one moment says nothing about its behavior the next.

Fourth is disclosure, and it's worse than it sounds. Most production agents have no documented default behavior for announcing that they're an AI agent at all, and only a small fraction publish anything stable enough, a User-Agent string, a fixed IP range, to let anyone verify agent traffic against a known source. Fifth, there's no bound on operational cost. Unbounded agentic interactions can spiral into runaway resource consumption, and no identity standard in wide use today has a native way to cap it.

The disclosure problem and the governance problem feed each other. If an agent doesn't identify itself and blends into ordinary traffic, no policy engine has anything to grab onto in the first place. No single standard ties attenuable delegation, cross-protocol credential binding, and provenance tracking into one working protocol. The market is patching this together out of OAuth 2.1, SPIFFE/SPIRE, and assorted agent-card formats, and none of them fully compose with each other yet.

The underlying design flaw is simpler than the acronym soup suggests. Without a formal separation of powers, a single agent can plan its own action, execute it, and then grade itself on how well it did. Call it a logic monopoly. It leaves safety resting entirely on the alignment of one model instead of on any institutional check outside it, a bet no bank would ever take with a human employee.

What MCP's authentication evolution reveals about the gap between protocol adoption and governed deployment

Model Context Protocol is the closest thing the agent ecosystem has to a common language, and its authentication history is a case study in standards outrunning governance. Anthropic released MCP in November 2024, and adoption since then has been fast enough to make the auth story look almost like an afterthought bolted on after the fact. It's now backed by every major AI lab and governed as a founding project of the Agentic AI Foundation under the Linux Foundation, making it the dominant interoperability layer in the space.

Enterprise usage is climbing fast enough to make procurement teams nervous. Datadog, Figma, Atlassian, and Salesforce have all reported sharp jumps in MCP tool calls and write usage over recent quarters, the kind of growth curve that outruns any team's ability to review what's actually flowing through it.

Auth hasn't kept pace with any of that. Most live deployments still run on long-lived tokens or API keys that operate outside the governance of a corporate identity provider. The spec has been trying to fix this: recent revisions introduced explicit OAuth 2.1 authorization server requirements, making MCP servers formal OAuth 2.1 resource servers, with clients required to implement Protected Resource Metadata for discovery and token scoping tied to a specific destination. A newer Enterprise-Managed Authorization extension goes further still, making the enterprise identity provider the central authority: a user logs in once through their existing IdP, and the IdP becomes the central authority governing which MCP servers that user can access.

The spec is well ahead of the deployments running on it. Much live MCP traffic today still runs on the older token model the newer revisions were built to replace, and that gap between spec and practice is the whole story here, not a footnote to it. Protocol adoption doesn't wait for governance. The distance between what agents are doing in production and what security teams can actually see keeps widening, not shrinking.

How the MCP gateway category emerged as the practical enforcement point between agents and tools

Connecting agents directly to dozens of MCP servers doesn't scale, and the protocol specifies the interface while leaving policy to be solved separately, by someone, eventually. Connect N agents to M tools directly and the result is N times M custom integrations, each with its own auth flow, its own error handling, its own way of quietly failing at 2 a.m. A gateway collapses all of that into one governed choke point that every request has to pass through, which is the entire point of a choke point.

The category arrived with a specific product launch that turned "MCP gateway" from a whiteboard idea into a shipping line, and analyst firms followed shortly after by naming "agent control plane" as its own emerging market category: infrastructure that inventories, governs, orchestrates, and checks agents across vendors and domains.

A gateway that actually does the job, as opposed to a proxy with MCP logging bolted on, handles four things. It authenticates inbound requests using OAuth 2.1. It checks policy against the full context of a request before any tool executes, not after the fact. It swaps in its own credentials for outbound calls to backend systems, so an agent's token never actually reaches the system it's calling. And it logs the full exchange for audit and forensic use later, when someone inevitably needs to reconstruct what happened and why.

The test that separates a real gateway from a rebranded proxy is simple: can the vendor say, in writing, exactly how per-tool policy gets enforced? If not, it's logging traffic, not governing it, and a fair number of products marketed as "MCP gateways" turned out to be exactly that once someone asked the question directly. On the policy side, the leading products have converged on policy-as-code rather than configurable menus meant for manual review, publishing rule sets that can be versioned and reviewed the same way application code is.

The vendors defining the MCP gateway and agent

The market splits along a fairly clean line: cloud-native gateways bundled into an existing platform, versus standalone control-plane products built to sit across multiple clouds and multiple agent frameworks at once. Bet on the standalone layer outlasting the bundled one, for the same reason API management never stayed locked inside a single cloud vendor's console: the moment a company runs agents across two clouds, a gateway tied to one of them becomes a second thing to govern instead of the thing doing the governing.

AWS's Bedrock AgentCore Gateway is tightly integrated with its own stack and built for teams already committed to it. Some vendors extend existing API gateway infrastructure into policy enforcement for agent-to-tool communication, leaning on tooling that API teams already know how to operate. Independent control-plane vendors are building specifically around the OAuth 2.1 and resource-indicator requirements in the newer MCP spec, betting that enterprises running agents across more than one cloud will want a governance layer that doesn't belong to any single provider.

None of these approaches has won outright, and it's early enough that "won" may be the wrong frame entirely. What's clear is the shape of what a serious buyer should check for: policy enforcement per tool call, not per session; credential substitution so agent tokens never touch backend systems directly; audit logging detailed enough to survive a forensic review after something's already gone wrong. Anything short of that is a proxy wearing a gateway's name tag, and the difference matters most on the day an agent gets talked into doing something outside its scope, which, given everything above, is not a matter of if.