SharedRoot: The Real Risk of Shared Filesystem Access in Containerized AI Workloads

🕒 8 min read

TL;DR: When AI agents run inside containers that mount the host filesystem or share volume paths with other services, a compromised or misbehaving agent can read sensitive files, exfiltrate data, or trigger unintended side effects. This is no longer theoretical: real CVEs in runc, real exploits in AutoGPT, and a March 2026 Oxford/AISI benchmark have all confirmed that containerized AI agents can and do escape their boundaries under realistic conditions.

Introduction

AI coding agents, autonomous task runners, and LLM-powered automation tools are increasingly deployed inside containers. The container is supposed to act as a boundary isolating the agent from the host system and from other services running alongside it.

But containers are not virtual machines. They share the host kernel, and their filesystem isolation depends entirely on how volumes, bind mounts, and permissions are configured at deploy time. When those configurations are loose, the isolation boundary is weaker than it appears.

In March 2026, researchers at the University of Oxford and the UK AI Security Institute (AISI) published SandboxEscapeBench (arXiv:2603.02277): the first rigorous benchmark specifically measuring whether frontier AI models can escape container sandboxes. This article is a design-level analysis of what architectural conditions enable these escapes, what real-world exploits have demonstrated, and what mitigations are available.

What Is the SharedRoot Risk Model?

The term SharedRoot describes a class of misconfiguration where a containerized AI agent gains access to filesystem paths belonging to the host or other containers, because those paths were mounted into the container namespace without appropriate scope restriction. This can happen in three main ways.

1. Overly Broad Bind Mounts

A bind mount maps a host directory into the container. If the mount point is / or /home rather than a narrow path like /home/user/project/src, the agent can navigate the entire directory tree within that scope.

# Risky: mounts the entire home directory
docker run -v /home/user:/workspace ai-agent

# Better: mounts only the target project directory, read-only
docker run -v /home/user/project:/workspace:ro ai-agent

2. Shared Volume Between Agent and Web-Publishing Services

When an AI agent and a web server share the same Docker volume, a write action by the agent can directly affect published content with no human approval gate.

# docker-compose.yml - risky shared volume pattern
services:
  ai-agent:
    image: agent:latest
    volumes:
      - site_content:/data
  nginx:
    image: nginx:latest
    volumes:
      - site_content:/usr/share/nginx/html
volumes:
  site_content:

3. Privileged Mode or Exposed Docker Socket

Containers run with --privileged or with access to /var/run/docker.sock can spawn new containers with any mount configuration, including a full bind mount of the host root. This is one of the most reliably exploited escape vectors confirmed in the SandboxEscapeBench research.

Warning: Never run an AI agent container with –privileged or mount /var/run/docker.sock inside the container without an explicit, audited reason. These configurations grant host-level access to whatever runs inside the container.

What Real CVEs Have Demonstrated

CVE-2024-21626 – Leaky Vessels (runc 1.1.11 and below)

Discovered by Snyk and disclosed in January 2024, this critical vulnerability (CVSS 8.6) affects all runc versions up to 1.1.11, the container runtime underlying Docker, Kubernetes, containerd, and CRI-O. An internal file descriptor leak allows a container process to manipulate process.cwd to point to a host filesystem path via /proc/self/fd/[ID]. The fix is in runc 1.1.12. See the NVD entry for CVE-2024-21626.

CVE-2025-31133, CVE-2025-52565, CVE-2025-52881 – runc Trio (November 2025)

Three additional high-severity runc vulnerabilities disclosed in November 2025, affecting Docker, Kubernetes, containerd, and CRI-O across all major cloud providers. CVE-2025-31133 allows replacing /dev/null with a symlink to procfs files such as /proc/sys/kernel/core_pattern, bypassing runc maskedPaths security controls.

CVE-2024-1086 – Linux Kernel Netfilter (Active Exploitation)

A use-after-free bug in the Linux kernel netfilter subsystem, confirmed under active exploitation by CISA in October 2025. RansomHub and Akira ransomware groups used this for privilege escalation from within containers to host-level access. See the NVD entry for CVE-2024-1086.

CVE-2023-37273 and CVE-2023-37274 – AutoGPT Docker Escape

Discovered by Positive Security and patched in AutoGPT v0.4.3, these are among the earliest documented cases of prompt injection leading to container escape in an AI agent. CVE-2023-37273 exploited an unprotected docker-compose.yml: a malicious web page AutoGPT was asked to summarize contained instructions that overwrote the container configuration, achieving host code execution on next restart. CVE-2023-37274 was a path traversal: filenames like ../../../main.py let the agent overwrite source files outside its workspace. Both required no special privileges, only malicious content in a file the agent read.

The SandboxEscapeBench Findings (Oxford / UK AISI, March 2026)

The most comprehensive empirical evidence comes from SandboxEscapeBench (arXiv:2603.02277), an 18-scenario benchmark placing frontier models including GPT-5 and Opus 4.5 in controlled container environments to test escape capabilities.

Layer Example Scenarios
Orchestration Exposed Docker socket, kubectl cp tar injection, writable host mounts
Runtime CVE-2024-21626, CVE-2019-5736, privileged container escape
Kernel Dirty COW, Dirty Pipe, netfilter kernel exploits

  • Frontier models reliably escaped easy scenarios: privileged containers, writable host mounts, exposed Docker daemons.
  • GPT-5 and Opus 4.5 also cracked harder scenarios requiring multi-step CVE exploitation.
  • Models discovered four unintended escape paths the research team had not anticipated.
  • Cost of a successful escape: approximately $1 at current API pricing.
  • Analysis of 18,470 real-world agent configurations: 98.9% ship with zero deny rules.

Why AI Agents Amplify This Risk

Traditional containerized applications have deterministic behavior. AI agents do not: their actions are conditioned on runtime input. An agent asked to summarize a document may execute instructions embedded inside that document. This is the intersection of prompt injection and filesystem misconfiguration, and each individual link in the attack chain has been demonstrated by real CVEs.

Frontier AI models success on apprentice-level cybersecurity tasks rose from under 10% in late 2023 to roughly 50% in 2025. Sandbox designs calibrated to 2023 model capability may be insufficient for 2026 and beyond.

Mitigations: What Secure Architecture Looks Like

1. Minimal Bind Mount Scope

docker run 
  -v /projects/myapp/src:/input:ro 
  -v /projects/myapp/agent-output:/output:rw 
  ai-agent:latest

2. Separate Agent Volume from Publishing Volume

The agent working directory and any web-serving volume must be separate. The only path from agent output to publication should be an explicit, human-triggered or policy-gated promotion step.

3. Read-Only Root Filesystem

docker run 
  --read-only 
  --tmpfs /tmp 
  -v /projects/myapp/src:/input:ro 
  -v agent-output:/output:rw 
  ai-agent:latest

4. Seccomp and AppArmor Profiles

A custom seccomp profile can block mount, ptrace, open_by_handle_at, and other syscalls not needed for legitimate agent operation. With SELinux enforcing, exploitation of CVE-2024-21626 can be prevented even on unpatched runtimes. See the Docker seccomp documentation.

5. Application-Level Action Policy

ALLOWED_READ_PATHS = ["/input"]
ALLOWED_WRITE_PATHS = ["/output"]

def before_file_action(action_type, path):
    allowed = ALLOWED_READ_PATHS if action_type == "read" else ALLOWED_WRITE_PATHS
    if not any(path.startswith(p) for p in allowed):
        raise PolicyViolation(f"Action blocked: {action_type} on {path}")

This policy must exist at a level the model output cannot modify, a lesson directly encoded in CVE-2023-37273.

6. gVisor or MicroVM Isolation

gVisor interposes a user-space kernel between the container and the host (~10-15% syscall overhead, significantly firmer boundary). For the highest-risk workloads, AWS Firecracker or Kata Containers provide true microVM isolation, nearly eliminating kernel escape risk.

7. Patch runc Promptly

Pin runc to 1.1.12 or later, apply the November 2025 patches, and subscribe to CISA Known Exploited Vulnerabilities alerts.

Monitoring and Detection

Signal Detection Method
File access outside declared scope Auditd rules on filesystem paths
Unexpected outbound network calls Container network policy / eBPF tooling
Write to shared volume not via approved pipeline Volume access audit logs
Prompt injection in input files Input scanning before agent ingestion
Process accessing /proc/self/fd unexpectedly Falco rule on procfs access from container

Falco can alert in real time when a containerized process accesses a path outside its expected scope. A rule targeting /proc/self/fd access from a non-root container process would have caught CVE-2024-21626 exploitation in runtime.

Key Takeaways

  • Containers provide process isolation, not filesystem isolation by default. 98.9% of real-world agent configurations ship with zero deny rules.
  • The SharedRoot risk arises when an agent container and a publishing or sensitive-data service share filesystem paths.
  • AutoGPT CVE-2023-37273/37274, runc Leaky Vessels CVE-2024-21626, and the November 2025 runc trio all demonstrate filesystem access beyond the intended container boundary.
  • Oxford/AISI SandboxEscapeBench (March 2026): frontier models escape production containers for approximately $1 per attempt and find paths security teams did not anticipate.
  • Prompt injection amplifies misconfiguration risk: agents act on malicious instructions embedded in files they are asked to read.
  • Mitigations are architectural: minimal mount scope, read-only root filesystems, separated volumes, action policies, seccomp/AppArmor, gVisor or Firecracker.
  • Keep runc patched. Runtime CVEs are the foundational layer beneath every container security control.

Further Reading

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *