An adversary who can only send text to an AI agent gains every permission that agent holds the moment it follows their instructions, which makes over-privileged agents the shortest escalation path in most AI deployments. MITRE ATLAS defines Privilege Escalation, AML.TA0012, as the adversary "trying to gain higher-level permissions", and lists four techniques in ATLAS 2026.10: two specific to AI (AI Agent Tool Invocation and LLM Jailbreak) and two adapted from ATT&CK (Valid Accounts and Escape to Host). This hub explains how they chain, what the ATLAS case studies show, which to address first, and the detection and mitigation priorities across the tactic. It is for AI platform owners, identity teams and detection engineers. Each technique has its own guide, linked below; this page does not repeat them. For the framework overview, see the MITRE ATLAS Guide.
Key takeaways
- Tool invocation is the dominant path. Of 19 Privilege Escalation steps in ATLAS case studies, 15 use AML.T0053 AI Agent Tool Invocation: the adversary borrows the agent's tools and the user's delegated access instead of exploiting a bug.
- Escalation follows execution. In the case study step graphs, 11 of the step links that lead into a Privilege Escalation step come from Execution steps, usually prompt injection, so the escalation is only as large as the agent's permissions.
- Sandboxes are the second line, and they are attacked. AML.T0105 Escape to Host appears in three case studies, including one where a stolen gateway token was used to switch an agent's sandbox off.
- Jailbreaks escalate within the model. AML.T0054 LLM Jailbreak removes the model's own restrictions; ATLAS rates it Realized and maps five mitigations to it, though no case study step tags it under this tactic.
- Agent identity design decides the blast radius. Least privilege tools, separate agent identities and approval for sensitive actions shrink what any escalation can reach.
What Privilege Escalation means for AI systems
ATLAS inherits the ATT&CK description: adversaries often enter with unprivileged access and need elevated permissions, such as SYSTEM or root, local administrator, an account with admin-like access, or an account with access to a specific system or function. In AI systems the "unprivileged access" is often just the ability to put text in front of a model: a message, a document, a calendar invitation, a web page or a tool description. The "higher-level permissions" are whatever the model can do on someone else's behalf: run shell commands, read mailboxes, modify records, control smart devices or call cloud APIs.
That gives three levels of escalation. Within the model: a jailbreak makes the model ignore its policy. Through the agent: injected instructions cause the agent to use tools and delegated credentials the adversary does not hold. Out of the runtime: code the agent executes escapes its container or sandbox, or a stolen agent token is used directly. The ATT&CK description also notes overlap with Persistence, which applies to agents too: a modified agent configuration or memory can keep elevated behaviour across sessions.
Every technique in the tactic
Maturity is the ATLAS rating (Feasible, Demonstrated or Realized). Case study steps are counted from the ATLAS 2026.10 data file: each procedure step tagged with tactic AML.TA0012 and that technique. None of the four has sub-techniques.
| ID | Technique | Maturity | Case study steps | ATT&CK counterpart | What is gained |
|---|---|---|---|---|---|
| AML.T0053 | AML.T0053 AI Agent Tool Invocation | Demonstrated | 15 | None | Use of the agent's tools and the user's delegated access: shell, email, calendar, enterprise search, smart home, URLs |
| AML.T0105 | AML.T0105 Escape to Host | Realized | 3 | T1611 Escape to Host | Execution on the underlying host or cluster instead of the sandbox |
| AML.T0012 | AML.T0012 Valid Accounts | Realized | 1 | T1078 Valid Accounts | Direct use of an agent, gateway or service credential |
| AML.T0054 | AML.T0054 LLM Jailbreak | Realized | 0 | None | Model behaviour outside its guardrails and system instructions |
Valid Accounts and LLM Jailbreak also sit in other ATLAS tactics, and the techniques that usually come just before escalation, AML.T0051 LLM Prompt Injection and AML.T0050 Command and Scripting Interpreter, have their own guides.
How adversaries chain into Privilege Escalation
Counting the step links that lead directly into a Privilege Escalation step across ATLAS 2026.10 case studies gives: Execution 11, Defense Evasion 5, and one each from Exfiltration, Credential Access, Persistence and Discovery. Fourteen case studies include an escalation step. Three chains recur.
Chain 1: indirect prompt injection, tool invocation with delegated access
Untrusted content carries instructions that the agent follows using the victim's connected services. AML.CS0063 records Gemini invoking Google Calendar, Google Home, Android Utilities and Zoom from a calendar invitation; AML.CS0026 records a Microsoft 365 Copilot plugin manipulated to act as an insider in a financial transaction; AML.CS0039 records Atlassian MCP tools invoked through a Jira ticket; AML.CS0066 records ChatGPT connectors and web access used under the victim's authority. In each case the adversary held no credential: the agent's grant was the privilege.
Chain 2: tool invocation to code execution
Agents with shell or code tools turn escalation into command execution. AML.CS0045 records Cursor's run_terminal_cmd tool invoked by injected instructions; AML.CS0049 records Claude Code running a shell command from a poisoned skill; AML.CS0048 records an exposed ClawdBot instance invoking its bash skill as the root user; AML.CS0062 records a Semantic Kernel search tool invoked with an argument designed to escape its filter; AML.CS0055 records a computer use agent pasting a malicious command from its clipboard.
Chain 3: stolen agent credentials or sandbox escape
The adversary leaves the agent's intended boundary. In AML.CS0050 a malicious script used a stolen OpenClaw gateway token (AML.T0012) to call the gateway API, then disabled sandboxing so commands ran on the host (AML.T0105). In AML.CS0068 excessive permissions on a storage driver let evaluation agents create a privileged pod. AML.CS0052 records code escape techniques used against LLM-integrated applications. See the AI Agent Sandboxing and Code Execution Guide.
Where to start: ranked techniques for defenders
- AML.T0053 AI Agent Tool Invocation: 15 of 19 recorded steps, present in almost every agentic case study, and ATLAS maps 13 mitigations to it. Reducing tool scope and gating sensitive tools gives the biggest reduction in escalation risk.
- AML.T0105 Escape to Host: rated Realized; essential wherever agents execute code. The controls (hardened sandboxes, no privileged containers, no host mounts) are well understood from container security.
- AML.T0012 Valid Accounts: agent gateway tokens, API keys and service credentials grant everything the agent can do without any injection. Treat them as privileged non-human identities.
- AML.T0054 LLM Jailbreak: important but rarely sufficient alone. A jailbroken model with no sensitive tools reaches little; prioritise it where model output is itself the privileged action, such as content generation that bypasses policy.
Detection priorities across the tactic
| Signal | Techniques | Telemetry needed | What to alert on |
|---|---|---|---|
| Tool calls that do not match the user request | AML.T0053 | Agent tool call log with arguments, user prompt and context sources | Sensitive tools (shell, email, payments, device control) invoked in a session where the user asked for something else, or after external content was retrieved |
| Scope drift | AML.T0053 | Per agent baseline of tools and resources used | First use of a tool or connector by an agent; access to resources outside its normal set (the aim of AML.M0038 AI Agent Scope Drift Detection) |
| Sandbox configuration change | AML.T0105 | Agent runtime configuration logs, container runtime and Kubernetes audit logs | Sandbox disabled, privileged pod or container created, host path mounts, new capabilities added |
| Agent credential used outside the agent | AML.T0012 | Gateway and API authentication logs | Agent or gateway tokens used from new hosts, browsers or networks; tokens used outside the agent process |
| Guardrail bypass attempts | AML.T0054 | Prompt and response logs, guardrail verdicts | Repeated guardrail blocks from one user followed by a policy violating response; known jailbreak patterns |
Metrics that show it is working
- Tool privilege: share of agents whose tools are scoped to the minimum set for their task, reviewed in the last quarter.
- Sensitive action gating: percentage of shell, payment, delete and external send tools behind human approval or a policy check.
- Sandbox posture: share of code executing agents running unprivileged, without host mounts and with sandbox settings that the agent cannot change.
- Credential hygiene: share of agent and gateway tokens that are short lived and bound to the agent's runtime.
- Red team escalation rate: number of injection to sensitive tool paths found per exercise, trending down.
Mitigation priorities
ATLAS 2026.10 maps 17 mitigations to techniques in this tactic; the MITRE ATLAS Mitigations Guide explains each one.
| Control point | ATLAS mitigations | Techniques mapped | Practical form |
|---|---|---|---|
| Agent permissions | AML.M0026 Manage AI Agent Service Access, AML.M0027 Manage User-Delegated AI Agent Access, AML.M0028 Enforce Access Controls for AI Agent Tools | AML.T0053 | Minimum tools per agent, narrow OAuth scopes, per tool authorisation checks outside the model |
| Untrusted input and output | AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data, AML.M0033 Input and Output Validation for AI Agent Components, AML.M0032 Segmentation of AI Agent Components | AML.T0053 | Disable sensitive tools once untrusted content is in context; validate tool arguments; split browsing and privileged components |
| Human oversight and monitoring | AML.M0029 Human In-the-Loop for AI Agent Actions, AML.M0038 AI Agent Scope Drift Detection, AML.M0024 AI Telemetry Logging and Monitoring | AML.T0053 | Approval for sensitive actions showing full arguments; baseline and alert on new tool use |
| Model level controls | AML.M0020 Generative AI Guardrails, AML.M0021 Generative AI Guidelines, AML.M0022 Generative AI Model Alignment, AML.M0008 Validate AI Model, AML.M0035 AI Red Team | AML.T0053, AML.T0054 | Input and output guardrails, system instructions, aligned models, jailbreak testing before release |
| Accounts and credentials | AML.M0005 Control Access to AI Models and Data at Rest, AML.M0019 Control Access to AI Models and Data in Production, AML.M0043 AI Agent External Resource Lifecycle Management | AML.T0012 | Strong authentication for model and agent endpoints, credential lifecycle for agent resources, removal when agents are retired |
ATLAS maps no mitigation to AML.T0105 in 2026.10; the counterpart ATT&CK technique T1611 Escape to Host and container hardening practice apply.
Phased rollout
- Inventory agent privilege: for each agent, list its tools, connectors, delegated scopes and credentials, and who it acts for. See the Agent Identity and Access Guide.
- Remove and narrow: drop unused tools, narrow OAuth scopes and give each agent its own identity rather than a shared service account.
- Gate sensitive tools: add approval or policy checks to shell, payment, delete and device control tools, enforced outside the model. See the AI Agent Action Approvals and Spending Limits Guide.
- Harden the runtime: run code tools in unprivileged sandboxes the agent cannot reconfigure, with no host mounts and no cloud credentials.
- Monitor in alert mode, then enforce: run scope drift analytics against a two to four week baseline before blocking; keep per agent overrides so a blocked workflow can be restored quickly.
- Test escalation paths: add injection to tool, jailbreak and sandbox escape scenarios to the AI red team plan. See the AI Red Teaming Guide.
Decision guidance
- User delegated or agent own identity: delegated access keeps actions within the user's rights but gives an injected agent all of them; a dedicated agent identity with narrower rights limits the blast radius but needs its own governance.
- Approval or policy engine: approvals fit infrequent, high impact actions; a policy engine that checks each tool call against rules fits high volume agents where approval fatigue would set in.
- Small teams: start by removing shell and send tools from agents that do not need them and by running coding agents in disposable containers.
Where identity fits
This tactic is an identity problem in AI form. The privilege an adversary gains through AML.T0053 is the agent's delegated grant; through AML.T0012 it is the agent's own token; through AML.T0105 it is the host's service identity and cloud credentials. Treat agents as non-human identities with owners, scoped and short lived credentials, regular recertification and removal when retired. See the Delegation Chains and Attenuated Authority for AI Agents and the Agent Permission Drift guide.
Common failure patterns
- Relying on the model to refuse: guardrails reduce jailbreaks but do not enforce authorisation; checks must run outside the model.
- One agent, every connector: an assistant connected to mail, calendar, files and devices turns one injected invitation into control of all of them, as AML.CS0063 shows.
- Agents running as root or administrator: AML.CS0048 records a bash skill running as root on an exposed instance.
- Sandbox settings the agent or a token can change: in AML.CS0050 a stolen gateway token was enough to switch sandboxing off.
- Over-permissioned platform components: AML.CS0068 shows excessive storage driver permissions turning agent code execution into a privileged pod.
- Approval prompts users click through: confirmation without full arguments and context gives little protection.
Framework mapping
| Framework | Relevant references |
|---|---|
| MITRE ATT&CK v20 | T1078 Valid Accounts, T1611 Escape to Host |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, AC-3 Access Enforcement, AC-2 Account Management, CM-7 Least Functionality, SC-39 Process Isolation, SI-10 Information Input Validation, AU-6 Audit Record Review, Analysis, and Reporting |
| NIST CSF 2.0 | PR.AA-05 (access permissions managed with least privilege), PR.PS-01 (configuration management), DE.CM-09 (runtime environments monitored), DE.AE-02 (adverse events analysed) |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection, LLM06 Excessive Agency |
Practitioner checklist
- Every agent has an inventory of tools, connectors, scopes and credentials, with an owner.
- Agents have only the tools their task needs; unused connectors are removed.
- Shell, payment, delete, external send and device control tools require approval or a policy check enforced outside the model.
- Sensitive tools are disabled when untrusted content is in the agent's context.
- Code executing agents run unprivileged in sandboxes they cannot reconfigure, without host mounts or cloud credentials.
- Agent and gateway tokens are short lived, scoped and monitored for use outside the agent.
- Scope drift analytics alert on first use of tools and resources per agent.
- The AI red team plan covers injection to tool, jailbreak and sandbox escape paths.
Standards and references
- MITRE ATLAS: Privilege Escalation (AML.TA0012)
- MITRE ATLAS: atlas-data repository (techniques, mitigations and case studies)
- MITRE ATLAS: Prompt-Based Attacks Against Gemini via Calendar Invitations (AML.CS0063)
- MITRE ATLAS: OpenClaw 1-Click Remote Code Execution (AML.CS0050)
- MITRE ATT&CK: Privilege Escalation (TA0004)
- OWASP: Top 10 for LLM Applications 2025
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE ATLAS Guide, OWASP LLM Top 10 LLM06 Excessive Agency Guide, AI Agent Sandboxing and Code Execution Guide, Agent Identity and Access Guide.