Quick summary
A sandbox gives an AI agent a controlled place to run code and use tools without granting unrestricted access to the host or organisation. Isolation may use containers, virtual machines, operating-system controls or disposable cloud environments. Security depends on the full capability boundary, not the label “sandbox.”
What the boundary controls
- Processes: which programs can start and how much CPU or memory they consume.
- Files: which directories are visible, writable or persistent.
- Network: which destinations, protocols and ports are allowed.
- Tools: which APIs and commands the agent can invoke.
- Identity: what credentials, roles and approvals accompany each request.
- Lifetime: whether the environment is destroyed after the task.
A typical execution flow
- The orchestrator creates an isolated workspace from a trusted image.
- Only task-relevant files and short-lived credentials are mounted.
- A policy broker validates tool and network requests.
- The agent acts, while logs and resource limits monitor behaviour.
- High-impact actions require separate approval or occur outside the sandbox through a guarded service.
- Results are exported, secrets revoked and the workspace destroyed.
Why isolation can fail
A container shares more of the host kernel than a full virtual machine, so a kernel or runtime vulnerability may permit escape. Misconfigured file mounts can expose host data. Open internet access enables exfiltration. A powerful API token can let the agent modify production even if its local filesystem is perfectly isolated.
Shared caches, logs and build artifacts can also leak information between tasks. Resource exhaustion may disrupt neighbouring services without escaping the environment.
Prompt injection changes the threat model
An agent reads repositories, webpages, documents and tool output that can contain hostile instructions. If it treats that content as authority, it may disclose secrets or perform an attacker’s requested action. The sandbox should assume the agent can be manipulated and enforce policy independently of the model’s judgment.
Least privilege and strong identity
Give each agent and task a distinct identity, minimum permissions and expiring credentials. Do not lend the agent a human administrator token. Separate read, write, deploy and payment capabilities, and make sensitive actions require stronger authentication or human confirmation. This preserves attribution and limits blast radius.
Testing the sandbox
Security teams should test forbidden file access, network egress, privilege escalation, secret discovery, persistence and cross-tenant leakage. Dependency and base-image patching matter because isolation is implemented by software. Logs should show both successful and denied actions without recording secrets.
Reality check
A sandbox does not make an autonomous agent safe in every sense. It cannot prevent harmful text, flawed code or misuse of an intentionally allowed capability. Allowing access to production, email or money transfers expands the real boundary to those systems. Safety claims must list permitted actions and failure assumptions.
A defensible architecture
Use disposable environments, read-only inputs where possible, default-deny networking, allowlisted tools, resource quotas, short-lived scoped credentials and an external policy gate. Keep deployment and other irreversible actions outside the agent workspace. Defence in depth matters because every isolation layer can contain defects.
