Identity Is the Missing Layer for AI Agents

February 23, 202615 min readAtypical Tech

Updated March 12, 2026

security agents identity safe-autonomy nist

Illustration for Identity Is the Missing Layer for AI Agents

Your cloud environment has 680,000 identities. Ninety-nine percent of them hold permissions they have never used. The fastest attackers are exfiltrating data in 72 minutes.

And you just gave your AI agent the same credentials as the engineer who deployed it.

This is not a hypothetical. It is the current state of agent identity governance — or, more precisely, the absence of it. Most organizations deploying AI agents have invested in prompt engineering, tool orchestration, observability, and cost controls. Almost none have addressed the question of who the agent is in terms the rest of the security stack can enforce.

NIST noticed. On February 5, 2026, the National Cybersecurity Center of Excellence published a concept paper titled Accelerating the Adoption of Software and AI Agent Identity and Authorization — the first serious federal attempt to define how identity and access management should work for autonomous AI systems. The public comment period closes April 2, 2026.

The paper proposes applying established identity standards — OAuth 2.0, SPIFFE, OpenID Connect — to a class of actors that most IAM systems were never designed to handle. It is a significant document. It is also, for most teams shipping agents today, an abstract one.

This post bridges the gap. We will walk through what the NIST paper proposes, why it matters now rather than later, and what it means for organizations building on the ROBOT framework.

Agents don't need new identity standards. They need existing identity standards applied to actors that don't have a login page.

The identity debt

Every agent system we have reviewed shares the same pattern. The agent authenticates to external services using one of three mechanisms: a long-lived API key stored in an environment variable, an OAuth token inherited from the deploying user, or a service account credential shared across multiple workflows.

In every case, the agent's effective permissions are a superset of what it needs for any given task.

This is not laziness. It is a structural consequence of how identity systems evolved. IAM was built for humans and, later, for services with predictable behavior. A web server that handles HTTP requests has a bounded set of actions it will perform. You can define its permissions precisely because its behavior is deterministic.

Agents are different. An agent's behavior is a function of its prompt, its tools, and its runtime context — all of which can change between invocations. The same agent that summarizes quarterly reports on Monday might be asked to query a production database on Tuesday.

Traditional role-based access control assumes stable roles. Agents have fluid capabilities.

RBAC was designed for actors who do the same job every day. Agents reinvent their job description every invocation.

The result is predictable: teams over-provision because scoping permissions to every possible task combination is impractical, and under-scoping breaks workflows. Unit 42's 2026 Global Incident Response Report quantifies the broader pattern — analyzing 680,000 identities across 18,000 cloud accounts, they found that 99% of cloud users, roles, and services held excessive permissions, many unused for 60 days or more. Identity weaknesses played a material role in nearly 90% of the incidents they investigated.

That is the baseline for human identities, where organizations have had decades of practice.

Agent identities are starting from further behind.

If you cannot define what your agent is authorized to do independently of what the deploying human is authorized to do, you do not have agent identity governance. You have identity inheritance.

What NIST is proposing

The NCCoE concept paper, authored by Harold Booth, Bill Fisher, Ryan Galluzzo, and Joshua Roberts, organizes the problem into four pillars.

Identification. Distinguishing AI agents from human users and from each other. This includes managing metadata about an agent's purpose, capabilities, and the degree of human oversight it operates under — from full human-in-the-loop approval to fully autonomous action. Without a consistent identification scheme, organizations cannot apply differentiated access policies to agents with different trust levels.

Authorization. Defining and enforcing what an agent is permitted to do. The paper references OAuth 2.0/2.1, policy-based access control, and NIST's own Next Generation Access Control (NGAC) framework. The critical point is that authorization must be dynamic — scoped to specific tasks, bounded in time, and revocable without disrupting the broader system.

Access delegation. Linking agent actions back to a human principal. This is the accountability chain: when an agent acts on behalf of a user, the system must preserve a verifiable link between the agent's identity, the delegating user's identity, and the specific action taken. The paper explicitly calls out the need to maintain oversight and accountability even as delegation chains grow longer.

Logging and transparency. Tying specific actions to specific non-human entities so that audit trails remain meaningful. This is harder than it sounds — when three agents share a service account, determining which agent performed which action requires identity-level granularity that most logging systems do not provide.

Three agents, one service account, and an incident response team that cannot tell you which one did it. That is the state of agent auditing today.

The paper does not prescribe a single solution. It surveys existing standards — SPIFFE for workload identity, SCIM for identity provisioning, NISTIR 8587 for token protection — and asks where the gaps are. An IETF Internet-Draft already extends OAuth 2.0 with specific parameters for agent delegation, introducing concepts like requested_actor and actor_token that separate the agent's identity from the delegating user's credentials.

This is the right framing. The problem is not that identity standards do not exist. The problem is that they were designed for actors with a login page. Extending them to actors that authenticate programmatically, act on variable instructions, and hold capabilities that shift between invocations requires deliberate adaptation — not new protocols, but new application of existing ones.

The NCCoE paper is not asking whether agents need identity governance. It is asking how existing standards should be adapted to provide it.

The evidence is already here

While NIST works on the framework, the consequences of the identity gap are arriving in production. We have been watching these incidents closely, and the pattern is unmistakable.

Credential theft is targeting agent toolchains directly

On February 22, 2026, Socket's threat research team disclosed SANDWORM_MODE — a supply chain worm targeting AI coding tools. The attack deploys rogue MCP servers into the configurations of Claude Code, Cursor, VS Code Continue, and Windsurf through 19 malicious npm packages. The fake servers register tools with innocuous names like index_project and lint_check that embed prompt injections to exfiltrate SSH keys, AWS credentials, and API tokens from nine LLM providers.

The attack works because the agent tools it targets have no identity layer between "this tool is configured" and "this tool has full access to the user's credentials." There is no verification of the tool's provenance, no scoped authorization for what the tool can access, and no delegation chain linking the tool's actions to an accountable principal.

The MCP server inherits the agent's permissions, which inherit the user's permissions, which were over-provisioned to begin with.

This is the identity debt compounding.

Permission inheritance is a convenience that becomes a vulnerability the moment your toolchain includes something you didn't write.

Enterprise AI inherits enterprise over-provisioning

The pattern extends to managed enterprise environments. Varonis Threat Labs disclosed "Reprompt" — a single-click attack against Microsoft 365 Copilot that exploits parameter-to-prompt injection to exfiltrate personal data. The attack bypasses Copilot's safeguards through a double-request technique and requires no plugins or user interaction beyond one click.

The underlying vulnerability is not in Copilot's model or its prompt handling. It is in its permission model. Copilot inherits the application permissions of the M365 tenant, which — as Microsoft's own security researchers acknowledge — means an agent's capabilities are "effectively equivalent to code execution in the environment."

When the environment's permissions are over-provisioned, the agent's blast radius expands accordingly.

The exfiltration window has collapsed

Even if organizations detect credential compromise quickly, the response window has narrowed dramatically. Unit 42's 2026 report found that the fastest quarter of intrusions reached data exfiltration in 72 minutes — down from 285 minutes in 2024, a four-fold acceleration. In some cases, exfiltration occurred in under five minutes.

When attackers move that fast, identity misconfiguration is not a compliance finding. It is a live exposure.

An agent operating with inherited, over-provisioned credentials in a 72-minute-response environment is an accelerant, not a tool.

The question is not whether your agents will be targeted. It is whether your identity architecture can distinguish between an agent performing its assigned task and an agent whose tool chain has been compromised.

What this means for ROBOT

The ROBOT framework organizes agent governance into five pillars: Role, Objectives, Boundaries, Observability, and Taskflow. Identity governance intersects three of them directly.

ROBOT Pillar	Identity Requirement	Current Gap
Role	Every agent must have a unique, verifiable identity distinct from its deploying user. The Role pillar requires named ownership — accountability stays human. Identity governance is how you enforce that chain technically.	Most agents authenticate as their deploying user or share service accounts. No unique identity means no attributable actions.
Boundaries	Agent permissions must be scoped to specific tasks and bounded in time. The Boundaries pillar requires that interfaces define capability and risk. Identity is the enforcement mechanism for those boundaries.	Permissions are typically static and over-provisioned. No just-in-time scoping. No per-task authorization.
Observability	Audit trails must link actions to specific agents, not shared credentials. The Observability pillar requires that you can reveal what the agent did and why.	When agents share credentials, audit logs show what happened but not who (which agent) did it.

The NIST paper's four pillars — identification, authorization, access delegation, and logging — map cleanly onto these ROBOT requirements. Identification addresses the Role gap. Authorization and access delegation address the Boundaries gap. Logging addresses the Observability gap.

What the NCCoE paper adds that ROBOT frames as a requirement but does not specify is the protocol layer — the specific standards and mechanisms (OAuth 2.0, SPIFFE, SCIM) that translate governance requirements into enforceable technical controls.

Governance tells you what the rules should be. Identity infrastructure tells you how to enforce them at runtime.

Defensive patterns

The standards landscape is converging. Here is what is actionable today.

Unique agent identity per deployment

Every agent instance should have its own identity — a distinct credential set, a unique identifier in your IAM system, and a verifiable link to the human who authorized its deployment. SPIFFE provides a production-ready framework for this: cryptographically verifiable workload identities using short-lived X.509 certificates or JWTs, scoped to specific trust domains. SPIFFE IDs are workload-centric (not person-centric), which makes them architecturally suited for agents whose lifecycles are ephemeral and whose capabilities vary between invocations.

HashiCorp has already integrated SPIFFE support into Vault Enterprise for non-human identity workloads, including AI agents. The tooling exists. The adoption gap is organizational, not technical.

Per-task credential scoping

Static, long-lived API keys are the agent equivalent of a master password. Replace them with short-lived tokens scoped to specific tasks.

The IETF draft on OAuth 2.0 for AI agents introduces the requested_actor and actor_token parameters that enable this pattern: the agent proves its identity separately from the user's, requests only the permissions needed for the current task, and receives a time-bounded token.

The design principles in the draft are explicit: clear identity separation, least privilege, just-in-time consent, and full auditability. These are not new principles. What is new is their application to agents that negotiate permissions programmatically rather than through a consent screen.

Delegation chain verification

When an agent acts on behalf of a user, the delegation chain must be verifiable end-to-end. This means: the user's identity is authenticated, the agent's identity is authenticated separately, the delegation grant is time-bounded and scope-limited, and the resulting actions are logged with both identities attached.

This is the access delegation pillar from the NCCoE paper, and it maps directly to the ROBOT framework's accountability requirement. An accountability proxy — a named human who owns the agent's actions — is the governance control. The delegation chain is the technical implementation of that control.

Tool provenance verification

SANDWORM_MODE exploits the absence of identity at the tool layer. The fix is to apply the same identity rigor to tools that you apply to agents: verify tool provenance before execution, scope tool permissions independently of the agent's permissions, and log tool-specific actions in the audit trail.

The NCCoE paper references the Model Context Protocol (MCP) as relevant infrastructure for agent-tool interaction. MCP currently lacks built-in identity verification for tools. Until it does, organizations deploying MCP-connected agents should treat every MCP server as an untrusted input source — the same principle that the interface security imperative applies to every external integration point.

If your agent's toolchain includes something you didn't build, you are trusting someone else's code with your credentials. That trust needs verification, not faith.

The comment window

The NCCoE concept paper is not a regulation. It is a call for input — a scoping exercise for a potential demonstration project that would show how existing identity standards can be adapted for AI agents. The public comment period closes April 2, 2026, with comments directed to AI-Identity@nist.gov.

Separately, NIST's Center for AI Standards and Innovation (CAISI) launched an AI Agent Standards Initiative on February 20, covering standards development, open-source protocol work, and agent security research. A parallel request for information on AI agent security is due March 9.

These are not routine administrative procedures. They are the standards-setting process for how agent identity will work across the industry.

Organizations that engage now will shape the standards they will later need to comply with. Organizations that wait will inherit constraints designed by others.

Standards are written by the people who show up. If you are deploying agents, this is your window to show up.

Start here

If you are deploying AI agents in production — or planning to — evaluate your current identity posture against three questions:

Can you distinguish your agent's actions from your human users' actions in an audit log? If your agents authenticate using shared service accounts or inherited user credentials, the answer is no. Start by assigning unique identities to each agent deployment.
Are your agent's permissions scoped to what it needs for its current task, or to everything its deploying user can access? If the latter, you have identity inheritance, not identity governance. Implement per-task credential scoping, even if it starts with manual token rotation.
If a tool in your agent's chain were compromised tomorrow, could you trace which agent used it, what it accessed, and who authorized the deployment? If your delegation chain has gaps, SANDWORM_MODE-style attacks will exploit them. Verify tool provenance. Log delegation chains end-to-end.

The Safe Autonomy Readiness Checklist covers these controls and 40 more across 8 governance dimensions — from identity and access management to kill switches and rollback procedures.

If your organization is preparing a public comment for the NCCoE by April 2, or if you want help assessing your agent identity posture against the NIST framework, we should talk.

Contact Atypical Tech

References

NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization — Concept paper by Harold Booth, Bill Fisher, Ryan Galluzzo, and Joshua Roberts. Published February 5, 2026.
NIST NCCoE, Software and AI Agent Identity and Authorization Project Page — Project overview and public comment instructions.
NIST CAISI, Announcing the AI Agent Standards Initiative — Three-pillar initiative covering standards, open-source protocols, and research. February 20, 2026.
Palo Alto Networks / Unit 42, 2026 Global Incident Response Report — 680,000 identities analyzed across 18,000 cloud accounts. 99% excessive permissions. Fastest-quartile exfiltration at 72 minutes.
Socket Threat Research Team, SANDWORM_MODE: npm Worm Hijacks CI Workflows and Poisons AI Toolchains — Supply chain worm deploying rogue MCP servers into AI coding tools. February 22, 2026.
Varonis Threat Labs, Reprompt: The Single-Click Microsoft Copilot Attack — Parameter-to-prompt injection exploiting M365 Copilot permissions.
Microsoft Security Blog, From Runtime Risk to Real-Time Defense: Securing AI Agents — Microsoft's own research on agent capabilities as code execution equivalents.
IETF, OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents — Internet-Draft introducing requested_actor and actor_token parameters for agent delegation.
SPIFFE, Secure Production Identity Framework For Everyone — CNCF graduated project for cryptographically verifiable workload identity.
HashiCorp, SPIFFE: Securing the Identity of Agentic AI and Non-Human Actors — SPIFFE integration in Vault Enterprise for agent workloads.
NIST, NISTIR 8587: Protecting Tokens and Assertions from Forgery, Theft, and Misuse — Token protection guidance applicable to agent credential management.
NIST, Next Generation Access Control (NGAC) — Policy-based access control framework referenced in the NCCoE concept paper.