OWASP ASI03 Explained: AI Agent Identity & Privilege

TL;DR

OWASP ASI03 ("Identity and Privilege Abuse") is item 3 of the OWASP Top 10 for Agentic Applications 2026. It covers attacks where AI agents lack distinct identity governance, enabling permission misuse, unauthorised delegation, or cross-boundary access.
The class fires when agents share identities across users or tenants, when tools inherit excessive host privileges, when delegation chains are unaudited, and when authentication mechanisms equate "local connection" with "authenticated principal".
Real-world ASI03 incidents include the Asana MCP cross-tenant access bypass (June 2025), CVE-2025-49596 (MCP Inspector) by mechanism, and a recurring pattern across MCP servers that run with the developer's full UID and credential store.
ASI03 overlaps with ASI02 (Tool Misuse) on over-privileged tools and with ASI04 (Agentic Supply Chain) on connectors that import their installer's identity. The fix layers are different.
Mitigation requires distinct agent identities, scoped delegation, and explicit authorisation at every privilege transition — not "the agent inherited my session, that's fine".

What ASI03 actually says

OWASP ASI03 names the threat class where AI agents use, share, or escalate identities and privileges without proper governance. The standard framing: agents are increasingly granted authority over real systems (file systems, networks, credentials, signing keys, on-chain assets), and the way that authority is modelled in production deployments is often inadequate. Agents inherit user identities by default. They share session tokens across multi-user contexts. They delegate to sub-agents without recording the delegation. They cross tenant boundaries that the underlying systems were supposed to isolate.

Three principal failure modes inside the category:

Shared identity across users. A multi-tenant agent platform shares connection state, cached tokens, or context across users — so user A's authority bleeds into user B's session. The Asana MCP cross-tenant case is the canonical example.

Inherited host privilege. An MCP server runs with the host's UID, environment variables, and credential store. The agent's effective authority is therefore the union of every tool's authority and the host's full identity. This is usually invisible to the operator who thought they were granting the tool a narrow set of capabilities.

Implicit delegation. Agents call sub-agents, sub-tools, and external services with the same authority they hold themselves, without recording the delegation chain. Audit becomes impossible because every action looks like it came from the same identity regardless of which agent in the chain actually decided to take it.

Real-world ASI03 incidents

The disclosed-incident record from 2025–2026 contains several findings that fit cleanly inside ASI03, drawn from the MCP Breach Index 2025–2026:

Asana MCP cross-tenant access bypass (June 2025)

The Asana MCP server's tool authority was over-broad: a single connection could read across tenant boundaries that should have been isolated at the tool level. This is the textbook ASI03 case — identity governance failed because the agent inherited authority that crossed customer boundaries. The fix was scope-narrowing on the server side, but a properly-architected host would also have enforced per-tenant identity governance independent of the connector's claims.

CVE-2025-49596 (MCP Inspector, by mechanism)

The Anthropic MCP Inspector vulnerability detailed in the MCP Inspector RCE writeup is primarily an ASI05 finding by impact (RCE), but the mechanism is pure ASI03: the inspector treated "local network connection" as authentication, conflating reachability with identity. Every CVE that follows the local-network trust assumption pattern has an ASI03 component.

Inherited-developer-credential pattern (multiple)

Across the disclosed-CVE record, a recurring pattern is MCP servers that run as the developer's UID and inherit their git credentials, AWS tokens, signing keys, and active session tokens. RCE in any such server is therefore credential exfiltration plus operator-equivalent execution. This is not a single CVE — it is the structural ASI03 failure that makes RCE-class CVEs much worse than they would be in well-isolated deployments.

Why MCP makes ASI03 worse

Three properties of MCP architecture amplify ASI03 risk:

STDIO-spawned servers inherit host identity by default. The official MCP SDKs spawn child processes that share the host's UID, environment, and filesystem authority. The operator who connected the server typically has no awareness that they granted the server full host identity rather than a scoped tool authority.

Cross-server connection sharing. When multiple MCP servers connect to the same agent host, they often share session state, cached tokens, and configuration context. A compromise of one server's authority can bleed into another's through the shared context.

Implicit user-level identity. Most agent runtimes do not distinguish between "the agent acts on the user's behalf" and "the agent acts as the user." The two are operationally different — the first is a delegation that should be audited and bounded; the second is identity sharing that should never happen.

Detection and mitigation

Defending against ASI03 requires explicit identity governance at every privilege transition. The four operational controls below cover the disclosed-incident record:

1. Distinct agent identities. The agent should have its own identity, separate from the user's. Tools authorise the agent's identity, not the user's. Where the agent's actions affect the user's data, the access should be a scoped delegation that can be revoked, audited, and bounded.

2. Constrained host inheritance. MCP servers should run with the minimum credentials and environment they need. Dedicated UIDs, scoped environment variables, no inheritance of git tokens or credential stores by default. The exception (the developer specifically wants the server to use their credentials) should be explicit, scoped, and recorded.

3. Explicit delegation recording. Every sub-agent call, every tool invocation, every external API call should record the identity chain. Who decided to take this action, with what authority, and at what point in the agent's reasoning?

4. Per-tenant identity at host level. Multi-tenant deployments should enforce tenant scoping at the host level, not trust the connector's claims. The Asana MCP bypass would have been blocked by host-level per-tenant identity governance regardless of what the server itself enforced.

For Web3 deployments specifically, the rule is unconditional: agents that hold transaction-signing authority must have a distinct identity from the user, and every signing action must record the delegation chain. Treating "the agent signed because the user authorised it once" as ongoing authorisation is an ASI03 failure that produces fund loss the first time the agent is goal-hijacked.

How Zealynx audits for ASI03

A Zealynx MCP Security Audit treats ASI03 as an identity-governance audit. The five focused tests:

Identity-graph enumeration. For every actor in the deployment (user, agent, sub-agent, tool, MCP server), what identity does it hold? What authority does that identity grant?
Privilege-inheritance audit. For every MCP server and connected tool, what privileges does it actually inherit from the host? Does the operator know?
Delegation-chain trace. For a representative set of agent actions, can the audit trail reconstruct who decided, with what authority, and at what point?
Multi-tenant boundary test. In multi-tenant deployments, can a single connection read or write across tenant boundaries the underlying systems were supposed to isolate?
Authentication-vs-reachability test. For every local port, IPC channel, or trust-assumption surface, is "reachability" being equated with "authentication"?

Findings map to ASI03 plus relevant downstream items.

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.

FAQ

1. What is OWASP ASI03 in one sentence?

OWASP ASI03 (Identity and Privilege Abuse) is item 3 of the OWASP Top 10 for Agentic Applications, covering attacks where AI agents lack distinct identity governance — sharing identities across users or tenants, inheriting excessive host privileges, performing implicit delegation without audit, or equating "local connection" with "authenticated principal".

2. What real-world incidents fit ASI03?

ASI03 incidents documented in the MCP Breach Index 2025–2026 include the June 2025 Asana MCP cross-tenant access bypass (the canonical multi-tenant identity failure) and CVE-2025-49596 (MCP Inspector) by mechanism (treating "local network connection" as authentication). The broader inherited-developer-credential pattern across MCP servers running with the developer's UID is a recurring structural ASI03 failure that makes RCE-class CVEs significantly worse.

3. Why do MCP servers typically run with developer credentials?

MCP servers typically run with developer credentials because the official MCP SDKs spawn child processes via STDIO transport that inherit the host's UID, environment variables, and credential store by default. The operator who installs the server usually does not realise they have granted the server full host identity rather than a scoped tool authority. The fix requires explicit configuration to constrain the server's environment — dedicated UIDs, scoped environment variables, no auto-inheritance of git tokens or AWS credentials.

4. How does ASI03 differ from ASI02 (Tool Misuse)?

ASI02 is about runtime tool use — over-privileged tools, ambiguous descriptors, unsafe composition. ASI03 is about identity — who the agent is, who tools think it is, what authority that identity grants. They overlap on over-privileged tools (ASI02 names the runtime issue, ASI03 names the identity-governance failure that produced the over-privilege). A complete audit reports findings under both items where both apply.

5. How do I prevent multi-tenant identity bleed?

To prevent multi-tenant identity bleed, enforce per-tenant scoping at the host level rather than trusting connector-level enforcement, ensure agent identities are distinct from user identities, require explicit re-authorisation at every tenant boundary the agent crosses, and audit the actual cross-tenant accessibility of every connected tool against intended boundaries. The June 2025 Asana MCP bypass would have been blocked by host-level per-tenant identity governance independent of the connector's claims.

6. What is "implicit delegation" in agent contexts?

Implicit delegation is the pattern where an agent calls sub-agents, sub-tools, or external services with the same authority it holds itself, without recording the delegation chain. The audit problem: every downstream action looks like it came from the original identity regardless of which agent in the chain decided to take it. Post-incident reconstruction becomes impossible. The fix is to record the delegation graph — who decided to take this action, with what authority, at what point in the reasoning chain — and to bound delegations explicitly rather than allow unrestricted authority propagation.

7. What is the rule for Web3 deployments under ASI03?

For Web3 deployments, the unconditional ASI03 rule is that agents holding transaction-signing authority must have a distinct identity from the user, and every signing action must record the delegation chain. Treating "the agent signed because the user authorised it once" as ongoing authorisation is a structural failure that produces fund loss the first time the agent is goal-hijacked. Each signing action requires explicit, per-action authorisation that surfaces the transaction's full effect to the user.

8. How does Zealynx audit for ASI03?

Zealynx's MCP Security Audit tests for ASI03 across five dimensions: identity-graph enumeration (mapping every actor and the authority each holds), privilege-inheritance audit (verifying each MCP server's actual inherited privileges), delegation-chain trace (confirming audit trails can reconstruct who decided what), multi-tenant boundary tests (verifying tenant isolation holds), and authentication-vs-reachability tests (catching cases where "local connection" is equated with "authenticated principal").

Glossary

Term	Definition
Identity Inheritance	The pattern where an MCP server or AI agent component automatically receives the identity, credentials, and authority of its parent process or installer — typically without the operator explicitly granting that authority.
Implicit Delegation	The pattern where AI agents call sub-agents, sub-tools, or external services with the same authority they hold themselves, without recording the delegation chain. Makes post-incident reconstruction impossible and unbounded authority propagation invisible.
Multi-Tenant Boundary	The security boundary between distinct customer or user tenants in a shared system. In MCP-connected agents, this boundary must be enforced at the host level rather than trusting connector-level enforcement, since a compromised connector cannot be trusted to enforce its own scoping.

View complete glossary →

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.