WebAssembly Sandboxes for AI Agent Tool Execution

WebAssembly sandboxes address a specific security problem in AI agents, namely what untrusted code can do when a tool call executes. Their strongest fit is discrete, pre-compiled tools whose permissions can be declared in advance. For that workload, deny-by-default capabilities and sub-millisecond startup offer a precise execution boundary, but production systems still need separate authorization, state management, and governance.

Why tool execution is the riskiest step in an AI agent's workflow

A malicious MCP tool can appear legitimate yet inherit the agent process’s filesystem access, environment variables, and network permissions when invoked. The attacker need not defeat authentication to exploit that authority. In the confused deputy pattern, the agent already has the access the attacker wants and can be manipulated into using it. Identity checks alone cannot distinguish an authorized role from a misuse of that role.

The structural cause is ambient authority. Traditional processes inherit permissions from their execution environment, whether or not a particular operation needs them. For an agent that runs shell commands, calls APIs, or changes files, this turns a mistaken tool choice into a potentially consequential action. The OAP paper identifies the enforcement gap here, because training-time alignment and retrospective evaluation do not provide deterministic policy enforcement at the instant of execution. Tool execution therefore needs a boundary that does not depend on the model’s judgment.

What WebAssembly's capability model actually does at the tool call boundary

A Wasm component begins with no resource permissions. It executes within its own sandboxed linear memory, while access to external resources must pass through interfaces explicitly provided by the host. WASI capability grants supply that access rather than inheriting it from the surrounding process. This reverses the permission-narrowing approach of a conventional container deployment.

The Component Model extends that boundary to composition. Components communicate through declared, typed imports and exports, without an ambient filesystem, ambient network, or shared global state. A tool compiled as a component declares the interfaces it needs, and policy sets which resources those interfaces may reach, such as api.stripe.com. Before execution, the host evaluates the requested capabilities and wires only approved access. The tool runs within those grants and is then torn down or pooled for reuse.

Startup overhead is sub-millisecond, which suits loops that invoke many small tools in rapid succession. Language support takes more than one form. Rust, Go, C, and C++ tools can compile directly to wasm32-wasi, while Python and JavaScript can run through interpreters compiled to Wasm. Components can also be cryptographically signed with Notation or Cosign, establishing a trust chain from registry to execution. A signature shows the code’s provenance, and capability grants set what that code may access.

How Wassette applies this model to MCP tool execution in practice

Microsoft’s Wassette, released by the Azure Core Upstream team in August 2025, connects Wasm components to the Model Context Protocol. It interprets a component’s typed library interfaces and exposes them as MCP tools. Built on Wasmtime, it combines that bridge with fine-grained, deny-by-default permissions. Distribution is deliberately simple. Wassette is written in Rust and installs as a standalone binary with zero runtime dependencies, so adopting it does not require auxiliary infrastructure.

Its time-component example makes the capability lifecycle visible. The subsequent tool call executes with only the access granted through the permission system. Agents can fetch components as needed, moving the mechanics of finding and securely installing a missing tool into the runtime.

The grammar-plugin example shows why this is more than packaging. A plugin granted network access for its declared purpose cannot read and exfiltrate SSH keys if no capability for reading those files was supplied. The sandbox enforces separate network and filesystem permissions, without requiring the developer to write firewall rules for the missing file access.

Where Wasm fits in the three-layer sandboxing problem for agents

An agent system has three distinct places for isolation. The outermost surrounds the harness, governing directories, network access, and commands that may run without approval. Removing approval prompts in “YOLO mode” leaves the system dependent on whatever outer boundary remains. A harness built as a Wasm component can instead use declared imports for model calls and tool calls, with no ambient network access of its own. This is architecturally clean but less common today.

A second boundary surrounds code the agent produces, including scripts and MCP servers. Restricting the harness while giving generated code full host authority merely relocates the vulnerability. Wasm can run code that fits its execution model, but arbitrary generated programs do not become compatible components on their own. Compilation and interpreter support still constrain that route.

The third boundary surrounds the tools the agent calls. This is Wasm’s most natural position in the stack. Discrete, pre-compiled functions already have the declared interfaces that the Component Model expects, and deploy-time grants can be enforced on every invocation. That scope is important when evaluating adoption. A Wasm tool layer can tightly limit what each function can do without claiming to isolate every generated script or the entire agent harness.

The hard limits of Wasm for agent workloads and where other substrates fill the gap

Arbitrary Linux binaries cannot run in Wasm without recompilation to wasm32-wasi, and automating that conversion for general-purpose agent output is impractical. Wasm-hosted Python and JavaScript interpreters do not remove every compatibility constraint. Some languages and libraries lack target support, while GPU access through wasi:webgpu remains an emerging proposal with maturing runtime support. Inference-heavy tools therefore cannot yet rely on running inside Wasm across most runtimes.

Firecracker microVMs make their strongest case at that compatibility boundary. They have hardware-enforced isolation with a dedicated kernel and boot in under 125ms, so they suit untrusted code that cannot be recompiled. Kata Containers has kernel-level isolation through a container-compatible interface and is built for regulated and zero-trust environments. Its startup is approximately 150–300ms, depending on VMM and configuration. The tradeoff is not simply speed against security, but whether the workload needs a kernel boundary and a Linux-compatible execution environment.

Other substrates occupy useful positions between those needs. gVisor intercepts syscalls in user space with millisecond-level startup, fitting high-volume multi-tenant SaaS and CI/CD workloads where code is less adversarial. V8 isolates, used in Cloudflare Workers and Deno Deploy, start in microseconds by providing runtime-level isolation. Their language surface is constrained to JavaScript, TypeScript, and WebAssembly. For frequent, small, pre-compiled tools, Wasm avoids the recurring microVM cold-start cost, while arbitrary scripts favor a microVM or gVisor.

Why sandboxing a tool call is not the same as authorizing it — and why both are needed

A tool can stay inside its sandbox and still take an action it is not authorized to take. If a granted interface allows fund transfers, isolation alone does not decide whether a given transfer should go ahead. Containment limits which resources code can use as it runs. Authorization decides whether an action is allowed before it runs. The distinction becomes especially sharp when an attacker persuades an authenticated agent to misuse legitimate access.

The OAP paper tests this distinction in an adversarial setting. It reports that social engineering succeeded at a high rate under a permissive policy, while a restrictive OAP policy reduced success to zero across a comparable population of attackers. That result supports policy enforcement at the call boundary within the tested setting. OAP intercepts calls synchronously, evaluates them against declarative policy, and produces a cryptographically signed audit record. Its measured median enforcement time is 53ms.

Model-based screening examines proposed behavior, pre-action authorization applies policy, and a Wasm sandbox or microVM constrains execution. The policy layer can set rules for spending limits, quality gates, operational contracts, and compliance controls as well as security restrictions. A fast sandbox does not make that layer redundant. And permission to take an action does not justify giving the code that carries it out unrestricted host access.

What stateful, long-running agents require from the sandbox layer beneath tool execution

Wasm’s execute-and-tear-down lifecycle suits short-lived calls, but work that persists needs more. What preserves the workspace when one call ends? The “Chatbot to Digital Colleague” paper frames sustained autonomous work through the “Workspace + Skill” paradigm, combining persistent state, reusable procedures, task closure, and experience reuse. In that model, the workspace is part of the execution substrate rather than a convenience added to an otherwise stateless loop.

Agents exploring solution branches need to attempt changes, fail, and recover without restarting from scratch. Millisecond-level rollback addresses that need differently from teardown and cold restart. Because consecutive checkpoints often differ only incrementally, storing deltas avoids repeatedly duplicating unchanged state. Wasm’s per-call isolation does not natively supply that persistence and checkpoint infrastructure. The surrounding runtime must keep it in place and manage resources from one step to the next.

Recovery also creates a separate authorization question. Safe to Resume? argues that faithful restoration can combine states, assumptions, and external effects that never coexisted in a valid history. A restored checkpoint may therefore encode a trajectory that was never authorized. Rollback is useful, but not sufficient for secure recovery. Persistent workflows need both recoverable state and scrutiny of whether resuming that state remains legitimate.

Enterprise requirements that apply to Wasm-based tool execution in production

Enterprise adoption depends on what the assurance covers as well as how strong the isolation is. SOC 2 Type II is a baseline in most enterprise sales conversations, but teams need to check whether the certification covers the sandbox product itself. Cloudflare holds SOC 2 Type II and ISO 27001 organization-wide, while its public SOC 2 FAQ does not name the Sandbox SDK in scope. That omission does not establish a product’s certification status.

Tenant boundaries extend beyond the component’s memory. A tool invoked by Tenant A must not reach Tenant B’s context windows, telemetry logs, or scratchpads, even when prompt injection compromises the orchestrating agent. Wasm limits leakage through ambient memory and state at the execution layer. Logging, telemetry, and orchestration must enforce equivalent separation. Otherwise, isolation below the agent leaves shared infrastructure above it exposed.

NVIDIA NemoClaw, announced in March 2026 at GTC, illustrates an explicit enforcement layer around an agent framework. It wraps OpenClaw with OpenShell runtime sandboxing, a privacy router, network guardrails, and an out-of-process policy engine that compromised agents cannot override. The Microsoft Agent Governance Toolkit, released in April 2026, also puts open-source runtime security above the execution substrate. Regulatory obligations add another deployment constraint. HIPAA requires a Business Associate Agreement with vendors that handle PHI for a covered entity, including infrastructure providers, and GDPR data residency requirements affect where the compute that runs tools is set up.

How to decide whether Wasm is the right isolation layer for your agent's tool calls

The first decision is about the code being executed. Teams should favor Wasm when tools are discrete, pre-compiled functions with declared interfaces, especially when high invocation frequency makes startup latency costly. An auditable, polyglot component supply chain strengthens that fit because signed artifacts and explicit grants make provenance and resource access separately inspectable. The threat model should also guide the choice. When ambient authority and lateral movement are central risks, deny-by-default capabilities address the mechanism that enables them.

A different workload calls for a different boundary. Teams should favor Firecracker or Kata when agents execute arbitrary Linux code, require unsupported system libraries or GPU access, or face a requirement for kernel-level isolation. gVisor is another option where script compatibility and high startup volume outweigh the need for a dedicated kernel. These choices should follow the tool workload.

Production readiness then depends on what surrounds that boundary. Whether the tool contract can be made explicit enough that every resource the code reaches is a deliberate grant is decisive.