AI agent privilege escalation happens at the permission intersection

At a glance

What this is: This is an analysis of how AI agents become privilege escalation machines when delegated access, OAuth scopes, and user entitlements are not aligned.

Why it matters: It matters because IAM teams need controls that account for agent policy, application permissions, and the human in the loop across NHI and autonomous access models.

👉 Read Andromeda Security's analysis of AI agent permission gaps and confused deputy risk

Context

AI agent privilege escalation emerges when an agent can act with more authority than the human who requested the task. In practice, the problem is not just whether the agent is authenticated, but whether its permissions are bounded by the user's actual entitlements at execution time.

That gap matters for identity governance because agent deployments often mix delegated tokens, shared credentials, and application scopes that were never designed to express per-resource, per-tool, or per-user ceilings. The result is a confused deputy pattern that turns identity plumbing into an escalation path.

Key questions

Q: How should security teams prevent AI agents from escalating user privileges?

A: Security teams should enforce the user's real entitlement at the point where the agent request is mediated, not only at the target application. That means binding tokens to the right resource, checking the initiating user's ceiling, and preventing shared agent identities from bypassing per-user restrictions. If those checks are split across systems, escalation paths remain.

Q: Why do AI agents create confused deputy risk in IAM?

A: AI agents create confused deputy risk because the actor making the request, the identity carrying the token, and the user who asked for the task may not be the same authority. When the application sees only a privileged agent or gateway identity, it cannot tell whether the human behind the request is entitled to the action. That mismatch is the core failure mode.

Q: When do OAuth scopes fail to protect AI agent access?

A: OAuth scopes fail when teams expect them to express precise tool and resource boundaries that they were never designed to describe. They are too coarse for per-database, per-workspace, or per-action authorization in agent workflows. Once an agent needs finer-grained access, scopes alone become an incomplete policy layer and must be supplemented.

Q: What is the difference between delegated AI access and shared agent identities?

A: Delegated access preserves the user's ceiling because the application can still see the human as the subject of the request. Shared agent identities remove that ceiling from the decision path, so the application only sees the agent's broader permission set. That difference determines whether the user's entitlement still acts as a control or disappears entirely.

Technical breakdown

Confused deputy risk in AI agent identity flows

The confused deputy problem appears when a system with legitimate authority performs actions on behalf of a less-privileged requester, but the target application cannot distinguish that mismatch. In agent architectures, the gateway or orchestrator may hold a powerful identity while the human behind the request is not entitled to the same action. If the resource server only sees a valid privileged token, it will accept the call even when the human should have been blocked. This is not a bug in OAuth itself. It is a mismatch between delegation design and runtime authority boundaries.

Practical implication: enforce the human ceiling at the point where the agent call is mediated, not only at the application boundary.

Why OAuth scopes fail to express agent permissions

OAuth scopes were designed as coarse capability labels, not as a portable language for per-tool or per-resource authorization. They can say an identity may read or write, but they cannot reliably describe which database, which workspace, or which action chain is allowed for a specific agent task. Resource indicators and rich authorization requests improve that model by binding a token to a resource server and structured policy, but adoption remains uneven. Where those standards are not implemented, broad scopes become a convenience layer that hides over-permissioned access.

Practical implication: treat scope strings as incomplete policy signals and add resource-specific controls where agents operate.

Shared agent identities remove the user's entitlement ceiling

The most dangerous pattern is an agent that runs under its own broad identity rather than a true on-behalf-of token. In that model, the application no longer sees the human user's actual ceiling, so a low-privilege requester can trigger actions through a high-privilege agent that would be impossible from their own account. That is where application access management and identity governance diverge. The issue is not simply too much access. It is that the user entitlement check disappears from the decision path entirely. Once that happens, the agent becomes a privilege amplifier.

Practical implication: inventory where agents use shared identities and require separate entitlement enforcement before those flows reach production.

Threat narrative

Attacker objective: The attacker or insider objective is to make a less-privileged request result in a higher-privilege action through delegated agent execution.

1. Entry occurs when a user submits a task to an agent that can route through a gateway and obtain an OAuth token or shared agent credential.
2. Escalation occurs when the agent operates with broader application permissions than the initiating user, allowing actions that exceed the user's own entitlement ceiling.
3. Impact occurs when the agent executes a privileged operation in the target application without the application being able to see the underlying human restriction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent privilege escalation is a governance failure, not just an access-control defect. The article shows that the true authorization boundary is the intersection of agent policy, token scope, and the human user's entitlement. That means traditional IAM logic, which assumes the application can independently enforce the right ceiling, breaks down when the agent runs under a shared identity. Practitioners should treat this as a delegation-design problem, not a simple permission review.

Confused deputy is the right named concept because the application becomes the proxy for the wrong subject. The user believes they are asking for a bounded task, but the gateway or agent may exercise a broader authority than the user actually owns. That is a classic identity governance blind spot: the actor executing the call is not the same actor whose permissions should determine the outcome. The implication is that agent governance must reason over effective authority, not just who authenticated.

Resource indicators and structured authorization requests matter because scopes alone do not describe agent reality. OAuth scopes were built for application capabilities, not for tool-specific and resource-specific agent operations. When the article notes that standards are barely deployed, it exposes a category-level problem: current control language is too coarse for autonomous or semi-autonomous execution paths. Practitioners should treat the permission model itself as incomplete, not merely misconfigured.

Shared-agent execution erases the user's entitlement ceiling and creates a new escalation surface. A low-privilege human can reach through a privileged agent and perform actions that would otherwise fail under direct access. That failure mode is especially important for organisations that centralise agent identities or reuse service principals across users. The governance conclusion is simple: if the human ceiling disappears, the access model is no longer acting as a control boundary.

Identity governance for agents now sits at the gateway, not only in the target application. The article correctly points to the gateway as the only place that can see agent policy, human identity, and individual tool calls at the same time. That does not eliminate downstream checks, but it does change where the highest-value control point lives. Practitioners should redesign their review model around mediation points, not just applications and roles.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For lifecycle context, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why access review and offboarding discipline must match the identity type, not just the workflow.

What this signals

Confused deputy control will become a board-level agent governance issue. As agents move from demos into production, teams will need to prove where the human ceiling is enforced and where it is lost. The control model has to account for gateway mediation, shared identities, and resource-bound authorisation together, not in isolation.

Agent identity programmes should now be measured by effective authority, not by authentication success. A flow that authenticates perfectly can still be unsafe if the wrong subject is authorised. That means IAM leaders should assess whether their current review process can distinguish delegated execution from pooled or shared agent execution before scale makes the problem harder to unwind.

Gateway-centric governance is the new pressure point. When a gateway sees both user context and tool invocation, it becomes the best place to enforce policy consistency. For teams building on agent protocols, the question is no longer whether identity exists, but whether the identity decision is still tied to the person who should bear the limit.

For practitioners

• Map every agent flow to the real entitlement boundary Document where the user's permissions are preserved, where they are lost, and where the agent can exceed the initiating identity. Prioritise any flow that uses shared service principals or reusable agent credentials.
• Require resource-bound authorization for agent calls Use token audience binding and structured authorization data so the receiving service can validate both the resource and the action, not just the presence of a valid token.
• Separate delegated flows from shared-identity flows Treat true on-behalf-of execution differently from autonomous or pooled agent execution, because the control assumptions are not the same. Do not let the same approval path govern both.
• Review gateway policy as an identity control point Make the gateway enforce the intersection of agent policy, user entitlement, and resource scope before a request reaches the application. This is where the broadest mismatch can be detected earliest.

Key takeaways

• AI agents become privilege escalation paths when the user's entitlement is no longer part of the authorization decision.
• The confused deputy problem is the clearest way to describe why shared agent identities can bypass intended IAM controls.
• Practitioners need gateway-level enforcement, resource binding, and entitlement checks that survive delegated and shared-identity execution models.

Key terms

• Confused Deputy Problem: A confused deputy occurs when a privileged system performs an action on behalf of a less-privileged requester and the target service cannot tell the difference. In AI agent environments, this becomes an authorization failure when the gateway or shared agent identity carries more power than the human should have.
• Delegated Token Flow: A delegated token flow is an authentication pattern where the token represents the human user and the application can enforce that user's ceiling. In agent systems, this only works when the user's identity remains visible to the resource server and the delegation chain is preserved end to end.
• Shared Agent Identity: A shared agent identity is a reusable non-human identity that multiple users or tasks can invoke. It simplifies operations but can hide the initiating user's entitlement from the target application, which makes over-permission and privilege escalation much harder to detect.
• Resource Indicator: A resource indicator binds a token to a specific resource server so the token is not broadly reusable elsewhere. For agent governance, it narrows the authorization surface and helps ensure the token presented by the gateway matches the intended service or dataset.

What's in the full article

Andromeda Security's full article covers the operational detail this post intentionally leaves for the source:

• How the gateway obtains and presents delegated OAuth 2.0 token exchange flows in practice.
• Why OAuth scopes, resource indicators, and rich authorization requests differ operationally for agent use cases.
• Where shared agent identities break user-ceiling enforcement in real applications.
• How the author frames gateway-level enforcement as the control point for agent-mediated access.

👉 The full Andromeda Security post covers gateway mechanics, OAuth scope limitations, and user-ceiling enforcement in agent flows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.