AI Security · Learn

What is AI agent sandboxing?

Sooner or later an agent will run code it wrote, or follow instructions an attacker planted. Sandboxing decides what happens next: whether the damage stays inside a disposable box or reaches your credentials, network and production data.

AI Security · LearnAI Agent Security Testing Download PDF
TL;DR

AI agent sandboxing means running an AI agent and the tools it uses inside a constrained execution environment that limits its access to the file system, network, credentials and system calls. It matters because agents execute generated code, call tools across trust domains and handle sensitive data, and any of them can be hijacked through prompt injection. Common layers are microVMs or gVisor-style kernels, container security profiles (seccomp, AppArmor, SELinux), read-only and ephemeral file systems, egress allowlists and secrets kept outside the sandbox.

By Rohit Hatagale, AI Security Lead, SecureLayer7Updated

What agent sandboxing is

A sandbox is an execution environment with deliberately narrow walls: the code inside can do its job and very little else. For AI agents, the sandbox wraps two things:

  • The tools that execute. Code interpreters, shell tools, browser automation and data transformation steps run code the model produced, often from inputs nobody reviewed.
  • The agent runtime and local MCP servers. A local the Model Context Protocol (MCP) server runs with the privileges of whoever launched it. Without a sandbox, that is the developer's full account, SSH keys and cloud credentials included.

The goal is a small blast radius. If the agent is hijacked, the attacker inherits only what the sandbox allows.

Why agents need it more than ordinary services

A normal web service runs code its developers wrote and reviewed. An agent runs code and commands that a model decided on at runtime, influenced by every document, web page and tool result it read along the way. That changes the threat model:

  • indirect prompt injection can turn "summarise this repository" into "run this install script".
  • Generated code can be wrong in harmful ways even without an attacker: deleting files, looping on a paid API, or writing secrets into logs.
  • Tools span trust domains, so misuse of one tool (a file reader) can feed another (an HTTP client) and exfiltrate data. See LLM data exfiltration.
  • Multi-tenant platforms run many users' agents on shared infrastructure, where a container escape becomes a cross-customer breach.

The layers of a good agent sandbox

  • Isolation boundary. Prefer microVMs or user-space kernels such as gVisor for untrusted code; a plain container shares the host kernel, and a a container escape turns one bad tool call into host access.
  • System call and capability limits. seccomp, AppArmor or SELinux profiles; no privileged mode, no extra Linux capabilities, non-root user.
  • File system policy. Read-only root, an ephemeral scratch directory, and only the specific project paths the task needs. Never mount the home directory, the Docker socket or credential files.
  • Network egress control. Default deny outbound; allowlist the few hosts the task needs, and route tool traffic through an an MCP gateway or egress proxy that logs it. Block cloud metadata addresses.
  • Secrets outside the box. The sandbox should never hold long-lived credentials. Inject short-lived, narrowly scoped tokens per task, or have the gateway attach them outside the sandbox.
  • Resource limits and lifetime. CPU, memory, process count and wall-clock limits, and a fresh sandbox per task or session so nothing persists for the next one.

How to test a sandbox

Assume the model is fully compromised and try to get out. From inside the sandbox, test whether you can read host files or other tenants' data, reach the cloud metadata service or internal networks, find credentials in environment variables or mounted files, persist anything between sessions, or exhaust shared resources. Then test the path in: whether indirect prompt injection in a document the agent reads can make it run code at all, and whether that code runs inside the sandbox or somewhere the designers forgot.

References

  1. [1]MCP Security Best Practices(Model Context Protocol)
  2. [2]Model Context Protocol specification(Model Context Protocol)
  3. [3]OWASP Top 10 for Agentic Applications (2026)(OWASP)
  4. [4]MITRE ATLAS(MITRE)
Related terms

Agents and MCP integrations need testing like any API, plus attacks on the model that drives them. Talk to a security expert about testing yours.

Related service
AI Penetration Testing
Adversarial testing of your LLM and AI features, prompt injection, data exfiltration, and agent abuse, with reproducible findings.
AI penetration testing

FAQ

AI agent sandboxing, asked often

Scope an engagement

Test your AI application before an attacker does.

Our AI red team probes your LLM and agent features the way an attacker would, prompt injection, tool abuse, and data exfiltration, and ships findings with reproducible attacks and fixes your team can implement.