Agent Environment Isolation
Run AI agents in isolated execution environments that limit their ability to access host systems, network resources, or data beyond what their task requires.
Objective
Contain the impact of agent errors, compromised behavior, or malicious injection by ensuring agents cannot affect systems outside their defined execution 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) 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 sandbox environment configuration specifying network access rules, file system constraints, and resource limits per agent deployment
- —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
- —Network access policy documentation for agent execution environments, reviewed at each deployment
- —Penetration test or red team results specifically targeting agent environment boundaries, with remediation records for findings
Implementation Notes
Key steps
- Use containerization or VM-level isolation for agents with access to sensitive systems — process-level isolation is insufficient for high-risk agents.
- Apply network egress filtering: agents should only be able to reach the specific endpoints required for their task.
- Treat agent execution environments as ephemeral where possible: spin up fresh environments per task and destroy them after completion.
- Regularly test isolation boundaries through red-team exercises specifically targeting environment escape.
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
Control Details
- Control ID
- AGT-008
- Domain
- Agentic AI
- Typical owner
- CISO / Platform Engineering
- Implementation effort
- High effort
- Agent-relevant
- Yes