Agent Sandboxing¶
Agent sandboxing isolates AI Agent execution from critical enterprise systems, resources, credentials, and the host environment, limiting the impact of incorrect, malicious, or unintended agent actions.
📖 Overview¶
AI Agents can do more than generate text.
They may:
- Execute code
- Read files
- Write files
- Access databases
- Invoke APIs
- Run shell commands
- Install packages
- Interact with cloud services
- Modify application state
- Process untrusted content
This creates a fundamental security problem:
What happens if the agent makes a wrong decision or executes an unsafe action?
A production architecture should assume that agent actions can fail.
Therefore, the agent should operate inside controlled execution boundaries.
AI Agent
│
▼
Action Request
│
▼
Policy / Guardrail
│
▼
Sandbox
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Files Code Network
│ │ │
└─────────────┼─────────────┘
↓
Controlled Result
│
▼
Agent
The fundamental principle is:
An agent should never receive more execution capability than is required for the task.
🎯 Learning Objectives¶
After completing this chapter, you will understand:
- Why AI Agents require sandboxing
- Agent execution boundaries
- Process isolation
- Container isolation
- Virtual machines
- MicroVMs
- Code execution sandboxes
- File-system isolation
- Network isolation
- Resource limits
- CPU and memory controls
- Execution timeouts
- System-call restrictions
- Read-only environments
- Ephemeral environments
- Workspace isolation
- Dependency isolation
- Tool isolation
- Cloud execution boundaries
- Sandbox lifecycle
- Sandbox cleanup
- Multi-tenant sandboxing
- Untrusted code execution
- Prompt injection containment
- Defense in depth
- Sandbox observability
- Sandbox failure handling
- Enterprise sandbox architecture
1. Why AI Agents Need Sandboxing¶
Traditional applications generally execute predetermined operations.
Agents can dynamically decide what to execute.
The agent may make mistakes.
For example:
If the generated code has unrestricted access:
the potential impact becomes much larger.
Sandboxing limits this blast radius.
2. The Agent Execution Boundary¶
A useful architecture separates:
from:
Conceptually:
The agent proposes an action.
The sandbox determines where and under what constraints that action executes.
This distinction is important because:
The LLM should not be the final security boundary.
3. What Should Be Sandboxed?¶
Potentially untrusted operations include:
Code Execution
Shell Commands
File Manipulation
Browser Automation
Plugin Execution
Third-Party Tools
Scripts
Data Processing
Package Installation
External Programs
A production system should evaluate each capability independently.
Not every capability requires the same sandbox.
4. Tool Execution vs Sandbox¶
A tool may be safe or unsafe depending on what it can access.
For example:
may expose only a controlled API.
But:
can potentially access:
Therefore:
should be evaluated for each capability.
5. Principle of Least Privilege¶
Sandboxing follows the same principle as authorization:
Give the agent only what it needs.
For example:
Task:
Analyze CSV
Required:
✓ Read input CSV
✓ Write result file
✓ Execute Python
Not Required:
✗ Access SSH
✗ Access Production Database
✗ Modify Host Files
✗ Access Cloud Credentials
A sandbox should enforce these boundaries.
6. Sandbox Isolation Levels¶
Different workloads require different isolation strengths.
A simplified hierarchy is:
Application Isolation
↓
Process Isolation
↓
Container Isolation
↓
MicroVM Isolation
↓
Virtual Machine Isolation
↓
Dedicated Environment
The appropriate choice depends on:
7. Process Isolation¶
A lightweight approach is to execute agent tasks in isolated processes.
Controls may include:
Process isolation can be efficient but may provide weaker isolation than stronger virtualization approaches.
It should therefore be selected according to the threat model.
8. Container Sandboxing¶
Containers provide a common execution boundary.
Containers can provide:
- Filesystem isolation
- Process isolation
- Resource limits
- Network controls
- Dependency isolation
- Reproducible environments
However:
A container is not automatically a complete security boundary.
The configuration and underlying runtime matter.
9. Containers With Restricted Privileges¶
A sandbox container should generally avoid unnecessary privileges.
For example:
Container
├── Non-root user
├── Limited capabilities
├── Read-only filesystem
├── Restricted network
├── Limited CPU
└── Limited memory
Avoid giving agent workloads:
unless there is a specific, justified requirement.
10. Virtual Machines¶
A VM provides stronger isolation through virtualization.
VM isolation can be useful for:
- Untrusted code
- Strong tenant isolation
- High-risk workloads
- Security-sensitive execution
The trade-off is generally higher resource overhead and startup cost compared with lightweight process isolation.
11. MicroVMs¶
MicroVMs aim to provide stronger isolation with lower overhead than traditional VMs.
Conceptually:
They can be useful for workloads requiring:
MicroVM-based architectures are particularly interesting for large-scale agent code execution.
12. Ephemeral Sandboxes¶
An ephemeral sandbox exists only for a specific task.
Example:
User Request
↓
Create Sandbox
↓
Install Temporary Dependencies
↓
Execute Code
↓
Generate Result
↓
Destroy Sandbox
This reduces persistent state and limits the lifetime of potentially compromised environments.
13. Why Ephemeral Execution Matters¶
A compromised environment becomes less useful when it disappears after execution.
Without ephemeral execution:
With ephemeral execution:
This reduces cross-task contamination.
14. Workspace Isolation¶
Agents may need temporary files.
A sandbox can provide:
with controlled access.
Example:
Permissions can be:
The agent should not automatically access:
15. Read-Only Filesystems¶
If the task does not require system-level writes:
can reduce attack surface.
For example:
Container
├── Root FS → Read Only
├── /tmp → Temporary Writable
└── /workspace → Controlled Writable
This limits persistent modifications.
16. Temporary Storage¶
Agent tasks often require temporary files.
A secure design can provide:
For example:
with the sandbox destroying temporary data when execution ends.
17. Network Isolation¶
Network access is one of the most important sandbox controls.
An unrestricted agent could potentially:
Access Internal APIs
Scan Networks
Download Malware
Upload Data
Call Unauthorized Services
Exfiltrate Sensitive Information
Therefore:
should be explicit.
18. Network Deny-by-Default¶
A secure starting point is:
and then explicitly allow required destinations.
Example:
Allowed:
api.example.com
storage.example.com
Denied:
Internal Admin Network
Database Network
Unknown Internet Destinations
This reduces unexpected network access.
19. Egress Control¶
Egress controls restrict where sandbox workloads can send data.
Egress control is particularly important for preventing data exfiltration.
20. Ingress Control¶
Ingress controls determine what can reach the sandbox.
Only approved input channels should be exposed.
For example:
rather than:
21. DNS Restrictions¶
Network isolation should also consider DNS.
An agent may attempt:
Therefore DNS access can be restricted through:
This is an important defense-in-depth measure.
22. Cloud Metadata Protection¶
Cloud environments may expose metadata endpoints that can provide credentials or instance information.
A sandbox should not have unrestricted access to:
unless explicitly required.
The architecture should ensure:
or tightly control access through workload identity and network policy.
23. Credential Isolation¶
Sandboxing should work together with secrets management.
Avoid:
Prefer:
Secrets should not be exposed simply because code is running inside the sandbox.
24. Environment Variable Filtering¶
A sandbox should carefully control which environment variables are exposed.
Avoid passing:
Prefer:
and only explicitly required credentials or configuration.
Environment filtering reduces accidental credential exposure.
25. CPU Limits¶
An agent-generated workload may accidentally or intentionally consume excessive CPU.
Example:
Without limits:
A sandbox should enforce CPU limits:
26. Memory Limits¶
Memory exhaustion can similarly affect infrastructure.
The sandbox should enforce:
For example:
If the workload exceeds the limit:
27. Execution Timeouts¶
Every agent execution should have a defined maximum runtime where appropriate.
For example:
A timeout protects against:
28. Process Limits¶
A malicious or poorly generated program may create many processes.
Sandbox policies can restrict:
29. System Call Restrictions¶
Low-level sandboxing may restrict operating-system system calls.
Conceptually:
Only required operations should be permitted.
This can reduce the attack surface available to untrusted code.
30. Capability Restrictions¶
Operating systems and container runtimes may provide capabilities that grant additional privileges.
A sandbox should drop unnecessary capabilities.
Conceptually:
The objective is:
31. Privileged Containers¶
Privileged containers substantially weaken isolation.
Avoid:
unless there is a carefully reviewed and justified requirement.
For general agent code execution:
is a much safer starting point.
32. Dependency Isolation¶
Agent-generated code may require packages.
Example:
Installing dependencies directly onto the host is unsafe.
Prefer:
This prevents agent-generated dependencies from contaminating the host environment.
33. Package Installation Policy¶
Package installation can introduce risks.
Potential problems:
A production sandbox may therefore use:
Approved Package Registry
Package Allowlist
Dependency Scanning
Network Restrictions
Version Pinning
34. Code Execution Sandboxing¶
A code-execution agent should follow:
User Request
↓
Agent
↓
Generate Code
↓
Security Validation
↓
Sandbox
↓
Execute
↓
Collect Output
↓
Destroy
The generated code should never execute directly on the production host.
35. Code Validation Before Execution¶
A validation layer can inspect generated code before execution.
Possible checks include:
Dangerous Imports
Shell Commands
File Access
Network Access
Credential Access
Process Creation
Privilege Escalation
However:
Static code analysis should complement sandboxing, not replace it.
Generated code can behave unexpectedly at runtime.
36. Sandbox as the Primary Boundary¶
The security model should therefore be:
rather than:
Natural-language restrictions alone are not a reliable security boundary.
37. Browser Agent Sandboxing¶
Browser agents may interact with untrusted websites.
The browser environment should be isolated from:
A dedicated browser sandbox can provide:
38. File Access Controls¶
If an agent needs file access:
Do not provide unrestricted:
filesystem access.
Instead:
Path traversal should also be prevented.
39. Path Traversal Protection¶
An agent may generate:
or similar paths.
The file-access layer should validate:
This control should exist outside the LLM.
40. Database Isolation¶
If code execution needs database access, avoid giving direct production database credentials.
Prefer:
If direct access is unavoidable:
and ideally:
41. Production Environment Isolation¶
Agent-generated code should not run inside the same environment as critical application services.
Avoid:
Prefer:
This prevents agent execution failures from directly affecting the core application.
42. Multi-Tenant Sandboxing¶
In multi-tenant environments:
Avoid sharing writable state between tenants.
Each sandbox should have isolated:
43. Cross-Tenant Sandbox Leakage¶
A dangerous architecture is:
Instead:
and:
Tenant isolation should be enforced by infrastructure.
44. Sandbox Lifecycle¶
A production sandbox should have an explicit lifecycle.
Create
↓
Initialize
↓
Inject Approved Inputs
↓
Execute
↓
Collect Output
↓
Sanitize
↓
Audit
↓
Destroy
The lifecycle should not leave uncontrolled resources behind.
45. Sandbox Cleanup¶
Cleanup should include:
Temporary Files
Processes
Network Connections
Memory
Credentials
Logs
Mounted Volumes
Temporary Tokens
The goal is:
46. Snapshot and Reuse¶
Reusable sandbox images can improve performance.
However, reusable environments should not contain:
Immutable base images are generally preferable.
47. Immutable Sandbox Images¶
A strong model is:
The base image contains:
while task-specific data remains ephemeral.
48. Sandbox Resource Quotas¶
Enterprise systems should enforce quotas.
Example:
CPU:
2 cores
Memory:
1 GB
Runtime:
60 seconds
Storage:
500 MB
Processes:
20
Network:
Allowlisted destinations only
The values should be determined according to the workload.
49. Sandbox Admission Policy¶
Before starting a sandbox:
Task
↓
Risk Classification
↓
Required Capabilities
↓
Resource Requirements
↓
Sandbox Policy
↓
Create / Reject
For example:
while:
50. Risk-Based Sandboxing¶
Not every task requires the same isolation.
LOW RISK
Read-only API call
↓
Standard Tool Boundary
MEDIUM RISK
File Processing
↓
Container Sandbox
HIGH RISK
Untrusted Code + Network
↓
Strong Isolation / MicroVM
This provides a balance between:
51. Sandbox Policy¶
A sandbox policy can describe:
{
"filesystem": {
"read": ["/input"],
"write": ["/workspace", "/output"]
},
"network": {
"mode": "allowlist"
},
"resources": {
"cpu": 2,
"memory_mb": 1024,
"timeout_seconds": 60
}
}
The exact policy format depends on the execution platform.
The important concept is that execution constraints are explicit and machine-enforced.
52. Sandbox and Authorization¶
Sandboxing does not replace authorization.
They solve different problems.
Authorization¶
Sandboxing¶
Together:
53. Sandbox and Secrets Management¶
Secrets management answers:
Sandboxing answers:
Together:
A sandbox should not receive credentials that the task does not require.
54. Sandbox and Data Privacy¶
Sandboxing also supports privacy.
Ephemeral environments can reduce persistent copies of sensitive data.
However, sandboxing alone does not guarantee privacy.
Privacy controls must still address:
55. Sandbox and Prompt Injection¶
Prompt injection may attempt to cause an agent to execute dangerous actions.
For example:
If the command executes inside a properly restricted sandbox:
the potential impact is reduced.
Therefore:
Sandboxing is an important containment layer against agent-induced actions resulting from prompt injection.
It does not replace input validation, authorization, or other security controls.
56. Sandbox and Tool Poisoning¶
A malicious or compromised tool may attempt to perform unsafe operations.
The sandbox provides an additional containment boundary.
The tool should still be:
Sandboxing is defense in depth.
57. Sandbox Observability¶
Sandbox execution should produce operational telemetry.
Useful metrics include:
Sandbox Creation Count
Sandbox Failure Rate
Execution Duration
CPU Usage
Memory Usage
Network Requests
Filesystem Operations
Timeouts
Terminations
Resource Limit Violations
Sensitive payloads should still be redacted.
58. Sandbox Audit Events¶
An audit record may contain:
{
"task_id": "task-123",
"tenant": "tenant-a",
"sandbox_id": "sandbox-456",
"runtime": "python",
"duration_ms": 3200,
"exit_code": 0,
"network_access": "restricted",
"status": "completed"
}
Avoid recording:
unless explicitly required and appropriately protected.
59. Sandbox Failure Handling¶
Possible failures include:
Timeout
Memory Limit
CPU Limit
Process Limit
Network Denied
Permission Denied
Runtime Crash
Dependency Failure
Sandbox Startup Failure
The architecture should distinguish:
from:
For example:
Memory Limit Exceeded
↓
Terminate Sandbox
↓
Record Security / Resource Event
↓
Return Controlled Failure
60. Sandbox Termination¶
Termination should be deterministic.
Timeout
↓
Terminate Process
↓
Terminate Child Processes
↓
Close Connections
↓
Destroy Sandbox
↓
Cleanup Workspace
A timeout should not leave child processes running in the background.
61. Sandbox Escape¶
A sandbox escape occurs when code breaks out of its intended isolation boundary.
Conceptually:
Sandbox escape is a serious security event.
Defenses include:
Strong Isolation
Minimal Privileges
Patched Runtime
Restricted System Calls
Network Isolation
Non-Root Execution
Ephemeral Environments
Security Monitoring
High-risk workloads should use stronger isolation boundaries where appropriate.
62. Defense in Depth¶
No single sandbox control should be considered sufficient.
A strong architecture combines:
Authentication
↓
Authorization
↓
Input Validation
↓
Tool Policy
↓
Sandbox
↓
Network Isolation
↓
Resource Limits
↓
Credential Isolation
↓
Monitoring
If one control fails, additional controls remain.
63. Sandbox Security Layers¶
A useful model is:
Agent
│
▼
Policy / AuthZ
│
▼
Execution Sandbox
│
┌───────────┼───────────┐
↓ ↓ ↓
Filesystem Network Resources
│ │ │
└───────────┼───────────┘
↓
External APIs
Each layer should have an explicit policy.
64. Sandbox Architecture for Code Agents¶
A production code agent might use:
User
│
▼
AI Agent
│
▼
Code Proposal
│
▼
Code Validation
│
▼
Sandbox Scheduler
│
▼
┌─────────────────┐
│ Ephemeral │
│ Sandbox │
│ │
│ Runtime │
│ Workspace │
│ Network Policy │
│ Resource Limits │
└────────┬────────┘
│
▼
Execute Code
│
▼
Collect Output
│
▼
Sanitize
│
▼
Agent
65. Sandbox Architecture for Enterprise Tools¶
Not every tool requires code execution.
For API-based tools:
For high-risk tools:
The architecture should be risk-based.
66. Sandbox Architecture for Browser Agents¶
A browser-based agent can use:
Agent
│
▼
Browser Controller
│
▼
Browser Sandbox
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Browser Storage Network
Process Profile Policy
│ │ │
└─────────────┼─────────────┘
↓
Target Website
The browser session should ideally be ephemeral for sensitive workloads.
67. Sandbox Architecture for Data Agents¶
For data analysis:
The sandbox should not automatically receive:
68. Sandbox and Production Databases¶
Avoid:
Prefer:
If code execution is necessary:
This significantly reduces blast radius.
69. Sandbox and Cloud APIs¶
Cloud APIs can have broad permissions.
Avoid:
Prefer:
For example:
rather than:
70. Sandbox Lifecycle Management¶
A sandbox platform should manage:
Conceptually:
This becomes an infrastructure capability in larger agent platforms.
71. Sandbox Pools¶
For latency-sensitive systems, sandbox pools can reduce startup overhead.
A task receives an isolated environment:
However, reset must be strong enough to prevent data leakage between tasks.
For high-security workloads:
may be preferable to:
72. Warm vs Ephemeral Sandboxes¶
Warm Sandbox¶
Ephemeral Sandbox¶
The appropriate model depends on:
73. Sandbox Policy by Risk¶
An enterprise platform can define standard profiles.
Profile A — Low Risk¶
Profile B — Medium Risk¶
Profile C — High Risk¶
Strong VM / MicroVM Isolation
Restricted Network
Ephemeral Environment
Scoped Credentials
Strict Resource Controls
Full Audit
This creates standardized execution policies.
74. Sandbox Security Checklist¶
Before enabling agent code or tool execution, verify:
Isolation¶
- [ ] Agent execution is isolated from the host
- [ ] Containers are unprivileged
- [ ] High-risk workloads use stronger isolation
- [ ] Tenant isolation is enforced
Filesystem¶
- [ ] Root filesystem is read-only where possible
- [ ] Workspace is explicitly scoped
- [ ] Path traversal is prevented
- [ ] Temporary files are cleaned up
Network¶
- [ ] Network access is restricted
- [ ] Egress is controlled
- [ ] Internal networks are protected
- [ ] Metadata endpoints are restricted
- [ ] DNS access is controlled where required
Resources¶
- [ ] CPU limits exist
- [ ] Memory limits exist
- [ ] Execution timeout exists
- [ ] Process limits exist
- [ ] Storage limits exist
Credentials¶
- [ ] Secrets are not automatically inherited
- [ ] Environment variables are filtered
- [ ] Credentials are scoped
- [ ] Workload identity is used where appropriate
Runtime¶
- [ ] Dependencies are isolated
- [ ] Packages are controlled
- [ ] Runtime versions are managed
- [ ] Sandbox images are patched
Lifecycle¶
- [ ] Sandboxes are ephemeral where appropriate
- [ ] Cleanup is deterministic
- [ ] Child processes are terminated
- [ ] Temporary state is removed
Monitoring¶
- [ ] Sandbox events are logged
- [ ] Resource violations are monitored
- [ ] Network activity is monitored where required
- [ ] Security events are auditable
75. Common Sandboxing Mistakes¶
Mistake 1 — Running Agent Code on the Host¶
Better¶
Mistake 2 — Giving the Sandbox Full Network Access¶
Better¶
Mistake 3 — Passing All Credentials¶
Better¶
Mistake 4 — Reusing State Between Tenants¶
Better¶
Mistake 5 — Treating Containers as an Absolute Security Boundary¶
Better¶
Mistake 6 — Relying on Prompts for Security¶
This is not a security boundary.
Better¶
Mistake 7 — Failing to Clean Up¶
Better¶
76. Key Engineering Principles¶
1. Sandbox Untrusted Execution¶
Never assume generated code is safe.
2. Separate Decision From Execution¶
The LLM proposes actions; infrastructure enforces execution boundaries.
3. Use Least Privilege¶
Limit files, network, credentials, and resources.
4. Prefer Ephemeral Environments¶
Destroy task-specific environments when practical.
5. Deny by Default¶
Especially for network, filesystem, and privileged capabilities.
6. Apply Defense in Depth¶
Combine authorization, validation, sandboxing, network controls, and monitoring.
7. Isolate Tenants¶
Never rely on the model to maintain tenant boundaries.
8. Protect Credentials¶
Sandboxing and secrets management must work together.
9. Limit Resources¶
Prevent infinite loops and resource exhaustion.
10. Treat the Sandbox as a Security Boundary¶
The sandbox should reduce the impact of incorrect or malicious agent behavior.
77. Enterprise Agent Sandboxing Architecture¶
The complete model can be summarized as:
User
│
▼
AI Agent
│
▼
Proposed Action
│
▼
┌────────────────────┐
│ Authorization │
└─────────┬──────────┘
↓
┌────────────────────┐
│ Policy Validation │
└─────────┬──────────┘
↓
┌────────────────────┐
│ Sandbox Scheduler │
└─────────┬──────────┘
↓
┌────────────────────────┐
│ Ephemeral Sandbox │
│ │
│ Filesystem │
│ Network │
│ CPU / Memory │
│ Processes │
│ Dependencies │
│ Credentials │
└───────────┬────────────┘
↓
Execute
↓
Collect Result
↓
Sanitize
↓
Agent
Cross-cutting controls:
78. Part VI Security Boundary¶
Sandboxing fits naturally within the security architecture of Part VI:
Authentication
↓
Authorization
↓
Secrets Management
↓
Data Privacy
↓
Sandboxing
↓
Controlled Tool Execution
↓
Observability
↓
Evaluation
Each layer addresses a different risk.
Authorization
→ What can the agent do?
Secrets Management
→ Which credentials can it use?
Data Privacy
→ Which data can it process?
Sandboxing
→ What can its execution environment affect?
Observability
→ What happened?
Evaluation
→ Was the behavior acceptable?
79. Part VI → Part VII Boundary¶
Sandboxing belongs to Part VI — AI Agents because individual agents need controlled execution boundaries before they can safely participate in larger autonomous systems.
Part VII can extend these concepts to autonomous and multi-agent environments:
Part VII — Agentic AI & Multi-Agent Systems
Agent A
↓
Agent B
↓
Delegated Capability
↓
Sandbox
↓
Tool / Agent Execution
Topics such as:
- Multi-agent sandbox orchestration
- Cross-agent execution isolation
- Autonomous workload isolation
- Agent-to-agent trust boundaries
- Sandboxed agent swarms
belong in the Agentic AI & Multi-Agent Systems module rather than being duplicated here.
📌 Key Takeaways¶
- AI Agents may execute code, access files, invoke APIs, and interact with external systems.
- Sandboxing limits the impact of incorrect, malicious, or unintended agent actions.
- The LLM should never be treated as the final security boundary.
- Agent decisions should be separated from actual execution.
- Code execution should occur in isolated environments rather than directly on production hosts.
- Containers, microVMs, and VMs provide different levels of isolation and should be selected according to the threat model.
- Ephemeral sandboxes reduce persistent state and cross-task contamination.
- Filesystem access should be explicitly scoped.
- Network access should generally be deny-by-default and controlled through allowlists or appropriate network policies.
- Cloud metadata endpoints and internal networks require particular attention.
- CPU, memory, storage, process, and execution-time limits reduce resource-abuse risks.
- Credentials should never be automatically inherited by sandbox workloads.
- Sandbox security should work together with authorization, secrets management, and data privacy.
- Generated code should be validated where useful, but validation should complement rather than replace sandboxing.
- Multi-tenant environments require isolated workspaces, credentials, networks, and execution environments.
- Sandbox lifecycle management should include creation, execution, monitoring, cleanup, and destruction.
- Strong isolation should be used for high-risk or untrusted workloads.
- Prompt instructions such as "do not access the filesystem" are not security controls; machine-enforced boundaries are required.
- Sandboxing is a defense-in-depth mechanism for reducing agent execution blast radius.
- The goal is controlled agent autonomy inside explicitly defined execution boundaries.
🔗 Related Topics¶
Previous¶
Next¶
Related¶
- 04. Agent Security & Guardrails
- 05. Agent Authorization
- 06. Secrets Management
- Agent Architecture
- Tool Calling & Function Calling
- Agent Evaluation
- Agent Observability
- Agent Deployment
Enterprise AI Engineering Handbook
Building Production-Grade Enterprise AI Systems — One Chapter at a Time.