Your agents inherit every permission of the machine they run on
A model doesn't have to be compromised to be dangerous — it just has to be persuaded. Sandboxing bounds what a persuaded model can do.
Threat 01
Prompt injection
Adversarial input in a document, tool output, or chained agent hijacks the model's instructions. In a sandbox, even a fully hijacked step can only use the capabilities that step was granted.
Threat 02
Data exfiltration
An agent with ambient network access can send anything it reads anywhere it likes. Capability-scoped networking means outbound connections exist only where you declared them.
Threat 03
Lateral movement
One bad tool call shouldn't become a beachhead. Each sandbox starts empty — no credentials, no shared filesystem, no path to its neighbors — so an attacker who lands in one has nothing to steal and nowhere to go next.
Definition
What is an AI sandbox?
An AI sandbox is an isolated execution environment for code you can't fully trust — AI-generated programs, LLM tool calls, MCP servers, and autonomous agent actions. It exists so that the worst thing untrusted code can do is bounded before it runs.
Most sandboxes start from a full computer and subtract: strip syscalls, filter networks, wrap kernels. WebAssembly components invert the model. A component starts with nothing — no filesystem, no network, no clock, no environment — and receives only the capabilities its task explicitly requires. Security people call this the principle of least authority; for AI workloads it's the difference between hoping a model behaves and not needing it to.
Because instantiation costs less than a millisecond, isolation gets cheap enough to apply per invocation — every tool call gets a fresh sandbox, and nothing persists between calls unless you say so.
agent tool call→wasm sandbox
✓ grantedhttp: api.internal/orders
✓ grantedkv: session-cache (read)
filesystemenv varsnetwork:*exec
deny-by-default · grants are explicit
Substrate comparison
Why WebAssembly, not another container
Containers, microVMs, and Wasm components all isolate — the difference is what that isolation costs at agent-traffic scale.
Capability
Containers
MicroVMs
Wasm components
Isolation model
Shared kernel, broad syscall surface
Strong, VM-level
Capability-based, shared-nothing — least privilege by default
Cold start
Hundreds of ms to seconds
~100 ms to seconds
Sub-millisecond
Density
~100 per node
Lower — per-VM memory overhead
10,000s per host
Scale-to-zero
Possible, with cold-start or warm-pool cost
Pre-warmed pools idle expensively
Native — restart is effectively free
Per-call isolation
Impractical at agent volume
Costly
Practical — fresh sandbox per invocation
In production
Runs on the Kubernetes you already have
Cosmonic Control is a Kubernetes-native control plane: CRDs and an operator, not a parallel platform. Your namespaces, RBAC, ingress, GitOps, and observability keep working.
Install the control plane
One Helm install adds the operator and CRDs to your cluster. Works with your admission policies and existing supply-chain controls.
Deploy sandboxed workloads
Ship agents, MCP servers, and functions as Wasm components via OCI registries — declared, signed, and versioned like everything else you deploy.
Scale with standard tooling
Workloads implement the Kubernetes /scale subresource, so HPA and KEDA autoscale sandbox instances across hosts — including scale-to-zero.
White paper
From Prompt to Production: Sandboxing the Vibe-Coded Enterprise
What changes when AI writes the code your business runs — and how platform teams keep shipping fast without inheriting the risk.
An isolated execution environment for code you can't fully trust — AI-generated programs, LLM tool calls, MCP servers, and autonomous agent actions. It contains what the code can touch, so a manipulated model or malicious output can't reach the network, filesystem, or credentials beyond what the task explicitly requires.
Why do AI agents need sandboxing?
Agents inherit the permissions of wherever they run. A prompt-injected agent with host-level access can exfiltrate data, move laterally, and execute arbitrary code. Sandboxing every tool call in a deny-by-default environment bounds the blast radius of any single manipulated step — even when the model itself is fooled.
How is WebAssembly sandboxing different from containers?
Containers share the host kernel and expose a broad syscall surface; hardening them for untrusted code means microVMs, warm pools, and cost. WebAssembly components run in a shared-nothing sandbox with capability-based security: zero ambient authority, explicit grants for every I/O path, sub-millisecond instantiation, and thousands of instances per node.
Can I run AI sandboxes on my existing Kubernetes cluster?
Yes. Cosmonic Control installs into your current clusters with CRDs and an operator, respecting existing namespaces, RBAC, ingress, and CI/CD. Sandboxed WebAssembly workloads run alongside your containers and scale with standard tooling like HPA and KEDA.
Does sandboxing add latency to agent workflows?
WebAssembly component instances start in under a millisecond, so per-call isolation is practical rather than costly — each tool invocation can get a fresh sandbox without warm pools. Autoscaling decisions ride the standard Kubernetes control loop, and new capacity is live the moment it's scheduled.
Get started
Sandbox your first workload today
Free to install on any Kubernetes cluster — cloud, on-prem, or edge.
