AI agent sandbox: secure execution architecture design
AI agents run code and tools on untrusted data. Build a sandbox with process, network, filesystem and secret isolation plus hard resource limits.
- AUTHOR
- Karol Rapacz / Penetration Tester (OSCP, PNPT)
- PUBLISHED
- 17 June 2026
- READING TIME
- 10 min read
- TOPIC
- AI Security
An AI agent sandbox limits the impact of incorrect plans, prompt injection and malicious code. A container alone is not a complete boundary: the agent may still have network access, secrets, runtime sockets or broad mounts.
Isolation layers
Run each task in an ephemeral environment with an unprivileged user, read-only base image and separate workspace. Drop Linux capabilities, prohibit privileged, constrain syscalls with seccomp and apply AppArmor or SELinux.
Never mount the Docker socket or home directory. Copy inputs into quarantine and export output only after validation.
Network and secrets
Deny egress by default. Allowlist exact domains, ports and methods, with protection against DNS rebinding and metadata services. Log the resolved destination at the proxy.
Inject short-lived, scoped secrets directly into tools; the model should not read them. Destroy identity and environment after the task.
Execution budgets
Limit CPU, memory, processes, storage, time, tokens, retries and tool calls. A circuit breaker stops loops that do not approach success criteria.
High-impact operations leave the sandbox as proposals requiring separate authorisation. Isolation does not grant production permission.
Tests
Test escapes, symlink traversal, fork bombs, payload downloads, metadata access, process-secret reads and DNS exfiltration. Repeat after changes to images, runtimes and policy.
OWASP recommends sandboxing arbitrary code and least-privilege tools. Combine this with agent identities and an AI incident playbook.
Architecture trust boundaries
Draw the model, orchestrator, tool executor, artefact store, network proxy and approval service as separate components. The model proposes an action but does not enforce policy. The executor validates tool name, argument schema, task identity and the current authorisation decision. Text from a webpage or document therefore cannot grant itself additional privileges.
Create an execution environment for one task and one tenant. Do not share cache, working directories or browser processes across users. Output does not flow automatically into another system: validate file type, size, symlinks, active content and sensitive data before export.
An execution policy example
Deny by default. A command may use only an approved image, unprivileged UID, constrained workspace and explicit network profile. Every exception—a new domain, write outside the workspace, longer runtime or new secret—creates a separate approval request. Approval is bound to one task and expires rather than becoming a permanent agent capability.
Log the task identifier, image and policy versions, tool name, normalised arguments, decision, resource use and export result. Never store complete secrets or unrestricted prompt content. Telemetry must come from middleware and the executor, not from the model’s narrative.
Sandbox acceptance testing
Before deployment, test access to the host filesystem, container socket, link-local and metadata addresses, other tenants, devices, parent processes and prohibited DNS. Verify process, memory, disk, time and connection limits. Force a failure halfway through a task and confirm that the environment, identity and temporary credentials are destroyed.
A sandbox reduces impact but does not replace goal validation, human control or secure tool design. Treat it as one of several independent barriers.
Minimum tool contract
Every agent tool needs an unambiguous name, closed input schema, size limit and list of possible effects. Avoid a universal run_command when a narrow operation can read one artefact or launch an approved test. The more general the tool, the more control the executor must assume.
A response should contain status, structured data and an evidence identifier. It should not expose secrets or arbitrary instructions for the next step. Normalise errors so internal paths and technology details do not enter model context unnecessarily.
Maintenance and ownership
Assign owners for the base image, network policy, seccomp profile and test suite. A runtime upgrade is a security change requiring isolation and export retesting. Measure sandbox lifetime, denials, prohibited egress attempts and budget overruns.
Run a periodic incident exercise: locate tasks executed on a vulnerable image, revoke identities, block the version and trace exported artefacts. Architecture is ready only when the team can determine scope as well as stop execution.
Sources: OWASP AI Agent Security Cheat Sheet, NIST — Agentic AI Emerging Threats.
