When “isolated” doesn’t mean isolated: How to sandbox AI agents

An agent might find a route to the internet through an internal Artifactory service, as OpenAI reported regarding agents in restricted research sandboxes, and another case involved an agent discovering and sharing publicly exposed Hugging Face credentials.

Anthropic detailed a different failure, noting that Claude reached live systems during three cybersecurity evaluations because a third-party testing environment possessed internet access despite explicit instructions against it. These incidents demonstrate that effective sandboxing relies on the surrounding network and service boundaries, not just the runtime environment holding the agent.

When considering agent sandboxing, it is crucial to implement safeguards across every pertinent boundary for your organization. This means the implementation will vary depending on where and how you deploy it. For instance, an agent handling sensitive healthcare data might require ingress/egress restrictions to block access to public, consumer-grade LLMs, permitting interaction only with dedicated models for specific data tasks.

Conversely, a software engineer developing a new integration might have greater latitude regarding the LLMs, MCP Server tools, and agent skills available to the agents, determining whether those agents operate on a desktop or an isolated server runtime.

True agent sandboxing ultimately requires clearly defining, understanding, and enforcing what your agents are permitted to interact with. This scope encompasses other agents, LLMs, web searches, APIs, tools, and MCP servers.

Four primary areas dictate the design of your agent sandbox: the level of isolation—whether it is software or hardware-based; the location where the agents execute; what resources they can access, such as web search or tools; and the security surrounding code execution for these AI agents.

Software-level isolation relates to container-level separation, which uses Linux Namespaces within a kernel. Hardware isolation, conversely, involves running a dedicated guest VM, like a microVM/Firecracker, at the CPU level.

Regardless of whether an agent runs on a workstation, in a container, or within a hardware-level VM, proper guardrails and policy enforcement are necessary. Outbound and inbound connections to the agent are managed at an AI gateway, which is where policies and tool isolation are typically configured.

Choosing the correct agentic runtime or framework allows you to specify the AI gateway for your agent traffic, the harness used, the underlying isolation method, and where the agents store their context.