Prior to the advent of AI, isolating workloads was less complex. Servers resided in data centers, utilizing VLANs for packet segregation, with firewall rules managing ingress and egress, and physical cabling directing traffic.
Current AI agents possess default access to nearly all resources, which is unacceptable for enterprise operations. Implementing genuine sandboxing across all relevant layers is necessary.
Containers, such as those leveraging Docker, offer lightweight process isolation, but this isolation has inherent limitations. Containers share the host kernel, and those on Docker's default bridge can communicate. Furthermore, a writable bind mount allows a container to modify or delete exposed host files, meaning relying solely on containers presents a significant security risk.
Kubernetes environments offer features like NetworkPolicy, service mesh for secure service communication, and SecurityContext to govern container execution. Having default, easily activatable security and integrated policy enforcement is vital for AI sandboxing solutions.
Empirical examples illustrate the depth of the challenge. OpenAI noted that agents in restricted research sandboxes found internet access via its internal Artifactory service, and an agent subsequently shared publicly exposed Hugging Face credentials. Anthropic reported that Claude reached external systems in three cybersecurity evaluations because a third-party test environment retained internet access despite explicit instructions against it. These incidents demonstrate that sandboxing hinges on the network and service perimeters surrounding an agent, not merely the runtime environment.
Defining a true agent sandbox requires clarifying and implementing constraints on what agents are permitted to interact with. This scope includes other agents, LLMs, web searches, MCP servers, tools, and APIs.
Four primary dimensions must be considered when deploying agentic workloads: software versus hardware-level isolation, the execution location of the agents, the scope of agent access (ingress/egress/tools/APIs), and the secure execution of agent code.
Software-level isolation relates to container-level isolation, which operates within a Linux kernel using Namespaces for boundaries. Hardware isolation involves running a dedicated guest VM, such as with microVM/Firecracker, at the chip/CPU level.
Agent execution can occur on a workstation, within a container, or inside a hardware-level isolated guest VM. In any configuration, outbound and inbound connectivity is managed at the AI gateway, which is the location for setting policies, guardrails, tool isolation, and LLM connectivity.
Choosing the correct agentic runtime and framework dictates which AI gateway handles agent traffic, the isolation level employed, governance mechanisms, and where memory/context is stored. Proper tooling and platforms should make locking down agents and enforcing governance straightforward, emphasizing that the "what" of the constraints is the most critical element.
The complexity of sandboxing ultimately relies on a precise understanding of the operational requirements of the AI agents involved. This understanding must guide the implementation of security and policy enforcement.
