AI Agent Privilege Escalation: Attack Paths and Security Testing

Privilege escalation in an AI agent occurs when an attacker gains authority beyond what the initiating user, task or agent should possess. The escalation may not look like a traditional exploit. A model can select an administrative tool, persuade another agent, reuse a token, modify parameters after approval or exploit a downstream authorization gap.

Security testing must distinguish the model asking for privilege from the system actually granting or spending it. This guide focuses on observable authority and evidence.

Map privilege layers

Inventory user roles, agent workload identities, delegated tokens, tool permissions, MCP policy, downstream service roles, infrastructure access and approval. Record which layer is authoritative for each action.

Compare declared capability with effective reach. A customer assistant may expose only read tools while its backend credential can write. A hidden admin tool may be directly callable. A generic HTTP tool may bypass named-tool policy.

Classify vertical escalation to higher roles, horizontal escalation across peers or tenants, and scope escalation to new resources or destinations.

Prompt-driven tool escalation

Direct jailbreaks and indirect content can influence tool selection. The model may call a higher-impact tool because a document claims an emergency or authority.

Enforce tool policy outside the model. Separate discovery from authorization. Require trusted approval when consequence increases. Do not encode admin access only in tool descriptions.

Test hidden tools, alternative names, direct protocol calls and multi-turn social engineering.

Parameter escalation

A permitted tool can become privileged through arguments: another tenant's account, an admin role, a production environment, a larger amount or an external destination.

Derive identity and ownership server-side. Constrain schemas and reauthorize every object. Bind approval to exact parameters.

Test substitution, nested fields, bulk operations, defaults, encoding and changes between preview and execution.

Credential and token escalation

Agents may obtain broader tokens through scope requests, token exchange or credential brokers. Validate audience, scope, user, client and task. Prevent a low-risk tool from requesting an administrative credential.

Test token reuse across services and environments, refresh-token abuse and fallback to a platform credential when user delegation fails.

Keep raw credentials outside model context. The secrets-management guide provides detailed controls.

Delegation escalation

One agent may ask a more privileged peer to act. Downstream agents must reauthorize using original identity and task. A message from an authenticated agent is not proof of permission.

Limit capability transfer, redelegation depth and recipient. Preserve the delegation chain and cancel descendants when root authority ends.

Test forged parent messages and confused-deputy paths using the multi-agent security guide.

Approval bypass

Escalation can bypass approval through a lower-level tool, replay an old decision, change parameters or split one high-impact action into several apparently safe steps.

Verify approval at the final enforcement point. Use single-use, expiring references bound to operation and identity. Detect cumulative consequence.

Test denial followed by alternative tool selection. The agent should not shop for a path around policy.

Role and session confusion

Account switching, support impersonation and stale sessions can retain higher privilege. Clear context and capabilities when identity changes. Reevaluate queued work.

Test logout/login, role removal, tenant change, shared devices and concurrent tabs. Confirm caches and memory do not carry authorization state.

Do not let natural-language claims such as “I am an administrator” influence trusted role attributes.

Downstream vulnerabilities

The agent may expose ordinary IDOR, mass assignment, injection or business-logic flaws in connected services. Treat the complete application and API as part of agent security.

Test direct backend requests with the same identity. Verify resource ownership and sensitive fields. Avoid blaming the model when the root cause is downstream authorization.

Correlate weaknesses into a path only when evidence supports the relationship.

Infrastructure privilege

Coding, operations and SOC agents may reach shells, cloud APIs, CI/CD and orchestration. Use isolated identities, constrained commands, network boundaries and sandboxes.

Prevent credential discovery and instance-metadata access. Separate plan from execution. Require stronger review for production and permission changes.

Test environment variables, local sockets, container APIs, service accounts and lateral movement using safe synthetic targets.

Detection signals

Monitor denied privileged tools, scope increases, new destinations, role changes during runs, unusual delegation, approval failures and resource access outside normal relationships.

Correlate signals with untrusted input provenance. A privileged call following a poisoned webpage is more actionable than the call alone.

Preserve both transcript and downstream effect. Alerting on unsafe language is not proof of escalation.

Security test methodology

Use synthetic low- and high-privilege identities and mock tools. Define forbidden outcomes. Test:

1. Direct requests for admin tools.
2. Indirect prompt injection claiming emergency authority.
3. Cross-user and cross-tenant identifiers.
4. Scope and audience substitution.
5. Low-privilege agent delegation to a powerful peer.
6. Approval replay and parameter change.
7. Denial followed by another tool path.
8. Role revocation during an active run.
9. Hidden tool and direct protocol invocation.
10. Downstream mass assignment and object authorization.
11. Infrastructure credential and metadata access.
12. Multi-step cumulative escalation.

Record each transition in authority. Label attempted, blocked and confirmed effects separately.

Remediation hierarchy

Remove unnecessary authority first. Split tools and identities. Enforce resource policy downstream. Make tenant and role server-derived. Bind approval. Restrict delegation and network reach.

Then improve detection and prompts. Behavioral instructions help, but they should not carry the security boundary.

Turn confirmed escalation paths into regression tests. Retest when tools, roles, models, prompts or brokers change.

Privilege-escalation checklist

• Map user, workload, tool and downstream privilege.
• Identify hidden and generic capabilities.
• Enforce tool policy outside the model.
• Derive identity, tenant and role from trusted state.
• Validate every object and sensitive field.
• Use audience-bound, narrow credentials.
• Restrict delegation and confused deputies.
• Bind approvals to exact operations.
• Clear privilege on identity and session changes.
• Sandbox infrastructure and command execution.
• Monitor authority transitions and denials.
• Validate with synthetic roles and downstream evidence.

Frequently asked questions

Is jailbreak success privilege escalation?

Not by itself. Escalation requires the system to grant or spend authority beyond the intended boundary. The transcript may show an attempt; tool and downstream evidence show impact.

What is horizontal escalation?

Accessing another user or tenant at the same nominal role, often through object-identifier substitution or shared memory.

Can human approval stop escalation?

It helps only when trusted parameters are displayed and the approval is enforced at the final action. It does not replace least privilege.

Where should fixes begin?

Reduce effective authority and enforce resource policy in trusted services before relying on prompts or classifiers.

Privilege-escalation testing makes agent authority measurable. Continue with least privilege, human approval and agent red teaming.

Model privilege as a graph

Create nodes for users, agents, service identities, tools, data stores, roles and approval authorities. Add edges for delegation, impersonation, token exchange, tool calls and administrative changes. Mark the conditions attached to every edge.

This graph reveals composed paths that individual permission reviews miss. An agent may have read-only access to one system, yet retrieved content can influence a second agent that has write authority. A support tool may generate a link that an administrator later opens.

Record both designed and effective privilege. Defaults, fallback identities and cached tokens can grant more than policy documentation suggests. Validate the graph with runtime evidence.

Test vertical and horizontal escalation

Vertical escalation gains a stronger role or action, such as moving from viewing a ticket to changing an account. Horizontal escalation crosses a peer boundary, such as another user, tenant, project or agent session.

Test direct requests and indirect routes through files, RAG, memory and tool output. Manipulate role identifiers, resource IDs, tenant context, approval references and delegated tokens. Include absent and malformed claims to verify fail-closed behavior.

Check whether a low-privilege agent can create, modify or select another agent with broader tools. In multi-agent systems, task delegation can become an unreviewed privilege transition.

Examine token exchange and delegation

Trace the original actor through every service. A downstream API should know whether it is seeing the user's authority, the workload's authority or an explicitly delegated subset. Generic shared credentials destroy this distinction.

Attempt audience confusion, token forwarding and use of tokens at unintended services. Verify expiry and revocation during an active workflow. Test whether a child task continues after the parent delegation ends.

Bind delegation to resource, action, tenant, purpose and duration. Do not accept a model-generated explanation as authorization. The agent identity guide covers these patterns in depth.

Challenge approval boundaries

Try to reuse approval for a different action, patient, account, repository, recipient or amount. Modify parameters after approval and race execution against cancellation. Check whether summaries omit a material change.

Test approval fatigue through many low-risk requests followed by a consequential one. Confirm that reviewers see the exact action and trustworthy provenance, not only model-written prose.

Where dual control is required, verify independence. Two clicks from sessions backed by the same identity are not separation of duties.

Test environment and control-plane escalation

Agents often have separate development, staging and production paths. Attempt to use non-production credentials against production endpoints, select a production namespace, or modify deployment configuration through a general-purpose tool.

Review administrative APIs, debug endpoints, feature flags and support consoles. These interfaces may bypass ordinary application authorization. Confirm that logs and traces do not expose reusable privileged tokens.

For coding agents, test repository protection, CI identities and secret access. For MCP, test whether adding or modifying a server grants new authority without review.

Capture proof without causing harm

Use synthetic principals and canary resources. Mock irreversible actions while keeping the authorization chain intact. Establish stopping conditions before execution and avoid real customer data.

Evidence should contain the starting identity, expected permission, escalation path, token or approval context, exact tool arguments, policy response and downstream outcome. Distinguish a proposal from an accepted or completed action.

After remediation, repeat the complete path and nearby variants. A blocked parameter may leave another endpoint or delegation route open. Store the scenario as a regression.

Operationalize prevention

Assign owners for identity, policy, tool and application layers. Remove unused permissions and separate read, write and administration. Use short-lived credentials and explicit delegation rather than long-lived shared keys.

Monitor role changes, new tool connections, token exchange, cross-tenant denials and actions that exceed the initiating user's normal capability. Correlate alerts with prompts and retrieved content, but keep enforcement in trusted services.

Review the privilege graph after every new integration. The safest permission is the one the agent never receives, and the strongest remediation is usually architectural rather than another instruction in the system prompt.

Prioritize remediation by path

Remove the shortest route to consequence first: excessive credentials, missing object authorization, reusable approvals or unrestricted general-purpose tools. Prompt changes can reduce accidental attempts but do not repair authority.

Then review neighboring identities and endpoints for the same design pattern. A fix to one tool method may leave bulk, export or asynchronous paths open.

Document accepted residual risk with an owner and expiry. Retest after role, tool, model or delegation changes because effective privilege can grow without a visible policy edit.

Final review questions

Ask whether every action can be traced to an authenticated principal and explicit delegation. Confirm that missing context fails closed and that no general service identity silently replaces the initiating user's narrower authority.

Review all escalation paths that join two legitimate capabilities. Check administration, support, debugging, export and asynchronous endpoints. Ensure approvals are bound to exact resources and cannot be replayed.

Before closure, verify credential revocation during active work, child-agent containment and cross-tenant denials. Keep canary roles and resources available for future regression so changes to identity infrastructure do not reintroduce the path unnoticed.

Record all identities, environments and endpoints excluded from testing. A clean result applies only to the exercised graph. When a new connector or administrative path appears, update the model and repeat neighboring escalation cases before granting production authority.