Agentic Identity Controls

Mapping the OWASP Top 10 for Agentic Applications to identity architecture

The OWASP Top 10 for Agentic Applications (2026) catalogs ten categories of risk specific to autonomous AI agents — but not all ten point toward the same kind of fix. Six of them describe failures that are fundamentally about how agent identity, credentials, and authorization are architected. This guide works through those six, across five sections, and maps each to a specific control.

The other four categories — ASI02 (Tool Misuse & Exploitation), ASI05 (Unexpected Code Execution), ASI06 (Memory & Context Poisoning), and ASI08 (Cascading Failures) — are real risks, but their primary mitigations live in input validation, execution sandboxing, and systems engineering rather than identity architecture. They aren't covered here.

ASI01 → ASI03: From goal hijack to confused deputy

The most common agentic-identity failure starts with ASI01 (Agent Goal Hijack) and ends with ASI03 (Identity & Privilege Abuse) — two categories that are easiest to understand as a single attack chain rather than two independent risks.

An attacker doesn't need to compromise an agent's credentials directly. They only need the agent to read something — a support ticket, a document, a tool response — that contains hidden instructions. If the agent's goal-setting logic treats that content as part of its task, its objective has been hijacked. What happens next depends entirely on what the agent is authorized to do.

In many early agent deployments, the agent's service account inherits the same permissions as the human user who invoked it, often with a margin added because provisioning one broad role is simpler than provisioning per-task roles. When the hijacked goal calls for a privileged action — export a user table, modify an IAM policy, delete a resource — the agent executes it with its own valid, high-privilege credentials. The agent becomes a confused deputy: a legitimate identity, doing something illegitimate, because nothing in the credential itself encoded what the agent was supposed to be doing at that moment.

Two controls close this gap, and they have to work together. Just-in-time (JIT) scoped tokens mean the agent's credential is valid only for the specific micro-task it's executing — a token issued for "summarize this ticket" simply doesn't include iam:* or export:users, regardless of what the agent's baseline role would otherwise allow. Dual-context token lineage means every privileged call carries two identities: the agent's, and the human's on whose behalf it's acting. If the human who submitted the ticket doesn't have permission to export the user table, the gateway blocks the call — even though the agent's own service account, in isolation, would have been allowed to make it.

Both are architecture patterns rather than shipping products, and turning them into runtime enforcement that survives real agent behavior is what the current wave of agent-access-control vendors is competing on. It is worth understanding how one early approach holds up against the confused-deputy case before standardizing on a single platform.

ASI04: Verifying MCP nodes in the agentic supply chain

ASI04 (Agentic Supply Chain Vulnerabilities) covers a different trust boundary: not what the agent is allowed to do, but who it's talking to while it does it.

Modern agents discover and call tools dynamically through protocols like the Model Context Protocol — the agent doesn't have a hardcoded list of approved endpoints; it asks an MCP server what tools are available and connects to whatever it's told. If that MCP server is compromised, spoofed, or simply an unvetted "shadow" node someone stood up for a side project, the agent will connect to it anyway — and hand over whatever session token or credentials it's currently holding.

The fix isn't about what the agent decides to trust. It's about removing the agent's ability to connect to anything that hasn't already proven its identity at the network layer, before any agent-level decision happens.

This control operates independently of the JIT-scoping and dual-context checks from the previous section — an agent holding a perfectly scoped, perfectly authorized token can still leak that token to a malicious MCP node if nothing verifies the node's identity before the connection is established. Both controls are necessary; neither substitutes for the other.

Implementation steps

ASI07: Insecure inter-agent communication

Once an organization has more than one agent, those agents start talking to each other — one agent's output becomes another's input, often with no human in the loop at all. ASI07 covers what happens when those messages aren't authenticated: a compromised or spoofed agent can inject messages into the chain, and a receiving agent has no way to tell a legitimate peer from an impostor.

This is structurally the same problem ASI04 solves for agent-to-tool connections, applied to agent-to-agent connections: the receiving agent needs to verify who sent a message before acting on it, independent of what the message claims about itself.

ASI09: Human-agent trust exploitation

ASI09 doesn't target an agent's credentials at all — it targets the human's trust in the agent's output. An agent that's been compromised, or whose goal has been subtly redirected, doesn't need to break any access control if it can simply persuade a human with the right permissions to take the action for it: approve this vendor payment, grant this service account admin access, disable this alert because it's a false positive.

This is an identity problem rather than a pure UX problem because the exploit works precisely when neither identity is doing anything wrong — the human really does have permission to approve the payment, and the agent really is the agent it claims to be. What's missing is a check on the action itself, not on either party's identity.

ASI10: Rogue agents

ASI10 covers agents that operate outside their intended policy — through compromise, through gradual drift as their context or fine-tuning changes, or through deliberate misalignment. What makes this an identity problem rather than purely a monitoring problem is the response: once a rogue agent is identified, how quickly can its access actually be cut off?

In many organizations, an agent's identity is provisioned once during initial setup and then left alone — the same pattern that created the orphaned-credential problem for human accounts, but recurring at the speed and scale of machine identities. An agent flagged as compromised but whose credentials remain valid for hours while a ticket works through an access-revocation queue has not, for practical purposes, been contained.

Where this breaks

This guide covers the architectural controls. The compliance landscape page covers why these controls increasingly determine cyber insurance eligibility and audit outcomes, and the audit and compliance mapping guide goes framework-by-framework on what auditors and underwriters actually look for. For vendors building toward dual-context token issuance, mTLS node verification, and agent identity lifecycle management, see the vendor index.