AI agent privilege escalation happens at the permission intersection

At a glance

What this is: This analysis explains how AI agents can turn into privilege escalation paths when delegated access, scopes, and human entitlements are not checked together.

Why it matters: IAM and security teams need to treat agent authorisation as an intersection problem, because shared identities can bypass the user’s real permission ceiling even when the agent appears constrained.

Context

AI agent privilege escalation happens when an agent is allowed to act through permissions that are broader than the person behind the request. The problem is not just whether the agent can call a tool, but whether that call respects the human’s actual authority in the target application.

The security gap appears when onboarding policy, OAuth scope, and user entitlement are treated as separate checks instead of one effective permission boundary. In shared-identity deployments, that boundary can disappear from the application’s view, which is why agent authorisation now needs explicit governance across both NHI and human identity models.

Key questions

Q: Where does agent authorisation fail in practice when users share an AI agent?

A: It fails when the system treats tool access as the whole permission boundary. If the agent runs under a shared identity, the application may only see a privileged caller and lose sight of the human’s real ceiling. That is where low-privilege users can inherit higher-privilege actions through the agent.

Q: Why do AI platforms create confused deputy risk in enterprise environments?

A: Because the AI layer often sits in the middle of users and internal systems while holding more access than any single user should have. If downstream services trust the platform itself, an attacker can persuade it to use legitimate privileges on the attacker’s behalf. The risk grows when tool calls, data access, and automation are all chained through one orchestrator.

Q: How should security teams manage permissions for AI agents?

A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope. Implementing a governance framework that details access levels and usage policies is crucial to mitigate risks. Moreover, continuous monitoring can detect irregular permissions that may increase exposure.

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

Why agent permissions are an intersection problem

An AI agent’s effective authority is the overlap of three layers: what the security team allows the agent to use, what the token scope permits, and what the human behind the request is entitled to do. If any layer is broader than the others, the agent can inherit excess capability. That is why tool allowlists alone do not define real permission boundaries. The control problem is not capability in isolation, but capability in context. Practical implication: model authorisation as an intersection of policy, scope, and user entitlement, not as a single agent onboarding decision.

Practical implication: model authorisation as an intersection of policy, scope, and user entitlement, not as a single agent onboarding decision.

Why shared agent identities create confused deputy risk

When an agent runs under a shared credential or service principal, the application no longer sees the human’s individual ceiling. It only sees a privileged identity making a permitted call, which means the application cannot distinguish a legitimate high-privilege workflow from a low-privilege user acting through a stronger agent. That is the classic confused deputy problem in modern agent form. The security failure is not token presence, but identity collapse at the application boundary. Practical implication: shared agent identities require explicit external enforcement because the target app cannot reconstruct the human’s real limits on its own.

Practical implication: shared agent identities require explicit external enforcement because the target app cannot reconstruct the human’s real limits on its own.

Why OAuth scopes and resource indicators are not enough on their own

Scopes were designed to gate application capabilities, not to describe precise tool-and-resource combinations for AI agents. The article notes that OAuth 6749 leaves scope values to each application, which produces inconsistent and often overly broad privilege models. Resource indicators from RFC 8707 and structured authorization from RFC 9396 help, but only if they are actually implemented and enforced in the right place. In practice, the gateway sees the agent policy, the user identity, and the tool call together, while the application may not. Practical implication: place enforcement where all three signals are visible, then validate token audience and resource binding downstream.

Practical implication: place enforcement where all three signals are visible, then validate token audience and resource binding downstream.

Threat narrative

Attacker objective: Use the agent as a confused deputy to perform higher-privilege actions than the initiating human is allowed to execute.

1. A human initiates an agent task through a gateway that obtains a delegated or shared credential for application access.
2. The agent operates with scopes or resource access that are broader than the human’s actual entitlements in the target application.
3. The application accepts the privileged identity call and cannot see that the human’s real ceiling has been bypassed.
4. The attacker objective is to carry out actions the user could not perform directly, using the agent as a privilege escalation path.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

The confused deputy problem is now the core agent-authorisation failure mode. AI agents do not just expose a missing control, they expose a control boundary that was never designed to reconcile tool access with the human’s actual application entitlements. The result is a permission intersection problem, not a simple scope problem. Practitioners should treat agent authorisation as a three-layer governance issue across NHI access, delegated tokens, and human identity ceilings.

Shared agent identities collapse the user ceiling out of the application’s view. A service principal or shared agent credential can make a low-privilege human look operationally legitimate inside the target system, even when the human should not have been able to act directly. That is an assumption failure in modern IAM: the application can no longer infer who is really constrained. The implication is that agent governance must be evaluated at the delegation layer, not only at the app layer.

Permission at the gateway is becoming the decisive control plane for agentic access. OAuth scopes are too coarse, and application-level enforcement is blind when the agent runs under its own identity. The permission intersection therefore shifts to the layer that can see policy, identity, and action in the same transaction. Practitioners should recognise this as a structural change in agent governance architecture, not just an implementation detail.

OAuth scope design is no longer sufficient as a proxy for agent capability. The article shows that scopes describe broad application permissions, while agent safety depends on precise resource binding and per-user entitlement. That gap matters most when the agent is shared across users or runs autonomously enough to outlive the assumptions of a single delegated session. The implication is that scope design must be subordinated to real-time entitlement validation.

Runtime authorisation for agents must align with the human’s present authority, not the agent’s planned workflow. Once the human ceiling disappears, over-permissioned agents become policy bypass channels rather than productivity tools. This is where identity governance, access management, and application authorisation converge into one control problem. Practitioners should reframe agent governance around effective permission, not declared intent.

From our research library:

• Patching addresses only about 10% of privilege escalation techniques, while privilege management covers about 65%, according to Verizon's 2026 Data Breach Investigations Report.

What this signals

Permission intersection will become a design requirement for agent programmes. Teams that keep treating agent onboarding, OAuth scope design, and human entitlement review as separate workstreams will miss the actual enforcement boundary. The practical question is not whether the agent can call a tool, but whether that call remains inside the user’s real authority.

Shared identity is the point where traditional application checks lose context. In that model, the app sees a permitted caller, not the initiating human’s ceiling. That means IAM and application security teams need a shared model for agent governance before multi-user deployment expands the blast radius.

Confused deputy risk is a governance problem as much as a technical one. When a low-privilege user can act through a higher-privilege agent, the control failure is usually at the authorisation design stage rather than at the token issuance stage. The programme implication is to test for entitlement bypass, not just token validity.

For practitioners

• Define the effective permission intersection Map each agent flow against agent allowances, token scope, and the initiating user’s entitlements before approving production use. Any mismatch should be treated as an escalation path, not a tuning issue.
• Separate shared identity from delegated identity Require a different control design for agents running under a service principal than for true on-behalf-of flows, because the application sees different identity evidence in each case.
• Constrain agent access by resource, not only by tool Review whether current scopes and gateway policies can express the exact resource the agent may reach, because generic tool access does not stop cross-database or cross-system privilege bleed.
• Validate gateway enforcement before the application call Make the gateway prove the user ceiling and resource audience on every request path where the target application cannot independently reconstruct the human’s limits.
• Audit confused deputy scenarios in multi-user agents Test whether a low-privilege user can trigger actions through a higher-privilege agent that they could not perform directly, then block any such pathway as an entitlement violation.

Key takeaways

• AI agents can become privilege escalation paths when their access is judged only by tool permissions instead of the overlap of policy, scope, and human entitlement.
• Shared agent identities make entitlement bypass harder to see because the application may no longer have visibility into the user’s true permission ceiling.
• The strongest control point is the layer that can validate the agent policy, token audience, and user authority before the application accepts the call.

Key terms

• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Permission Intersection: The overlapping set of entitlements shared by all intended recipients of an AI agent’s output. If the agent can only return data that everyone in the audience is allowed to see, disclosure risk drops materially, but only when entitlement data is accurate and current.
• Scoped Agent Identity: Scoped agent identity is a non-human identity assigned to an AI system or agent with explicit limits on what it may access and do. The scope must be narrower than a human session because agents can execute independently, interact with tools, and persist across workflows.
• On-Behalf-Of Flow: A token or session pattern where one identity acts for another while preserving evidence of delegation. For agents, the value is not just access propagation. It is the ability to show that the action was performed under a specific authority and within a specific scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.