AI Agent Sandboxing: Google Researcher Unveils Capsem

At [un]prompted II, Google DeepMind's Elie Bursztein introduces Capsem, an open-source AI agent sandbox that combines hardware isolation, security enforcement and sub-two-second startup times.

Enterprises are racing to give AI agents access to code, corporate data, networks and business systems. But the more freedom those agents receive, the greater the consequences when they are manipulated, make mistakes or behave unpredictably.

The industry's response has largely been to pile on more guardrails. Elie Bursztein, distinguished research scientist at Google DeepMind, argues that security needs to move beyond trying to control every action an AI model might take.

Instead, organizations should control the environment in which the agent operates.

At [un]prompted II in San Francisco, Bursztein presented Capsem, an open-source, Rust-based hypervisor and virtual machine system designed to isolate AI agents without making them too slow or cumbersome to use.

His presentation, Taming AI Agents with Capsem: Hardware Sandboxing That Doesn't Kill Productivity, centers on a straightforward proposition: Security and productivity should not be competing requirements.

The idea is to move the security boundary away from the unpredictable behavior of the model and into a hardened execution environment that can inspect, restrict and log what the agent actually does.

Bursztein describes the concept as "Chrome for agents" — a specialized environment that makes powerful AI systems usable while keeping their actions within enforceable boundaries.

Full [un]prompted coverage:

[un]prompted II: Full Coverage

CYBR.SEC.Media's full coverage of [un]prompted II 2026: AI agent security research, expert talks, debates and analysis from San Francisco, October 27–29.

CYBR.SEC.MediaBill Brenner

Move the security boundary, not the goalposts

Traditional AI guardrails attempt to prevent unsafe behavior through prompts, model alignment, content filtering and other restrictions.

Those mechanisms remain useful, but they face a fundamental limitation: AI agents increasingly interact with tools and systems beyond the model itself.

An agent might execute code, retrieve sensitive information, communicate with external services or invoke tools through the Model Context Protocol (MCP). A successful prompt injection or unexpected model behavior can therefore have consequences far beyond generating an incorrect answer.

Capsem takes a different approach. Each agent runs inside an isolated, hardened Linux virtual machine, with the system designed around zero-trust principles and restricted privileges.

The architecture combines a Rust-based hypervisor with concurrent OCI containers running inside specialized VMs. Instead of giving agents unrestricted access to the host environment, Capsem routes their activity through security components that can inspect and enforce policies.

The result, according to Bursztein's presentation, is an execution environment built to contain the consequences of unsafe agent behavior rather than relying exclusively on preventing that behavior.

Security without killing productivity

Bursztein acknowledges a persistent obstacle to stronger security: Users will work around controls that make their jobs unnecessarily difficult.

Capsem is designed to avoid that tradeoff.

The system's co-designed architecture can boot fully configured AI agent environments in under two seconds, according to the presentation, while supporting multiple agents running concurrently.

Users can install it with a single click, select from a catalog of ready-made agent environments and interact through a desktop interface.

For developers and enterprise teams, Capsem also provides command-line tools, SDKs and MCP integration.

The software supports Mac and Linux environments.

These features are central to Bursztein's argument that effective security controls must fit into how people actually work.

If deploying a secure agent requires extensive manual configuration, complicated networking or unacceptable delays, users and development teams have strong incentives to bypass the controls.

Capsem attempts to make the secure environment the easiest environment to use.

Inspecting what agents actually do

Isolation is only part of the architecture.

Capsem includes a security engine designed to inspect and control agent activity across multiple layers, including IP, TCP, HTTP, DNS, model interactions and MCP communications.

External traffic passes through a single low-privilege egress point, where rules and plugins can inspect activity before it reaches outside systems.

Bursztein's slides describe an enforcement engine capable of processing 5,000 requests per second with sub-millisecond event processing, including reconstruction.

Those are performance figures presented by the project, rather than independently verified benchmarks.

The system supports four policy actions: allow, ask, deny and rewrite.

That gives administrators options beyond simply permitting or blocking an agent's behavior. They can require approval, modify requests or responses, and apply fine-grained restrictions based on what an agent is attempting to do.

The architecture also separates networking functions. External communications pass through the security engine, inter-VM traffic uses a sandboxed Rust virtual router, and exposed ports are handled by authenticated, low-privilege processes.

The objective is to minimize the privileges available to individual components and reduce the damage possible if one is compromised.

From credential protection to real-time detection

Capsem's security plugins extend that approach into specific enterprise risks.

A credential broker can intercept and replace credentials so agents do not directly receive the underlying secrets.

A personally identifiable information scanner examines inbound and outbound communications for sensitive information.

A sanitizer normalizes model inputs to remove unusual characters and other potentially problematic content.

The slides also identify a malware scanner for URLs and files, although that capability remains a work in progress.

For security operations teams, Capsem supports Sigma-compatible detection rules and OpenTelemetry-based reporting.

One example in the presentation demonstrates a Sigma rule that records when an agent loads a SKILL.md file — an event that could matter when monitoring the instructions and capabilities introduced into an agent's environment.

Administrators can also define custom VM images, security profiles, enforcement rules and detections.

That level of visibility matters because traditional endpoint and network controls were not designed to understand the full context of AI agent interactions.

A security team might see an HTTP request leaving a system without understanding which model generated it, what MCP tool was invoked or which agent instruction triggered the action.

Capsem's approach is to bring those interactions into a common enforcement and observability framework.

The catch: Capsem itself was built entirely with AI

One of the presentation's more revealing disclosures concerns how Capsem was developed. Bursztein states that 100% of Capsem's code was AI-generated.

The slides describe a codebase of more than 630,000 lines, supported by approximately 14,900 tests.

That makes Capsem both an AI security project and an experiment in AI-assisted software engineering.

Bursztein's development statistics reveal the difficulties involved. The presentation highlights extensive effort devoted to testing, building and releasing the software, along with a decline in successful development outcomes associated with problems in the release system.

The lesson is not that AI-generated code is inherently secure or insecure. Rather, producing a complex security product with AI requires substantial engineering infrastructure, testing and controls.

There is an important limitation here: The presentation describes Capsem's architecture and development experience, but it does not provide an independent security assessment demonstrating that the system withstands every relevant sandbox escape or agent attack.

That distinction matters particularly for software designed to establish a security boundary around untrusted execution.

The system's isolation guarantees, implementation quality and resistance to emerging attack techniques will ultimately need to be tested by the broader security community.

A different direction for agentic AI security

Bursztein's presentation arrives as cybersecurity researchers increasingly shift their attention from AI models themselves to the infrastructure surrounding them.

That includes agent permissions, tool integrations, execution environments, credentials, memory and the systems used to connect AI models to enterprise resources.

Capsem addresses that challenge by treating agents as workloads that require strong isolation, controlled access and continuous monitoring.

Its open-source approach also creates an opportunity for outside researchers to examine the implementation, identify weaknesses and contribute improvements.

Bursztein is clear that next-generation sandboxing remains an emerging field requiring additional research.

But the broader argument is difficult to ignore. Organizations cannot assume that AI agents will always follow instructions, recognize malicious content or make safe decisions. They can, however, build environments that limit what those agents can access and what happens when they fail.

For enterprises trying to deploy agentic AI without exposing their systems to unnecessary risk, that may prove more practical than another layer of model-level guardrails.

The goal is not to make AI agents incapable of mistakes, but to make those mistakes containable.

Capsem is available as an open-source project for Mac and Linux at capsem.org. Bursztein's presentation materials are available at elie.net/capsem.