Agent Sandboxing: Containers vs. WASM vs. Kernel – Three Ways to Contain AI Agents

In 30 Seconds

AI agents execute code, call APIs, and interact with file systems. Without isolation, that's a security risk. Three approaches are currently competing: Containers (NemoClaw), WASM Sandboxes (IronClaw), and Kernel-Level Isolation (nono). Each solves the problem differently – with different trade-offs in performance, security, and complexity.

Why Agents Need Sandboxing

A classic API call is deterministic: input in, output out. An agent is different. It decides which tools to call, in what order, and with what parameters. That makes it powerful – and dangerous.

Without sandboxing, an agent can:

• Read/write file systems it shouldn't have access to
• Make network requests to internal services
• Read credentials from environment variables
• Trigger side effects that can't be undone

The question isn't whether isolation is needed, but which kind fits the use case.

The Three Approaches at a Glance

Containers: The Proven Path (NemoClaw)

NemoClaw uses containers – the same approach the industry has used for microservices for a decade. Each tool call from an agent runs in its own container with defined resource limits.

Strengths

• Battle-tested: Docker, OCI standards, broad ecosystem
• Complete isolation: Own filesystem, network, process space
• Tooling: Monitoring, logging, orchestration are solved problems
• GPU passthrough: Relevant for local inference (Nemotron models)

Weaknesses

• Startup latency: 100–500ms per container – adds up with thousands of parallel tool calls
• Resource overhead: Each container needs its own kernel namespaces, cgroups, filesystem layers
• Scaling challenges: Thousands of short-lived containers per second is an orchestration nightmare
• Overkill for simple tools: A JSON parser doesn't need its own container

When Containers Make Sense

Containers fit when tool calls are complex, long-lived, and resource-intensive. Example: An agent running local Nemotron inference with GPU access while processing sensitive data. NemoClaw's Privacy Router uses containers for exactly this.

WASM Sandboxes: The Lightweight Path (IronClaw)

IronClaw takes a different approach: agent tools run as WebAssembly modules in a sandbox. No containers, no kernel overhead – just linear memory with defined boundaries.

Strengths

• Microsecond startup: WASM modules start in 1–5ms – orders of magnitude faster than containers
• Minimal overhead: No OS, no filesystem, no network stack
• Determinism: WASM execution is deterministic – reproducible tool calls
• Capability-based security: Tools only get explicitly granted capabilities (WASI)

Weaknesses

• Limited ecosystem: Not every library is available as WASM
• No GPU access: Local inference in WASM isn't practical (yet)
• Memory limits: WASM modules work with linear memory – complex data structures get expensive fast
• Network access: Must be proxied through host functions – additional complexity

When WASM Makes Sense

WASM sandboxes fit when tool calls are lightweight, short-lived, and high-frequency. Example: An agent executing hundreds of small transformations per second – parsing JSON, formatting strings, running calculations. A container per call would be absurd.

Kernel-Level Isolation: The Radical Path (nono)

nono takes the hardest path: isolation at the kernel level through syscall filtering (similar to seccomp-bpf), namespace isolation, and capability dropping. No container runtime, no WASM runtime – direct OS-level control.

Strengths

• Maximum isolation: Direct syscall filter – no detour through container or WASM runtime
• Low overhead: Closer to bare-metal than containers, less abstraction than WASM
• Fine granularity: Control at the syscall level – which system calls can a tool make?
• No runtime lock-in: Works with any language, any binary

Weaknesses

• High complexity: Maintaining syscall policies manually is error-prone
• Linux-only: Kernel features like seccomp, namespaces, cgroups are Linux-specific
• Hard to debug: When a syscall gets blocked, troubleshooting is painful
• Experimental: nono isn't production-ready – it demonstrates what's possible

When Kernel-Level Makes Sense

Kernel-level isolation fits highly sensitive environments where neither container nor WASM runtimes are trusted. Example: Agents in regulated industries (banking, healthcare) that need provably isolated execution.

Decision Matrix

Does the tool call need GPU access?
  ├── Yes → Containers (NemoClaw)
  └── No
       ├── High-frequency (>100 calls/s)?
       │    └── Yes → WASM (IronClaw)
       └── Regulated environment?
            ├── Yes → Kernel-Level (nono)
            └── No → Containers or WASM by preference

Hybrid Architecture: The Realistic Path

In practice, no single approach will win. The most likely architecture is hybrid:

1. Containers for complex, long-lived tool calls with GPU needs
2. WASM for lightweight, high-frequency transformations
3. Kernel-level as an additional hardening layer inside containers

This creates a layered model:

Agent Runtime
  └── Tool Router (decides sandbox type)
       ├── Container Pool (NemoClaw-style)
       │    └── Kernel Hardening (nono-style)
       └── WASM Pool (IronClaw-style)

Connection to Privacy Routing

The sandbox question is directly linked to the Privacy Router. When sensitive data must be processed locally, the local path needs stronger isolation than the cloud path – because cloud providers have their own isolation.

This means: Privacy routing and sandboxing aren't independent decisions. They must be designed together:

Open Questions

• Startup latency vs. security: How much latency is acceptable for better isolation?
• WASM GPU: Will WebGPU in WASM sandboxes become practical for local inference?
• Standardization: Will there be a standard for agent sandboxing, or will the market fragment?
• Attestation: How do you prove that isolation actually worked?

Conclusion

There's no winner in agent sandboxing – only trade-offs. Containers are proven but heavy. WASM is light but limited. Kernel-level is maximally secure but complex. The future lies in hybrid architectures that choose the right isolation level per tool call.

Three takeaways:

1. Containers are the safe default – but not the right choice for everything
2. WASM will be essential for high-frequency calls – startup latency makes the difference
3. Hybrid architectures will become standard – no single approach solves everything

→ NemoClaw: Privacy Router Explained → The 5 Building Blocks of an AI Agent → Learn about Agentic Engineering → Get in touch