fenders.io Get early access

WASM AI sandbox for agents

A WASM sandbox for AI code, sealed in its own VM.

fenders runs each piece of agent-written code as a WebAssembly component inside its own fresh KVM virtual machine. There is no guest Linux to attack, and nothing reaches the network, files or CPU unless you granted it. When the code finishes, the VM is gone.

Get early access See the benchmarks
Fresh VM → verified result · median of 50 runs each
  1. Compute module returns Pure computation, result verified
    p95 2.66 ms
  2. PostgreSQL write + read Credentials never enter the sandbox
    p95 7.27 ms
  3. HTTPS + PostgreSQL over TLS 1.3 TLS, SCRAM auth and SQL all execute inside WASM
    p95 63.48 ms

Median of 50 fresh VMs per workload. Benchmark VM: 1 vCPU, 32 MiB, on AMD Ryzen 5 8500GE with Linux/KVM. All benchmarks

How it works

Two walls. No kernel.

WebAssembly bounds what the code can address. The virtual machine bounds the runtime itself. To get out, generated code has to break Wasmtime and the hardware boundary, and even then it lands in an empty VM with no operating system, no shell and no network.

Every socket, file and clock request leaves the VM and is checked against your policy before anything happens.

Host VMM checks every I/O exit

  • Network allowlist
  • Directory grants
  • Deadline

Dedicated VM hardware boundary, one per run

Wasmtime standard WASI runtime

  • CPU budget
  • Memory cap

Your WASM component code an agent wrote

Not in the guest

  • Linux kernel
  • initramfs
  • PID 1 / init
  • shell
  • guest TCP/IP stack
  • JIT compiler
  • firmware boot

Permissions

Nothing is ambient.

A sandbox starts with no network, no filesystem and a fixed budget. You grant each capability per launch, and the checks that matter most run outside the guest.

  • Network

    Allow exact HTTPS origins and exact host:port pairs. Everything else is refused, including a permitted name that resolves to a forbidden address.

  • Files

    Grant a read-only /app, a scratch /tmp or a persistent /data, each backed by a host directory you provision. Paths resolve beneath the grant, and .. or symlink escapes are refused.

  • Compute

    Each run gets a CPU budget, a memory cap and a wall-clock deadline. Hitting any of them stops the sandbox with a clear reason instead of hanging your agent.

  • Secrets

    Credentials arrive in runtime configuration for one launch and are never baked into the image. Rotate a database password and the same artifact keeps working.

Example sandbox policy

Network

  • ✓ https://api.example.com HTTPS only
  • ✓ 10.0.0.9:5432 PostgreSQL
  • ✕ everything else

Files

  • ✓ /app read-only
  • ✓ /tmp scratch, discarded after the run
  • ✕ host filesystem

Limits

  • ✓ CPU budget
  • ✓ memory cap
  • ✓ wall-clock deadline

What runs inside

Standard WASI. Real libraries.

The guest runs upstream Wasmtime with the standard wasi:http, wasi:sockets and wasi:filesystem interfaces. Rust std::fs, Hyper, rustls and tokio-postgres work unmodified, including TLS 1.3 with certificate checks performed inside the sandbox.

Bring code in any language that compiles to WebAssembly. The same .wasm runs the same way in every sandbox.

  • Code interpreter for agents

    Let a model write and run analysis code against data you hand it, with no path back to your infrastructure.

  • Tool and MCP calls

    Run each tool invocation in a fresh VM that can reach exactly one API and nothing else.

  • Customer plugins

    Accept WebAssembly from users and execute it next to your product without trusting it.

  • Eval and RL harnesses

    Spin up thousands of disposable, identical sandboxes to grade generated code.

Compared with

Where an escape lands.

Containers Linux microVMs WASM runtime alone fenders
What contains the code Namespaces and cgroups Hardware VM Runtime memory bounds WASM bounds inside a hardware VM
Kernel the code can reach The shared host kernel A full Linux guest The host process's kernel None in the guest
After a runtime escape Host kernel attack surface Guest Linux, then the VMM The host process An empty VM with no OS
What you can run Any Linux binary Any Linux binary WASI components WASI components

Benchmarks

Fast enough for a VM per call.

Every run starts a brand-new VM and does the whole job: no snapshots, no reused VMs, no pooled connections. Each result is timed from process launch until an independent check confirms it.

Workload in one fresh VM Median p95 Memory
Compute-only WASM module No guest Linux, libc, filesystem or JIT 2.66 ms 6.61 ms —
PostgreSQL write/read, credentials outside the sandbox SQL and credentials stay outside the VM 7.27 ms 28.35 ms 1.88 MiB
PostgreSQL over TLS 1.3, driver inside WASM Fresh TCP, TLS handshake and SCRAM auth every run 59.35 ms 68.20 ms 15.51 MiB
HTTPS GET + PostgreSQL TLS in one sandbox 18 positive and negative checks passed 63.48 ms 71.44 ms 15.61 MiB
Upstream wasi:http + wasi:sockets, DNS + HTTPS + PostgreSQL TLS Full upstream Wasmtime stack; 35 integration cases 231.02 ms 236.70 ms 25.16 MiB

50 fresh VMs per workload · AMD Ryzen 5 8500GE · Linux x86-64 with KVM · benchmark VM: 1 vCPU, 32 MiB RAM · memory is host process footprint

FAQ

Questions engineers ask first.

What is a WASM AI sandbox?

A place to run code that an AI model or agent wrote, compiled to WebAssembly, so it can only touch the memory, network and files it was explicitly given. fenders adds a second wall: every sandbox is also its own hardware virtual machine.

Why put WebAssembly inside a virtual machine?

WebAssembly bounds what a program can address, and the VM boundary contains the runtime itself. If a bug in the WebAssembly runtime were ever exploited, the attacker would still be inside an empty VM with no operating system, no shell and no ambient network access.

Is there a Linux kernel inside the sandbox?

No. Your code runs directly on a WebAssembly runtime inside the VM. There is no guest Linux, init process, shell or filesystem driver to attack.

How fast does a sandbox start?

A fresh VM running a compute module returns a verified result in 2.66 ms (median of 50 runs). A sandbox that calls an HTTPS API and then opens an authenticated PostgreSQL TLS connection, all from inside WASM, finishes in 63.48 ms.

Can sandboxed code reach the internet?

Only where you allow it. You list the exact HTTPS origins and host:port pairs a sandbox may reach, and those checks are enforced outside the VM. With no grants, the sandbox has no network at all.

Can it read or write files?

Only directories you grant: a read-only /app, a scratch /tmp and a persistent /data. The VMM resolves every path beneath its grant and refuses absolute paths, .. traversal and symlink escapes. Without grants, there is no filesystem.

Which languages and APIs are supported?

Anything that compiles to a WASI component. The runtime uses upstream Wasmtime with standard wasi:http, wasi:sockets and wasi:filesystem, so Rust std::fs, Hyper, rustls and tokio-postgres run unmodified.

How do I get started?

Request early access below and tell us what you want to run. We will get your first workload, whether a code interpreter, an agent tool or a customer plugin, running in fenders.

Early access

Put your agent's code behind a fender.

We're onboarding teams that run untrusted or model-generated code. Tell us what you'd run and we'll get you set up.

We'll only email you about fenders access. No newsletter.