Agent Environment Isolation
Added May 2026
Run AI agents in isolated environments. Limit system, network, and data access to what their tasks require.
Objective
Contain the impact of agent errors, compromised behavior, or malicious injection (hidden instructions planted in content agents read) by keeping agents from affecting systems outside their defined boundary.
Maturity Levels
Initial
Agents run with the same access as the hosting application with no isolation.
Developing
Some isolation is in place (e.g. API key scoping, which limits what the agent's software access keys can do) but execution environment is not formally defined or audited.
Defined
Agents run in documented sandboxed environments with defined network and file system access constraints.
Managed
Isolation configurations are reviewed after every agent deployment; escape attempts are detected and alerted.
Optimizing
Isolation is enforced at the infrastructure level (containers, VMs) with automated compliance verification.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Documented configuration for each agent deployment's sandbox (the sealed-off space the agent runs in), specifying network access rules, file access limits, and computing resource limits
- —Post-deployment environment review records signed by responsible team confirming isolation configuration matches specification
- —Escape attempt detection logs and alert response records for any attempted boundary violations in production (live systems)
- —Network access policy documentation for agent execution environments, reviewed at each deployment
- —Penetration test (authorized simulated attack) or red team results specifically targeting agent environment boundaries, with records of fixes for findings
Implementation Notes
Key steps
- Use containers or virtual machines (VMs), which give agents their own sealed computing space, for agents with access to sensitive systems; lighter process-level isolation is insufficient for high-risk agents.
- Apply network egress filtering (limits on outbound connections): agents should only be able to reach the specific services and addresses required for their task.
- Treat the environments agents run in as temporary where possible: create a fresh environment for each task and delete it after completion.
- Regularly test isolation boundaries through red-team exercises (staged attacks by internal or hired testers) specifically targeting environment escape (an agent breaking out of its isolated space).
Example Implementation
Platform team deploying a code-execution agent with access to internal APIs
Environment Isolation Spec: Code Execution Agent
Execution environment: Ephemeral Docker container, destroyed after each task
Network egress allowlist (all other traffic blocked at host firewall):
- Internal API gateway: 10.0.1.50:443
- Package registry (read-only): registry.internal:443
- No public internet access
File system constraints:
- Read/write: /workspace (ephemeral, destroyed post-task)
- Read-only: /config (mounted secrets, no modification)
- No access: host file system, /etc, /proc, /sys
Resource limits: 2 vCPU, 4 GB RAM, 10-minute max execution time
Isolation verification: Automated escape test suite run before each agent version release; test attempts to write outside /workspace and reach non-allowlisted network endpoints; both must fail
Incident trigger: Any file write outside /workspace or blocked network call generates P1 alert to Security Operations