OWASP ASI03: when an agent inherits more identity than it should
Identity & Privilege Abuse is the #3 risk in OWASP's Top 10 for Agentic Applications. Agents rarely get their own identity — they inherit yours, accumulate permissions, and hold tokens that outlive the task.
What is this?
ASI03 — Identity & Privilege Abuse is the third entry in the OWASP Top 10 for Agentic Applications, the agentic security benchmark published by the OWASP GenAI Security Project’s Agentic Security Initiative (the list was introduced in December 2025). The category received a dedicated deep-dive on June 25, 2026 from Adversa AI, which is what prompts this defensive walkthrough.
ASI03 names the class of risk that arises when an AI agent accumulates, inherits, or exploits credentials and permissions beyond its intended operational scope. It complements our coverage of ASI02 — Tool Misuse & Exploitation and ASI06 — Memory & Context Poisoning, and rounds out how the framework decomposes agent risk. OWASP ranks identity abuse at #3 for a structural reason: it sets the blast radius for every other entry. A goal hijack or a tool misuse is only as damaging as the credentials the agent happens to be holding when it fires.
How it works
The core problem, stated plainly across the OWASP material and the Adversa and CSA write-ups, is that agents rarely get their own identity — they inherit yours. Three properties make that dangerous.
1. INHERITED the agent runs under a human's or service's
credentials, not a scoped identity of its own
2. ACCUMULATED permissions pile up across tool calls and sessions
instead of being granted per-task and released
3. PERSISTENT tokens and delegated sessions outlive the task that
needed them, sitting around to be reused or stolen
An agent’s identity becomes an aggregation point: it encompasses not only the agent’s own provisioned credentials, but any tokens, API keys, or delegated sessions it picks up through tool invocations, API responses, or injected context. None of this requires a classic software exploit. The mechanism is the agent’s ordinary operation — it asks for what it needs, is granted more than it needs, and never gives it back.
That aggregation is what makes the category attractive to an attacker, and it is why ASI03 sits downstream of other risks. A prompt injection (LLM01) or a sensitive-information disclosure (LLM02) becomes far more serious when the agent it lands on is carrying broad, long-lived credentials. As OWASP frames it, compromising one over-privileged agent is cheaper than phishing a hundred humans, because the agent has already done the credential-gathering for you.
No payloads are reproduced here; the shape is the lesson. An over-scoped identity plus an untrusted input channel plus a persistent token equals a privilege-abuse incident waiting to be triggered.
Why it matters
The scale of non-human identity (NHI) over-provisioning is the part defenders underestimate. Industry figures cited in the Adversa guide are stark: roughly 73% of secrets held by non-human identities carry excessive permissions, and about 1 in 20 AWS machine identities has full administrative privileges. When an agent inherits or acquires one of those credentials, the potential blast radius of a compromise extends far beyond anything the agent’s original purpose justified.
This matters now because the number of non-human identities in a typical enterprise already dwarfs the number of humans, and agentic deployments are adding more of them weekly — each one a potential aggregation point. Traditional identity governance was built around human lifecycles: onboarding, role changes, offboarding, periodic access reviews measured in months. Agents operate on the timescale of seconds and spawn sub-agents and tool sessions that no quarterly access review will ever see.
ASI03 is also largely invisible to perimeter controls. Every credential the agent uses is, by definition, one it was issued. There is no malformed packet and no unauthorized binary; there is an authorized identity doing authorized things with more authority than the situation called for. The failure is one of scope and lifecycle, not of authentication — which is exactly the kind of failure that signature- and pattern-based tooling does not catch.
Defenses
OWASP, Adversa, and the Cloud Security Alliance’s Agent Identity Governance Framework converge on a consistent control set. None of it is exotic; the discipline is in applying it to machine identities at agent speed.
- Give every agent its own identity. Do not let agents run under a human’s account or a shared service principal. A distinct, attributable identity per agent is the precondition for scoping, auditing, and revoking anything.
- Scope per task, not per agent. Grant the narrowest permissions the immediate task needs, drawn from a defined role, and avoid standing broad grants. Treat “what could this identity do on its worst day?” as a design input, not an incident-response question.
- Make credentials short-lived and bound. Prefer ephemeral, just-in-time tokens scoped to a single task or session, ideally bound to the workload, so a leaked token expires before it is useful and cannot be replayed elsewhere.
- Stop privilege accumulation across sessions. Release acquired tokens and delegated sessions when the task ends; do not let the agent’s effective authority ratchet upward over its lifetime.
- Govern delegation explicitly. When an agent calls another agent or a tool that re-authenticates, propagate identity and authorization intentionally — the authorization-propagation problem is its own failure mode, and silent privilege inheritance between agents is where multi-agent systems leak the most.
- Inventory and monitor non-human identities continuously. You cannot scope what you cannot see. Maintain a live inventory of agent identities and their grants, and alert on excessive permissions, dormant-but-privileged credentials, and anomalous use. Apply the same rigor to NHIs that mature programs apply to human joiners and leavers — at machine cadence.
The unifying principle: an agent’s identity is an authorization boundary, not a convenience. Design the authority each identity carries and the lifetime of every token it holds, and assume that any credential left lying around will eventually be inherited by something you did not intend.
Status
| Item | Reference | Date | Notes |
|---|---|---|---|
| OWASP Top 10 for Agentic Applications | OWASP GenAI | 2025–2026 | ASI03 = Identity & Privilege Abuse, item #3 of 10 |
| ASI03 deep-dive guide | Adversa AI | 2026-06-25 | Definitions, NHI statistics, defensive controls |
| Threat-modeling the category | disesdi | 2026 | Attacker’s-eye view of ASI03 |
| Agent Identity Governance Framework | Cloud Security Alliance | 2026 | Governance model for agent/NHI identities |
ASI03 is a framework category, not a single CVE — it will keep “patching itself” only as fast as builders give agents their own scoped, short-lived identities and treat non-human credentials with the same lifecycle discipline as human ones. The takeaway for anyone shipping an agent: enumerate every credential it can hold, decide what its worst legitimate use would cost you, and constrain the identity before the agent ever reasons about it.
Sources
- → https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- → https://adversa.ai/blog/owasp-asi03-identity-privilege-abuse-in-ai-agents/
- → https://disesdi.substack.com/p/attacking-and-threat-modeling-the-ff9
- → https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/
- → https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/