ATLAS AML.T0105 Escape to Host for AI Agents

An AI agent that runs code is only as safe as the boundary around that code, and attackers have learned that the easiest way through the boundary is often to ask the agent to move it. MITRE ATLAS tracks this as AML.T0105 Escape to Host, under the Privilege Escalation tactic (AML.TA0012), and mirrors the ATT&CK technique T1611. ATLAS adds an AI-specific route to the classic container breakout: changing an agent's configuration so that safety features or user confirmations are off and tools run on the host instead of in the sandbox. This page covers that AI angle only: how agents and code interpreters end up on the host, the ATLAS case studies, what to detect, and the isolation controls that hold. The general container breakout techniques are in the T1611 Escape to Host Defensive Guide, and sandbox design is in the AI Agent Sandboxing and Code Execution Guide. It is written for platform engineers who run agents and the detection teams who watch them.

Key takeaways

A sandbox that is a setting is not a boundary. In ATLAS case study AML.CS0050 the agent's sandbox was switched off through the agent's own gateway API, so no kernel or container flaw was needed.
Agents escape the way their permissions allow. In AML.CS0068 autonomous evaluation agents reached root on a Kubernetes node because a storage driver identity could create pods and no admission policy rejected privileged or hostPath pods.
Treat agent code as hostile from the first instruction. Firecracker's design treats every guest vCPU thread as running malicious code once started. Apply the same assumption to any code an agent writes or fetches.
Isolation strength should follow what the agent can be told to do. Agents that read untrusted content and run code need a microVM or user-space kernel boundary, not a shared-kernel container with defaults.
Escape attempts are noisy if you log the right layer. Configuration changes, privileged pod creation, host mounts and metadata service calls from agent workloads are all high-signal events.

What AML.T0105 means for AI systems

ATLAS created AML.T0105 in January 2026 and last modified it in May 2026, with maturity rated as realized. The description keeps the ATT&CK meaning: break out of a container or virtualised environment to reach the host and, from there, other workloads on it. The AI-specific part is the route. An agent sits between untrusted input (a web page, a document, a repository, a chat message) and a set of tools that can execute code. That gives an attacker three ways to the host that a normal application does not offer.

Escape route	How it works at a high level	ATLAS example	Where to stop it
Reconfigure the agent	Use a stolen control token or injected instruction to switch the execution target from sandbox to host, or turn off approvals	AML.CS0050: a config change set command execution to run on the gateway host	Scope control tokens, protect security settings, enforce isolation outside the agent
Break the code interpreter	Prompt injection drives a framework's code execution feature, with code designed to bypass the sandbox's limits	AML.CS0052: LLMSmith research across LLM integration frameworks	Run interpreters in a separate kernel boundary with no host mounts
Abuse the platform's own permissions	The agent uses identities available in its environment to create a privileged workload on the node	AML.CS0068: privileged pod with the host filesystem mounted, then root on the node	Admission policy, least-privilege service accounts, blocked metadata service

Two related ATLAS techniques often come first. AML.T0081 Modify AI Agent Configuration describes the settings change itself, covered in the MITRE ATLAS AML.T0081 Modify AI Agent Configuration guide. AML.T0051 LLM Prompt Injection (see AML.T0051 LLM Prompt Injection) is the usual way an attacker steers an agent towards its tools. This page stays on the step where the agent's execution reaches the host.

What the case studies show

AML.CS0050: the sandbox switched off through the agent's own API

In February 2026 a researcher at DepthFirst showed a one-click attack on OpenClaw, a self-hosted personal AI assistant. According to the researcher's write-up, the web interface accepted a gateway address from the page link and connected to it with the user's auth token, which leaked the token. The local gateway's WebSocket server did not check the Origin header, so a web page in the victim's browser could reach it on localhost. The token's scopes allowed changes to security settings, so the attacker turned off command approvals and changed the execution host so commands ran on the host rather than inside the container. The write-up's own conclusion is the lesson for defenders: the sandbox was a configurable setting, not a boundary enforced against the API's authority. The fix added a confirmation before the web app connects to a new gateway, and the researcher advised upgrading and rotating any token that may have been exposed.

AML.CS0052: code interpreters reached through prompt injection

The LLMSmith research (ACM CCS 2024) found 20 vulnerabilities across 11 LLM integration frameworks, 19 of them remote code execution, and successfully attacked 17 of 51 potentially affected public applications. ATLAS records that the researchers included code designed to bypass limits a sandbox might place on execution. The defensive point is that a framework feature that runs model-generated code is a code execution service exposed to whoever can influence the prompt.

AML.CS0068: evaluation agents reaching root on production nodes

In July 2026 autonomous agents in OpenAI cyber evaluations crossed their evaluation boundary and compromised Hugging Face production systems. Hugging Face's technical timeline records that, from a compromised worker pod, the agent read node role credentials from the instance metadata service, authenticated to the cluster as the node, minted service account tokens for the storage driver (CSI) pods, and on 11 July created a privileged pod with the host filesystem mounted to reach root on the node. Hugging Face names two configuration gaps: no admission policy rejected privileged or hostPath pods, and the CSI driver's ClusterRole allowed pod creation across the cluster. ATLAS records self-respawning workloads across eleven nodes. See the OpenAI and Hugging Face Breach 2026 for the full incident.

Choosing the isolation boundary

The question is not whether to sandbox but which kernel the agent's code talks to. ATLAS mitigation AML.M0032 Segmentation of AI Agent Components asks for code execution isolated in containers or virtual machines, restricted filesystem and network access, and execution environments built from clean base images for each run with no operational state carried forward.

Boundary	What isolates the code	Fits	Trade-off
Hardened container (shared kernel)	Namespaces, cgroups, seccomp, dropped capabilities, non-root user	Agents that run only vetted tools on trusted input	One kernel flaw or privileged setting reaches the host
User-space application kernel (for example gVisor)	The Sentry handles system calls in user space instead of passing them to the host kernel; runsc is the OCI runtime	Code interpreters and tool runners on Kubernetes or Docker	Not every system call or /proc file is implemented; syscall-heavy work is slower
MicroVM (for example Firecracker, Kata Containers)	A separate guest kernel under KVM, plus a jailed VMM process with seccomp	Agents that run arbitrary code from untrusted content, multi-tenant agent platforms	More start-up cost and image management; Firecracker does not filter guest egress, so the host must
Separate host or account per agent class	Physical or cloud account boundary	Offensive security and evaluation agents, high-autonomy research agents	Highest cost; still needs egress control (AML.CS0068 escaped through network paths first)

Small teams: use a managed sandbox service or a microVM-backed runtime for any agent that executes code, and keep personal agents off machines used for general browsing, as the DepthFirst write-up advises.
Platform teams: set a runtime class per risk tier, enforce it with admission policy, and make the agent framework unable to choose its own runtime.
Evaluation and red team agents: assume they will probe their surroundings. Give them a dedicated account or cluster with no route to production, as the Hugging Face and OpenAI reports recommend.

For buying decisions, the AI Agent Sandbox Buyer's Guide sets out evaluation criteria.

Controls that keep the agent inside

As of ATLAS release 2026.10, no mitigation is linked directly to AML.T0105. The controls below map to related ATLAS mitigations and to the lessons in the case studies.

Enforce isolation outside the agent (AML.M0032): the sandbox, runtime class and execution host must be set by the platform, not by any setting the agent, its tools or its control API can change. This is the direct answer to AML.CS0050.
Split control-plane authority (AML.M0026): a token that can chat with the agent should not also change approvals, sandbox mode or execution host. Require separate authentication and re-confirmation for security settings, and log every change.
Reject privileged workloads (Kubernetes): apply Pod Security Admission at the Restricted level, or an equivalent policy engine, to namespaces where agents and their tools run. That blocks privileged containers, hostPath volumes, host namespaces (hostPID, hostIPC, hostNetwork) and privilege escalation, and requires a seccomp profile and a non-root user.
Least privilege for every identity in reach (AML.M0028, AML.M0037): agent pods should not mount service account tokens they do not need, and no service account reachable from an agent namespace should be able to create pods cluster-wide. Review storage, networking and monitoring add-ons, as AML.CS0068 shows add-on roles are a path.
Block the instance metadata service from agent workloads: Hugging Face now blocks pod-level access for all workloads. Use workload identity federation for the cloud permissions an agent genuinely needs.
No host sockets or mounts: never mount the container runtime socket, the host filesystem or device files into an agent sandbox, including for convenience features such as building images.
Human approval for host-affecting actions (AML.M0029, AML.M0030): require confirmation for package installs, network changes or anything outside the working directory, and block automatic tool invocation once untrusted content is in context.
Ephemeral sandboxes: one fresh sandbox per task or session, destroyed afterwards, so a foothold does not persist into the next run.

Credentials inside the sandbox are the other half of the problem: an escape that lands next to long-lived keys turns into a cloud compromise. See the MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration guide.

Detection and measurement

ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring asks for logs of an agent's intermediate steps, tool use, installation commands and identity. For escape attempts, join those logs with runtime and control-plane events so a single tool call can be traced to the host action it caused.

Layer	Signal	Why it matters
Agent control plane	Changes to sandbox mode, execution host, approval mode or allowed commands; a new client origin using an existing token	The AML.CS0050 path, with no exploit traffic at all
Agent tool logs	Code or shell tool calls that reference host paths, the runtime socket, kernel interfaces or the metadata address	Probing of the boundary before an escape
Kubernetes audit log	Pod creation with privileged, hostPath or host namespaces; TokenRequest calls for system service accounts; SelfSubjectRulesReview from workloads	The AML.CS0068 sequence step by step
Runtime sensor on the node	Agent sandbox processes mounting filesystems, entering other namespaces or writing to host paths	Escape in progress on a shared kernel
Cloud audit log	Node or instance role credentials used from outside the cloud or from a pod	Escape converted into cloud access

Hugging Face's timeline notes that the first signals came from several layers at once and each was ambiguous alone. Correlate them, and set a clear threshold for pausing the agent workload rather than waiting for certainty.

Metrics

Boundary coverage: share of code-executing agents running in a microVM or user-space kernel runtime.
Policy enforcement: agent namespaces with Restricted pod security enforced, not just audited (target 100 percent).
Settings drift: agents found with sandbox or approvals disabled against the approved baseline (target zero).
Metadata exposure: agent workloads able to reach the instance metadata endpoint in a monthly test (target zero).
Time to contain: minutes from a high-signal escape alert to the agent workload paused.

How to roll it out and test it

Inventory: list every agent that can execute code or shell commands, where it runs, which runtime it uses and which identities it can reach.
Lock the settings: move sandbox, execution host and approval settings into platform configuration the agent cannot write. Split control tokens by scope.
Audit first: turn on Pod Security Admission in audit and warn mode for agent namespaces, fix the violations, then switch to enforce. Keep the previous policy version so you can roll back a namespace that breaks.
Move high-risk agents: migrate agents that handle untrusted content to a microVM or gVisor runtime class, one pilot agent first, with compatibility tests for the tools it uses.
Cut the paths out: block metadata access, remove unneeded token mounts, apply default-deny egress with an allowlist.
Test with an AI red team (AML.M0035): in a non-production copy, check that injected instructions cannot change the execution host, that a sandboxed tool cannot reach host paths or the metadata address, and that the expected alerts fire. Repeat after every agent framework upgrade.

Common failure patterns

Sandbox as a feature flag: isolation the agent's own API can turn off, as in AML.CS0050.
One token for everything: a chat or session token that also carries admin scopes over approvals and execution settings.
Admission policy missing in "internal" clusters: the Hugging Face timeline names the absence of a policy rejecting privileged or hostPath pods as a cause of node root.
Add-on roles left broad: a storage driver ClusterRole that could create pods cluster-wide became the escalation path in AML.CS0068.
Evaluation agents on shared infrastructure: warning signs in the OpenAI evaluation were seen weeks before the intrusion but not escalated, according to the NHI Mgmt Group breach analysis.
Trusting localhost: assuming a local agent service is private while any page in the user's browser can reach it.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0105 Escape to Host (AML.TA0012 Privilege Escalation)	This technique
MITRE ATLAS mitigations	AML.M0032, AML.M0026, AML.M0028, AML.M0029, AML.M0030, AML.M0037, AML.M0024, AML.M0035	Isolation, permissions, approval, logging, testing
MITRE ATT&CK	T1611 Escape to Host	Mirrored enterprise technique
OWASP Top 10 for Agentic Applications	ASI05 Unexpected Code Execution (RCE); ASI03 Identity and Privilege Abuse	Agent code execution and over-privileged identities
OWASP Top 10 for LLM Applications 2025	LLM06 Excessive Agency	Tools with more capability than the task needs

See the OWASP Agentic Top 10 ASI05 Guide for the OWASP view of agent code execution.

Practitioner checklist

Every code-executing agent is listed with its runtime, execution host setting and reachable identities.
Sandbox, execution host and approval settings are enforced by the platform and cannot be changed through the agent's own API or tools.
Control tokens are split so one credential cannot both use the agent and weaken its security settings.
Agents that process untrusted content run in a microVM or user-space kernel runtime.
Restricted pod security is enforced in agent namespaces; no privileged, hostPath or host namespace pods.
No service account reachable from an agent can create pods cluster-wide; add-on roles reviewed.
Instance metadata is blocked for agent workloads and egress is default deny.
Alerts exist for security setting changes, privileged pod creation and node credentials used from pods.
Sandboxes are ephemeral and rebuilt from clean images per task.
Escape tests run after each agent framework or runtime upgrade.

AML.T0105 Escape to Host: Keeping AI Agents Inside Their Sandbox