OWASP ASI03 Identity and Privilege Abuse: Agent Guide

AI agents act for users, for themselves and for other agents, and every hop in that chain is a chance to inherit, keep or borrow more access than the task needs. OWASP ranks this as ASI03 Identity and Privilege Abuse in the OWASP Top 10 for Agentic Applications, released on 9 December 2025. This guide goes deeper than our overview of the list: it explains what OWASP means by the entry, turns its mitigations into testable requirements, shows how OAuth token exchange, audience binding and per-agent workload identity apply, and sets out how to roll the controls out and prove they work. It is written for IAM and NHI teams, security architects and platform owners who issue credentials to agents or approve their access. For the full list, see the OWASP Top 10 for Agentic Applications Guide.

Key takeaways

ASI03 is about credentials and delegation, not tools. OWASP separates it from ASI02 Tool Misuse: ASI03 covers an agent misusing or inheriting identity and permissions, ASI02 covers an agent misusing tools it was legitimately given.
The attribution gap is the root cause. OWASP notes that agents often lack a distinct, governed identity, so their actions blur into the user or service account behind them and least privilege cannot be enforced or audited.
Bind every token to a task. OWASP's core mitigation is short-lived, narrowly scoped credentials per task and per agent, bound to subject, audience, purpose and session, with re-authorisation on any context switch.
Delegation must stay visible. OAuth 2.0 Token Exchange (RFC 8693) lets an agent act on behalf of a user while keeping its own identity in the act claim, which is the difference between delegation and silent impersonation.
Authorise each privileged step, outside the model. A central policy engine re-checks every privileged action, and escalation or irreversible actions need human approval that the agent cannot grant itself.

What it is and who it applies to

OWASP describes ASI03 as attackers exploiting the dynamic trust and delegation between users, agents and tools to gain access or bypass controls. They do it by manipulating delegation chains, inherited roles and control flows, or by reusing context such as cached credentials and conversation history. OWASP frames it as the agentic form of LLM06 Excessive Agency, and its Appendix A maps it to LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure and LLM06, to threat T3 Privilege Compromise in the earlier Agentic AI Threats and Mitigations taxonomy, and to the AIVSS core risk "Agent Access Control Violation".

It applies to any agent that holds or receives credentials: coding agents with cloud and repository tokens, copilots that act in a user's mailbox or CRM, MCP servers that call third-party APIs, and multi-agent systems where an orchestrator hands work to sub-agents. If an agent can call an API that checks an access token, ASI03 applies.

OWASP lists five common forms of the vulnerability:

Un-scoped privilege inheritance: an agent or sub-agent receives the full rights of the user or parent agent rather than the subset the task needs.
Memory-based privilege retention and data leakage: credentials or privileged data cached in context or memory carry over into later tasks or other users' sessions.
Cross-agent trust exploitation (confused deputy): a low-privilege agent or attacker persuades a higher-privilege agent to act for it, and the high-privilege agent uses its own authority.
Time-of-check to time-of-use (TOCTOU) in agent workflows: permission is checked at the start of a long-running workflow but the action runs later, after the context or entitlement has changed.
Synthetic identity injection: an attacker introduces a forged agent persona or identity that other agents or systems then trust.

OWASP's example attack scenarios are delegated privilege abuse, memory-based escalation, cross-agent trust exploitation, device-code phishing across agents, workflow authorisation drift, forged agent persona and identity sharing. A well-documented real case of the pattern is the GitHub MCP "toxic agent flow" that Invariant Labs published on 26 May 2025: a prompt injection planted in a public repository issue led an agent, holding a personal access token that could read every repository the user could, to copy private repository data into a public pull request. Invariant Labs stressed that the MCP server code was not at fault; the broad token and the agent's exposure to untrusted content were.

Structure and key requirements

OWASP gives nine prevention and mitigation guidelines for ASI03. The table turns each into a requirement you can test. OWASP's wording is paraphrased; the "how to verify" column is NHI Mgmt Group's.

OWASP guideline	Requirement	How to verify
Task-scoped, time-bound permissions	Each agent gets its own identity; tokens are issued per task with the minimum scopes and a short lifetime	Sample tokens: `exp` minus `iat` within policy, scopes match the task profile, no shared client IDs
Isolate agent identities and contexts	Per-session sandboxes; memory and cached credentials are wiped between tasks	Run two tasks for different users and confirm no token or data from the first is reachable in the second
Per-action authorisation	A central policy engine re-verifies every privileged step, not just the session start	Revoke an entitlement mid-workflow and confirm the next privileged call is denied
Human-in-the-loop for escalation	High-privilege or irreversible actions need approval from a person, through a channel the agent cannot answer itself	Attempt a delete or permission grant; confirm it blocks pending approval and is logged
Define intent	OAuth tokens are bound to a signed intent covering subject, audience, purpose and session; mismatches are rejected	Replay a token against a different API or purpose and confirm rejection
Agentic identity management	Agents are managed as NHIs with owners, scoped credentials and audit trails	Every production agent appears in the NHI inventory with an owner and credential list
Bind permissions and re-authenticate	Permissions bound to subject, resource, purpose and duration; re-authentication on context switch; revocation on idle or anomaly	Switch tenant or user mid-session and confirm a new token is required
Detect delegated and transitive permissions	Monitor when agents gain access indirectly through delegation chains	Effective-permission report per agent includes inherited and delegated rights
Detect cross-agent elevation and device-code phishing	Alert on unusual scope requests, token reuse across agents and unexpected device-code grants	Detection rule fires in a purple-team test

Identity and NHI requirements

ASI03 is the entry where the agentic list and the OWASP Non-Human Identities Top 10 meet most directly. OWASP's Appendix C maps NHI5 Overprivileged NHI to ASI02 and ASI03, NHI4 Insecure Authentication to ASI03 and ASI07, and NHI3 Vulnerable Third-Party NHI to ASI03 and ASI04. In practice an agent is an NHI with an unusually dynamic job description, so the NHI controls apply with three additions: delegation, per-task scoping and intent binding.

Give the agent its own identity

Workload identity, not shared keys: issue each agent a workload identity (for example a SPIFFE ID, a cloud workload identity or a dedicated OAuth client) and federate it to target platforms rather than storing static API keys. See the Workload Identity Federation Guide and the SPIFFE and SPIRE Guide.
One agent, one identity: OWASP lists identity sharing as an attack scenario. Separate identities per agent and per environment are what make attribution, scoping and revocation possible.
Named owner: every agent identity has an accountable human owner and is reviewed like any other privileged NHI. Agents that run access reviews or provisioning need this most, as the Agentic AI in IAM Operations Guide explains. See the Agentic AI Identity Guide.

Delegate, do not impersonate

RFC 8693 OAuth 2.0 Token Exchange (grant type urn:ietf:params:oauth:grant-type:token-exchange) distinguishes two models. In impersonation the agent presents only a subject_token and receives a token indistinguishable from the user's. In delegation the request also carries an actor_token, and the issued token can record the agent in an act claim, with nested act claims recording a chain of actors and the outermost one being the current actor. A may_act claim in the subject token lets the authorisation server check which party is allowed to act for the subject. For agents, prefer delegation: the downstream API and the audit log then see both the user and the agent. See the OAuth Token Exchange and Delegation Guide.

Bind tokens to audience and purpose

Audience: the MCP authorisation specification (version 2025-11-25) requires clients to send the RFC 8707 resource parameter in authorisation and token requests, requires MCP servers to accept only tokens issued for them, and forbids passing a client's token through to an upstream API. These rules stop one token being replayed across services.
Scope: the MCP security best practices advise a minimal initial scope set with step-up through WWW-Authenticate scope challenges, and list wildcard or omnibus scopes such as * or full-access as a common mistake.
Purpose: OWASP's "define intent" guideline goes further than scope: bind the token to the purpose and session of the task. OAuth Rich Authorization Requests can carry structured purpose data. See the OAuth Rich Authorization Requests (RAR) Guide.

Watch the deputies

The MCP security best practices describe a concrete confused deputy: an MCP proxy server that uses one static OAuth client ID towards a third-party API, allows dynamic client registration and relies on the third party's consent cookie can be tricked into sending an authorisation code to an attacker's redirect URI. Proxy servers must keep per-client consent, validate redirect URIs by exact match and use single-use state values. See the MCP Security Guide.

Implementation steps

Start with the agents that hold the most power, not the most users. A small team with one coding agent and a large organisation with dozens of orchestrated agents follow the same order; the large organisation adds a central token service and policy engine earlier.

Inventory agent credentials. For each agent, list every token, key, OAuth grant and role it can use, including credentials it can read from files, environment variables or MCP configuration. ATLAS documents this exposure as AML.T0083 Credentials from AI Agent Configuration.
Compute effective permissions. Include inherited and delegated rights: what the agent can reach as itself, as the user it acts for, and through any sub-agent or MCP server. For platform roles in practice, see the Securing ServiceNow AI Agents Guide.
Remove credentials from the agent's reach. Move secrets out of repositories, workspaces and prompt context into a secrets manager or token broker the agent calls, so a hijacked agent cannot simply read a stronger credential.
Issue per-agent identities. Replace shared service accounts and user personal access tokens with per-agent workload identities, federated where the platform allows.
Introduce per-task tokens. Use token exchange to mint short-lived, audience-bound tokens for each task, carrying the agent as actor. Start with read paths, then writes.
Put a policy decision point in front of privileged actions in log-only mode for a pilot group. Review what it would have denied for two to four weeks, tune, then enforce. Roll back by switching the policy point back to log-only, not by restoring broad tokens.
Add approval gates for deletes, permission grants, money movement and external sharing. See the Human-in-the-Loop for AI Agents Guide.
Isolate sessions. Clear memory and cached tokens between tasks and between users; re-issue tokens on any tenant or user switch.
Test and rehearse revocation. Run delegation abuse, confused deputy and memory carry-over tests before release, and time a full credential revocation for each high-risk agent.

Choosing a delegation model

Model	When it fits	Trade-offs
Agent acts as itself (client credentials)	Back-office automation with no specific user, such as a nightly reconciliation agent	Simple and attributable; must not be used to reach user-owned data the agent's role should not see
Delegation via token exchange with `act`	Copilots and assistants working on a named user's data	Best attribution and least privilege; needs authorisation server support and downstream APIs that read the claim
Impersonation (user token passed to agent)	Legacy APIs that cannot accept anything else	Agent inherits all the user's rights and disappears from logs; treat as a temporary exception with compensating controls
User's personal access token in agent config	Never for production	The GitHub MCP case shows one broad token turning a prompt injection into cross-repository data exposure

Evidence and assessment

Assessors, internal audit and red teams need to see that the controls work at run time, not only on a diagram. Log enough to reconstruct every privileged action: agent identity, the principal it acted for, the delegation chain, token identifier, audience and scopes, the policy decision, any approval and the outcome. Without the actor recorded separately from the subject, the attribution gap OWASP describes remains.

Alert on these signals:

An agent requesting scopes outside its profile, or a step-up for an admin scope.
The same token or refresh token presented by two different agents or hosts.
Device-code grants initiated from agent infrastructure, or approved by users shortly after an agent interaction.
Tokens presented to an API that is not in their audience.
Privileged calls after the task or session that justified them has ended.
An agent creating identities, keys or role assignments.

Metric	What it shows	Target
Share of production agents with a unique identity and no static credentials	Attribution and revocability	Towards 100%
Median lifetime of agent access tokens	Exposure window if a token leaks	Minutes to an hour, falling
Share of user-facing agents using delegation (actor recorded) rather than impersonation	Delegation visibility	Towards 100%
Privileged agent actions without a recorded policy decision	Gaps in per-action authorisation	Zero
Measured time to revoke all credentials of one agent	Containment readiness	Minutes
Unused scopes per agent identity	Over-provisioning drift	Falling each quarter

For behavioural detection, see the AI Agent Behaviour Baselining and Anomaly Detection Guide.

Mapping to other frameworks

Framework	Where ASI03 sits
OWASP LLM Top 10 2025	LLM06 Excessive Agency (excessive permissions and autonomy; its mitigations include executing extensions in the user's context and complete mediation), LLM01 Prompt Injection as the usual trigger, LLM02 for the data exposed. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
OWASP NHI Top 10 2025	NHI5 Overprivileged NHI, NHI4 Insecure Authentication, NHI3 Vulnerable Third-Party NHI (OWASP Appendix C). See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
MITRE ATLAS	AML.T0012 Valid Accounts, AML.T0083 Credentials from AI Agent Configuration, AML.T0098 AI Agent Tool Credential Harvesting, AML.T0053 AI Agent Tool Invocation, AML.T0101 Data Destruction via AI Agent Tool Invocation
MITRE ATT&CK v20	T1078.004 Cloud Accounts, T1528 Steal Application Access Token, T1550.001 Application Access Token, T1552.001 Credentials In Files
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-3 Access Enforcement, AC-6 Least Privilege and AC-6(5) Privileged Accounts, IA-9 Service Identification and Authentication, IA-5 Authenticator Management, AU-2 Event Logging, AU-10 Non-repudiation
NIST CSF 2.0	PR.AA-01 identities and credentials for services managed, PR.AA-05 least privilege access permissions, DE.CM-09 monitoring of runtime environments
ISO/IEC 27001:2022 Annex A	5.15 Access control, 5.16 Identity management, 5.18 Access rights, 8.2 Privileged access rights, 8.15 Logging

The NIST and ISO mappings are NHI Mgmt Group's; OWASP maps ASI03 only to its own lists, T-codes and AIVSS. NIST's NCCoE is also exploring a project on software and AI agent identity and authorisation, with a concept paper titled "Accelerating the Adoption of Software and AI Agent Identity and Authorization"; it is at an early, feedback-gathering stage. Track it in the Agent Identity Standards Tracker.

Common pitfalls

Leaving strong credentials where the agent can read them. In the PocketOS database deletion, a coding agent working in staging found an account-scoped Railway token in an unrelated file and used it to delete the production database and its volume backups. The token was created for domain management; nothing limited it to that purpose or environment.
Giving the agent the user's whole identity. A personal access token or impersonation token makes every prompt injection a full-account compromise, as the GitHub MCP case showed.
Checking permission once per workflow. Long-running workflows drift: the user loses access, the ticket closes, or the tenant changes, but the agent's cached token still works. This is the TOCTOU form OWASP lists.
Trusting another agent because it is internal. A high-privilege agent that acts on any request from a peer becomes a confused deputy. Authorise the original principal and the task, not the calling agent alone. See the Agent-to-Agent Authentication Guide.
Letting memory outlive the task. Privileged data or tokens stored in long-term memory resurface in a later session for a different user.
Approval prompts the agent can satisfy. If the approval channel is a message the agent itself can send or click, it is not a control.

Practitioner checklist

Inventory every agent with its owner, identity, credentials, delegated rights and reachable secrets.
Give each agent and environment its own identity; remove shared service accounts and user personal access tokens.
Issue short-lived, audience-bound, task-scoped tokens through token exchange, recording the agent as actor.
Reject tokens not issued for the receiving service, and never pass a client's token upstream.
Re-authorise every privileged action through a policy engine outside the model.
Require human approval, through a channel the agent cannot use, for escalation and irreversible actions.
Clear memory and cached credentials between tasks, users and tenants.
Log subject, actor, delegation chain, token, scopes, decision and outcome for every privileged call.
Alert on out-of-profile scope requests, token reuse across agents and device-code grants.
Drill full credential revocation for each high-risk agent and record the time taken.

OWASP Agentic Top 10 ASI03 Guide