Hardware Sandboxing for Agents: Elie Bursztein and Capsem at [un]prompted II

The usual objection to a hardware sandbox for agents is that it is slow and gets in the way. Elie Bursztein's [un]prompted II talk says it does not have to be. [un]prompted II, also typed "unprompted II", is the AI security practitioner conference in San Francisco, 27-29 October 2026. Our conference guide covers every session.

The official agenda, as published on 2026-10-12, lists Elie Bursztein as Distinguished Research Scientist, Google DeepMind. His talk, "Taming AI Agents with Capsem: Hardware Sandboxing That Doesn't Kill Productivity", is on Day 1, Stage 1, at 10:00. This is a preview written from the published abstract, before the talk. We are independent coverage, not the organiser, and we follow remotely. The agenda can change.

What the talk says it will show at [un]prompted II

The abstract describes Capsem as an open-source Rust hypervisor and VM system for running agents in a hardened environment. It lists fast-booting VMs, air-gapped isolation, network observability, and support for Sigma and OpenTelemetry. The argument is that security need not cost speed or usability. The abstract gives no boot times or overhead figures, so we quote none.

Why this is the hard part

An agent runs code and calls tools, and some of that is untrusted. A process-level sandbox shares a kernel with the host, so a kernel bug can end the isolation. A virtual machine puts a hypervisor between them, which is a smaller and better studied surface. That is our analysis, and it is why we put VMs high in our isolation architecture for agent tool calls. The cost has always been start-up time and friction for the person using the agent. Capsem's claim is that fast-booting VMs remove most of that cost.

The honest pairing is with Daniel Cuthbert's talk, "Your Sandbox Degrades Gracefully, What's the Wurst That Could Happen?", on Day 1, Stage 1, at 13:55. Cuthbert describes building an agent-specific sandbox for RAPTOR, an agentic bug-finding harness that runs untrusted code. His abstract is candid about the security issues the team introduced themselves, and about why agent sandboxing is harder than it looks. One talk reports a boundary designed in hardware. The other reports what went wrong while building one. Read together, they test each other. You will find both people in our speakers list.

The word to watch in the abstract is productivity. Security teams often win the sandbox argument on paper and lose it in practice, because developers turn the sandbox off when it slows them. A boundary that people disable gives no protection, which is the same lesson as permission fatigue. If Capsem is fast enough that nobody has a reason to bypass it, that is a real result. The abstract claims it, and we will look for the numbers behind the claim. Observability is the other half: a VM that you cannot see into is a better wall, but it does not tell you what the agent tried to do against it.

What we will be watching for

• Measured boot time and per-call overhead, with the hardware named.
• What the agent can still reach when air-gapped, and how it gets files and packages in.
• Which network events Capsem exposes, and whether the Sigma support ships with rules.
• Whether the talk names escape paths it does not stop, such as host-guest channels.
• Whether the open-source release includes the observability pipeline or only the hypervisor.

If this holds, what changes on Monday

Our inferences, conditional on the talk. Decide which of your agent workloads run untrusted code and move those into a VM boundary first. Send network events from the agent environment to the same place as your other telemetry. Our piece on runtime monitoring for AI agents covers what to collect. State what each sandbox does not stop. A hypervisor does not stop a tool that is allowed to send your data out.

Three questions for Elie Bursztein

These are the questions we would ask. The page stands without any reply.

1. Where does hardware isolation stop being worth the latency, and which agent workloads should not use it?
2. What does an air-gapped agent give up, and how does it receive the code and data it needs?
3. What do Sigma rules on agent telemetry actually catch, and what do they miss?