Sandboxing Agent Tool Execution
Overview
OS-level enforcement of filesystem and network isolation around agent tool execution.
Once an agent can execute code or shell commands, least-privilege prompting alone is not a security boundary. Containers alone are often incomplete without network and filesystem restrictions.
Where used: Production agent platforms, Sandboxed execution environments, Code-interpreter features
Why learn this
- To prevent compromised agents from exfiltrating sensitive data like SSH keys.
- To understand why a broad domain allowlist can still be a data-exfiltration path.
- To implement robust sandbox boundaries using both filesystem and network isolation.
Code walkthrough
# ❌ NAIVE SETUP: High exfiltration risk
naive_sandbox = {
"filesystem": {
"allowWrite": ["/home/user/"]
},
"network": {
"allowedDomains": ["*.github.com"]
}
}
# ✅ SECURE SETUP: Independently scoped axes
secure_sandbox = {
"filesystem": {
"allowWrite": ["/app/workspace/build"]
},
"network": {
"allowedDomains": ["registry.npmjs.org"]
}
}Focus: Each axis must be scoped independently. The naive setup allows broad write access to the home directory and network access to any GitHub domain, creating an exfiltration path via gists. The secure setup scopes filesystem writes exclusively to the build directory and network access solely to the required package registry.
Common mistakes
- container-alone-is-sandboxing: Running an agent's code-execution tool inside a Docker container is, by itself, insufficient isolation against a compromised agent. Effective sandboxing requires both filesystem and network isolation. Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys. Without filesystem isolation, a compromised agent could backdoor system resources to gain network access.
- trusted-domain-allowlist-is-safe: Adding a well-known, trusted domain (like github.com) to a sandboxed agent's network allowlist is dangerous because the destination itself being reputable does not make it safe. The sandbox proxy allows or denies based on the requested hostname without inspecting TLS-encrypted contents. A compromised agent can still create a public gist or repo on an 'allowed' host and exfiltrate data through it.
Recall questions
- Why is a Docker container with default networking insufficient for sandboxing an agent?
- Why is allowlisting 'github.com' a security risk for a code-execution sandbox?
- What are the two required axes for effective agent code execution sandboxing?
Understanding checks
What is the critical exfiltration risk in this sandbox configuration?
The sandbox allows read access to '/etc/secrets' and allows outbound network traffic to 'github.com'. A compromised agent could read the secrets and POST them to a public GitHub Gist.
Network isolation and filesystem isolation must be securely scoped together. Even trusted domains like github.com can be used as data exfiltration vectors if the agent has access to sensitive files.
A developer places their agent's Python code execution tool inside a standard Docker container and considers it securely sandboxed from data exfiltration. Are they correct?
No. A standard Docker container has default bridge networking, which allows outbound internet access.
Containers isolate processes, but without explicit network restrictions (like disabling egress) and strict filesystem boundaries, they are incomplete sandboxes.
Practice tasks
Scope a Secure Sandbox
Write a JSON configuration for a sandbox that only allows reading from '/project/src', writing to '/project/out', and strictly prevents all outbound network access by emptying the allowed domains.