The Identity Layer of AI Agents

Executive summary

As AI agents move from answering questions to taking autonomous action across real systems, a distinct engineering and policy problem has emerged: how does an agent prove who it is, what it is allowed to do, and on whose behalf it is acting. This is now referred to across industry and government as the “identity layer” for AI agents. In 2026, this went from a niche concern to a formal standards effort, a fast-growing vendor category, and the subject of at least one major real-world breach. This paper summarizes the current state of that landscape: the scale of the problem, the technical standards being built, the vendors competing to solve it, a documented failure case, and a gap that remains largely unaddressed — the difference between authenticating that an agent is authorized, and verifying whetheran agent's specific action actually reflects what the person it represents intended.

01 — Defining the identity layer

What the identity layer is

An AI agent's identity layer is the set of mechanisms that let it be recognized, authenticated, and governed as a distinct actor — separate from the human who deployed it and separate from the underlying model powering it. According to a framework published via IETF draft standards in March 2026, agent identity works through four layered mechanisms: cryptographic verification of who the agent is, per-agent access policies defining what it can do, audit trails recording what it did, and shared standards connecting these mechanisms across platforms.

This is a newer problem than it might first appear. Traditional software identity was built around two categories: human users and static service accounts. Autonomous agents do not fit cleanly into either. They act continuously rather than in a single session, they can chain actions across multiple systems without a human approving each step, and unlike a service account, their behavior is not fully predictable at the time credentials are issued.

02 — The scale of the problem

Machine identities are outrunning the tools to govern them

Machine and agent identities have expanded far faster than the tooling built to govern them. Multiple independently published 2025–2026 industry surveys converge on the same basic pattern, even though the specific ratios vary considerably by methodology:

• Palo Alto Networks' 2026 Identity Security Landscape report, based on a survey of nearly 3,000 cybersecurity decision-makers, found machine identities now outnumber human identities 109 to 1, up from 82 to 1 the year before — and that AI agents specifically account for about 72.5% of that machine identity population.
• KPMG's 2026 Cybersecurity Considerations report put the ratio at roughly 80 non-human identities for every human user in the average enterprise, and found that 92% of executives now rank managing AI agents as a top future security skill.
• Entro Security's research on cloud-native and DevOps environments specifically found a ratio as high as 144 to 1, up from 92 to 1 just eighteen months earlier.
• Averaging four independently published ratios produces a composite estimate of roughly 77–79 non-human identities for every human identity as of mid-2026.

The commercial response to this gap is itself measurable. The non-human identity access management market was valued at approximately $11.14 billion in 2025 and is projected to reach $27.33 billion by 2033, growing at a compound annual rate of roughly 11.9%. Growth is expected to be fastest in services rather than software licensing, reflecting how much of this problem currently requires custom implementation and governance work rather than an off-the-shelf fix.

03 — The technical standards landscape

A layered model, not one specification

Several overlapping standards efforts emerged or matured through early-to-mid 2026, generally converging around a layered model rather than one single specification.

04 — The vendor landscape

Everyone authenticates; no one verifies the data context

By the first half of 2026, at least six major identity vendors had shipped dedicated AI agent identity products: Okta, Microsoft Entra, Ping Identity, SailPoint, BeyondTrust, and Snowflake. A consistent critique across independent analysis of this vendor category is that essentially all of them currently address only the authentication and authorization layer — establishing who an agent is and which systems it is permitted to call — and none of them yet address the governed data context behind an agent's actions, meaning what information it actually drew on to decide what to do.

Microsoft's approach, Entra Agent ID, reached general availability in April 2026 after beginning as a preview at Microsoft Build 2025. It introduces dedicated identity constructs distinct from both human user accounts and traditional service principals, including an “agentUser” resource type designed specifically for agents that need to act as digital workers inside collaborative tools such as mailboxes and chat — a gap that previously forced developers to either misuse human accounts or accept that service principals cannot obtain the token types those APIs require. The platform also introduced “agent identity blueprints,” reusable templates that let organizations apply consistent security policy across large numbers of agent identities at once, and requires every agent identity to have a designated human sponsor accountable for its access and lifecycle. Okta's competing approach builds on the same OAuth and OIDC foundation used for human identity, adding agent-specific token vaulting and, as of mid-2026, a forthcoming feature for centralized cross-application consent.

05 — Case study

The Salesloft Drift breach

The clearest public demonstration of what happens when agent identity is handled poorly is the August 2025 breach involving Salesloft's Drift AI chat platform, which remained one of the most cited case studies in agent identity security discussion throughout 2026.

Attackers, tracked as the threat cluster UNC6395, first compromised one of Salesloft's internal GitHub repositories between March and June 2025, conducting reconnaissance over several months before acting. Inside that repository, they found a sensitive OAuth token that functioned as a master credential, granting Salesloft's own account privileged access into its Drift cloud application. Between August 8 and 18, 2025, the attackers used that stolen credential to authenticate as the trusted Drift integration and systematically query and export data from more than 700 downstream organizations that had connected Drift to their own Salesforce, Google Workspace, or Slack environments — including major security vendors such as Cloudflare, Google, PagerDuty, Palo Alto Networks, and Zscaler.

The specific failure mode is what makes this case relevant to the identity layer problem rather than a conventional breach. Because the attacker was operating through a legitimate, pre-approved OAuth integration, their queries were indistinguishable from Drift's normal, authorized chatbot activity — enterprises could see that Drift had access to their systems, but had no visibility into what that access was actually being used for at any given moment. Analysts have since characterized this as the defining lesson of the incident: identity systems that only verify that an agent is authorized, without any mechanism to evaluate whether a specific action is consistent with legitimate use, cannot detect this class of attack even in principle.

06 — The unaddressed gap

Authorization vs. verified intent

Taken together, the standards work, the vendor landscape, and the Drift case study point to a consistent pattern: essentially the entire current identity layer for AI agents is built to answer the question “is this agent allowed to do this,” not the question “does this specific action actually reflect what the person or organization behind the agent intended.” Every major framework covered here — AIMS, Entra Agent ID, Okta's OAuth-based approach, the DID/VC credentialing model — operates at the level of cryptographic proof of identity and static or role-based permission scopes.

This distinction matters more for personal and consumer-facing agents than for enterprise automation, because the actions in question are often irreversible in a personal, relational sense even when they are technically reversible in a system sense — a message sent in someone's voice to an investor, a client, or a family member cannot be un-sent in any way that matters, regardless of whether the underlying account access was properly authorized. The current identity layer, as built by NIST, IETF, Microsoft, and Okta, would not have flagged the Drift-style attack pattern, and by design it is not intended to evaluate whether a specific autonomous action taken by an otherwise properly authenticated agent is actually the action a person would have chosen. That remains open.