[EAAPL-AGT004] Agent Sandboxing

Category: Agentic AI Sub-category: Security Architecture Version: 2.2 Maturity: Proven Tags: sandboxing, compute-isolation, security, code-execution, network-egress, escape-detection, resource-quotas Regulatory Relevance: EU AI Act (Art. 9, 15), APRA CPS 234, ISO 27001 §A.12.6, NIST AI RMF (MANAGE 2.2), SOC 2 Type II

1. Executive Summary

The Agent Sandboxing Pattern defines the secure execution environment that isolates AI agent tool executions from the host infrastructure, other agent workloads, and each other. As AI agents gain the ability to execute code, call external APIs, read and write files, and interact with databases, the execution environment becomes a critical attack surface. An unsandboxed agent that is manipulated via prompt injection can exfiltrate data, modify production systems, or pivot to attack other services.

For CIO/CTO audiences: this pattern is the equivalent of a bank's vault door. It does not prevent an agent from being asked to do something harmful; it ensures that even if an agent is compromised or manipulated, the blast radius is contained to the task it was explicitly authorised to perform. Without sandboxing, a single successful prompt injection against your most capable agent could mean unrestricted access to your entire enterprise infrastructure. With sandboxing, the attacker is limited to the resource quota and network scope of that single tool invocation — and every attempt is logged and detectable. This pattern is non-negotiable for production AI agents executing code or making external API calls.

2. Problem Statement

Business Problem

Organisations deploying AI agents with code execution, file system, or API-calling capabilities face an existential risk: an agent that is manipulated via prompt injection or that malfunctions can execute arbitrary actions on enterprise infrastructure. The consequential damages — data exfiltration, ransomware staging, financial fraud, or regulatory violation — can far exceed the cost of the agent use case itself.

Technical Problem

AI agents run as processes on compute infrastructure. Without isolation, they share the OS kernel, network namespace, filesystem, and memory address space with other processes. A malicious tool, a compromised package dependency, or a successful prompt injection that tricks the agent into generating malicious code has full access to everything the agent process can reach — which, in cloud environments with overly permissive IAM roles, can be the entire AWS/Azure/GCP estate.

Symptoms of Absence

• Agents execute code in-process or in shared container environments with no isolation
• Network calls from tool executions are unrestricted — any endpoint is reachable
• CPU/memory consumption by one agent task can starve other workloads
• No alerting when a tool execution attempts to access a restricted file path or network destination
• Security assessment of the agent produces an unacceptably large attack surface with no containment boundary

Cost of Inaction

• Security: A single successful sandbox escape or prompt injection gives an attacker the agent's full cloud credentials
• Compliance: APRA CPS 234 requires capability to contain and detect security incidents; absence of sandboxing is a material finding
• Operational: Runaway tool executions (infinite loops, memory leaks) can crash host infrastructure, affecting unrelated workloads
• Insurance: Cyber insurers increasingly require demonstrable code execution isolation for AI agent deployments

3. Context

When to Apply

• The agent can execute code generated by an LLM (code executor tool)
• The agent can call external APIs on behalf of users
• The agent has read/write access to file systems
• The agent handles sensitive data that must not be exfiltrated
• Multi-tenant environments where one agent's actions must not affect another tenant's data or compute

When NOT to Apply

• The agent is purely an LLM inference wrapper with no tool use (no sandbox needed for inference calls themselves)
• The agent runs in a fully air-gapped, single-tenant environment with static, pre-approved tools only (lighter controls may suffice)
• Proof-of-concept with no production data and no external network access

Prerequisites

• Container runtime or hypervisor infrastructure (Kubernetes, Docker, Firecracker, or equivalent)
• Network policy enforcement capability (Kubernetes NetworkPolicy, AWS Security Groups, iptables)
• Secrets management (no credentials in sandbox environment that are not explicitly required)
• Audit log infrastructure to receive sandbox event logs
• EAAPL-AGT003 (Tool Registry) providing sandbox_requirements per tool

Industry Applicability

4. Architecture Overview

The Agent Sandboxing Pattern defines a five-layer isolation model. Each layer addresses a different attack vector, and the layers are defence-in-depth: compromising one layer does not automatically breach the others.

Why layered isolation rather than a single control? Container security history is instructive: Docker containers that rely only on namespace isolation have been escaped via kernel vulnerabilities (CVE-2019-5736, runc breakout). gVisor adds a userspace kernel; Firecracker adds a hypervisor boundary. Each layer closes attack vectors that the layer below leaves open. For production AI agents executing untrusted LLM-generated code, layers 1–4 (namespace, kernel, hypervisor, and network) are all required.

Layer 1: Process Namespace Isolation Each tool execution spawns in an isolated Linux namespace set: PID (process cannot see host processes), mount (private filesystem), network (private network interface), IPC (no shared memory with host), and UTS (custom hostname). This is the baseline provided by container runtimes. It prevents basic information leakage (process enumeration) and limits lateral movement within the host.

Layer 2: Syscall Filtering (seccomp) A seccomp profile defines the exact set of Linux syscalls the sandbox process may invoke. For typical tool executions (HTTP API calls, file I/O, computation), the permitted syscall set is far smaller than the full Linux syscall table. Any syscall not on the allow-list causes the process to be killed with SIGKILL and triggers a security alert. This is the primary defence against kernel exploit attempts: even if an attacker can generate malicious code, the syscalls needed to exploit a kernel vulnerability are blocked.

Layer 3: Mandatory Access Control (AppArmor / SELinux) A MAC policy defines filesystem paths the sandbox process may access (read/write), network operations permitted, and capabilities (Linux capabilities) the process holds. The policy is defined by the tool type: an API caller needs network access but no filesystem write; a file processor needs specific directory access but no network. The tool registry provides the MAC profile name to the sandbox orchestrator at invocation time. Any MAC violation is logged and alerted.

Layer 4: Kernel Isolation (gVisor / Firecracker) For highest-sensitivity tool executions (LLM-generated code execution, untrusted third-party tool implementations), a virtualised kernel boundary is added. gVisor (runsc) intercepts all syscalls in a Go-based userspace kernel, providing a deep isolation boundary without full VM overhead. Firecracker provides a full KVM microVM with a lightweight kernel (50ms startup), used for the highest-risk executions. The choice between gVisor and Firecracker is a trade-off between isolation strength and startup latency.

Layer 5: Network Egress Controls By default, the sandbox has no external network access (default-deny egress). A network allow-list specifies the exact endpoints and ports the tool is permitted to call. The allow-list is derived from the tool's registration metadata in the tool registry. Any connection attempt to an unlisted endpoint is blocked at the network layer (iptables/NetworkPolicy/firewall) and logged as a security event. DNS resolution is intercepted — DNS queries for unlisted domains are blocked.

Resource Quotas The sandbox enforces hard resource quotas: CPU (in millicores), memory (in MiB), execution time (timeout in seconds), and network bandwidth. These quotas prevent a runaway tool execution from exhausting compute resources and prevent slow exfiltration via bandwidth. Quotas are defined per tool type in the tool registry and enforced by the container orchestrator (Kubernetes resource limits) and Linux cgroups.

Capability Allow-Listing Linux capabilities provide fine-grained privilege controls below the root/non-root dichotomy. Sandbox processes drop all capabilities not on the explicit allow-list (typically: none, or at most CAP_NET_BIND_SERVICE for tools that need to bind ports). Running as a non-root user inside the namespace is required; user namespace remapping is applied to prevent privilege escalation via UID manipulation.

Escape Detection A monitoring agent (eBPF probe or privileged sidecar) monitors sandbox processes for escape indicators: unusually high syscall rates, attempts to access restricted file paths (MAC violations), attempts to connect to unlisted network endpoints, process spawning outside expected patterns, and CPU/memory usage spikes. Any anomaly triggers an immediate alert and can trigger sandbox termination.

5. Architecture Diagram

6. Components

7. Data Flow

Sandbox Invocation Flow

Escape Attempt Detection Flow

Error Flow

8. Security Considerations

Defence-in-Depth Model

The five-layer model means an attacker must break multiple independently hardened controls. Historical container escape CVEs (runc, Docker, containerd) typically bypass Layer 1 only; Layers 2–4 would contain the impact in each case.

Secrets in the Sandbox

• Secrets needed by the tool (API keys, DB credentials) are injected as environment variables just-in-time by the sandbox orchestrator via the secrets vault
• Secrets are never present in the tool code, the agent prompt, or the audit log
• Secrets are revoked from the environment immediately after the sandbox exits (ephemeral dynamic secrets are preferred)
• The MAC policy prevents the sandbox process from reading the host's secrets vault mount

OWASP LLM Top 10

Container Image Hardening

• Sandbox base images are minimal (scratch or distroless); no shell, no package manager, no unnecessary utilities
• Images are built deterministically from pinned dependencies; vulnerability-scanned before deployment
• Images are signed (Cosign/Notary); admission controller validates signatures before running

9. Governance Considerations

Security Review of Isolation Profiles

• Every isolation profile (seccomp + AppArmor + network allow-list + quotas) requires security team review before being used in production
• Profile changes are treated as security-relevant configuration changes and go through change management

Governance Artefacts

10. Operational Considerations

SLOs

Monitoring

• Per-sandbox resource consumption: CPU, memory, wall-clock time, network bytes sent/received
• Security event rate per tool_id: escape indicators, network blocks, MAC violations
• Sandbox startup latency histogram per isolation level
• Alert: any Firecracker escape indicator triggers P0 incident regardless of time of day

Incident Response

11. Cost Considerations

Cost Drivers

Indicative Cost Comparison (per 1M sandboxed executions, 1s avg execution time)

12. Trade-Off Analysis

Isolation Technology Options

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

APRA CPS 234

• Sandboxing directly implements the "capability to contain" requirement — the organisation must demonstrate capability to contain security incidents affecting information assets
• Escape detection alerting implements the "ability to detect material security incidents promptly" requirement
• Isolation profiles and penetration test results are evidence for CPS 234 annual attestation

EU AI Act

• Art. 15 (Accuracy, Robustness, Cybersecurity): sandboxing with escape detection directly implements the cybersecurity requirement for high-risk AI systems
• Art. 9 (Risk Management): isolation tier selection (container/gVisor/Firecracker) is a documented risk treatment

ISO 27001

• §A.12.6.1 (Management of Technical Vulnerabilities): container image scanning + signature validation satisfies this control
• §A.12.2.1 (Controls Against Malware): seccomp + AppArmor + escape detection implements this control in the AI agent context

NIST AI RMF

• MANAGE 2.2: sandboxing is the primary technical control for managing AI agent action risk; hardened profiles per tool risk tier implement the tiered risk treatment requirement

15. Reference Implementations

AWS

Azure

GCP

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History