AI Agent Sandboxes

 

AI Agent Sandboxes & Permission Boundaries

As AI agents evolve from simple chat assistants into autonomous systems executing code, running shell commands, and querying live databases, security architectures must adapt. A prompt instruction is not a security boundary. Modern AI agent security relies on two primary pillars: Runtime Sandboxing and Permission Boundaries.

1. Executive Summary

When an AI agent is granted access to tools (e.g., executing Python, running Bash scripts, interacting with cloud APIs), it gains the ability to change state in the physical or digital world.

Relying on model behavior or system prompts (e.g., "Do not delete files") to prevent harmful actions is ineffective because models can hallucinate, experience prompt injection, or make unexpected decisions.

The Core Rule of Agent Security:

Isolation (Sandbox) + Constraint (Permission Boundary) + Auditability = Safe Agent Governance

2. Core Concept 1: The Agent Sandbox (System Isolation)

What is an Agent Sandbox?

An Agent Sandbox is a temporary, isolated execution environment (like a lightweight container or microVM) designed to run untrusted code generated by an AI agent without giving that code access to the underlying host system or local network.

Key Capabilities of a Sandbox

• Filesystem Confinement: Restricts file reads and writes to a virtualized or temporary directory.

• Process Isolation: Prevents the agent from viewing or terminating host system processes.

• Network Scoping: Restricts outbound HTTP/TCP calls to approved endpoints or blocks internet access entirely during code execution.

• Ephemeral Lifecycle: Automatically destroys the environment after task completion to prevent state persistence or malware installation.

Common Sandbox Technologies

• Containers & MicroVMs: Docker, Firecracker MicroVMs, gVisor.

• OS-Native Isolation Tools: Linux bubblewrap (used by platforms like Claude Code and Codex), chroot, or cgroups.

3. Core Concept 2: Permission Boundaries (Identity & Access)

While a sandbox prevents the agent from breaking out into the host OS, a Permission Boundary limits what the agent is allowed to do within cloud networks, databases, and external APIs.

What is a Permission Boundary?

A Permission Boundary is an explicit access control policy (IAM, RBAC, or API scopes) that defines the maximum set of permissions an agent's identity can ever hold, regardless of what tools or credentials it requests.

Key Rules of Permission Boundaries

1. Separation of Capabilities:

   • READ: Fetching docs, querying logs, searching repos.

   • PROPOSED WRITE: Drafting pull requests, generating SQL scripts, preparing emails.

   • APPROVED WRITE / EXECUTE: Merging code, running database migrations, making payment API calls.

2. Short-Lived Credentials: Avoid static API keys or long-lived database passwords. Use temporary Security Token Service (STS) tokens scoped specifically to the current task.

3. Least Privilege: If an agent only needs to analyze logs from Bucket-A, its access token must strictly deny access to Bucket-B and all other resources.

4. The Two-Layer Defense Model

Effective agent security requires combining system-level sandboxing with identity-level permission boundaries:

Layer	Security Focus	Primary Function	Example Failures Addressed
Layer 1: Runtime Sandbox	Infrastructure & OS	Limits disk, RAM, CPU, processes, and host network access.	Prevents disk wiping (rm -rf /), host process access, or host socket hijacking.
Layer 2: Permission Boundary	Identity & APIs	Limits what cloud roles, DB tables, or third-party APIs the agent can invoke.	Prevents deleting production databases, exfiltrating data via approved APIs, or escalating privilege.

5. Key Risks & Failure Modes

Understanding how agent security fails helps in designing resilient architectures:

1. Confusing Prompts with Permissions:

   • The Mistake: Instructing an LLM via system prompt: "Do not modify production databases."

   • The Failure: An ambiguous prompt, injection, or unexpected agent reasoning causes it to invoke a destructive command anyway because its database credential actually had drop privileges.

2. Indirect Sandbox Escapes:

   • The Failure: The agent stays inside its sandbox, but writes a malicious file or script to a shared volume that an unsandboxed external background worker later executes automatically.

3. Credential Drift & Persistence:

   • The Failure: Passing broad admin credentials into a task. Once the task finishes, those credentials remain stored in the agent's context memory or local storage, accessible to future tasks.

6. Actionable Best Practices for Agent Developers

To build safe and reliable agentic workflows, adopt these controls:

1. Define a Permission Boundary File (AGENTS.md / IAM Policy): Explicitly declare what files, APIs, and commands an agent can Read, Write, and Never Touch before writing application code.

2. Implement Human Checkpoints (Human-in-the-Loop): Require explicit human approval whenever an agent transitions from Drafting/Proposing to Executing/External Sending (e.g., sending emails, deploying code, modifying infrastructure).

3. Reversible & Auditable Tool Calls: Ensure every tool call logs the exact input, output, system state, and timestamp. Favor reversible actions (e.g., creating a branch or draft) over destructive ones.

4. Fail Loudly & Stop: Configure agents to immediately halt execution and raise an exception when encountering an ambiguous instruction, missing evidence, or permission error, rather than improvising or guessing.