The security review reached the agent pods and asked a plain question: if the generated code tried to reach the cloud metadata address, what would stop it? The platform team pointed at the namespace's network policy, then admitted it allowed outbound HTTPS to anywhere, because the agent installs packages. Nobody in the room could list the hosts the agent actually needed.
Most clusters that run agent code already have the first layers: namespaces, resource limits, a locked-down pod spec. What they still need are the two layers that are hardest to build on Kubernetes, a runtime boundary stronger than a shared kernel and egress controls that name hosts rather than address ranges. Solari sets both when an environment is created: every sandbox is a microVM of its own by default, a hardened tier blocks outbound network, and browser sessions take a host allowlist. This guide walks through what each layer has to do and where it lives on Solari.
Why a Container Is Not a Sandbox
The runtime comes first, because every other control assumes the code cannot climb out of its box. A standard container shares the host kernel with every other pod on the node, separated by namespaces and cgroups. For a service the team wrote and reviewed, that is usually enough; for code a model wrote moments ago, a kernel flaw puts the whole node in reach.
Clusters close that gap with a RuntimeClass that swaps the runtime per pod. gVisor intercepts system calls in a userspace kernel, which costs most on I/O-heavy work, and Google is now donating it to the CNCF. Kata Containers goes further and boots each pod inside a lightweight virtual machine. The stronger option is also the harder to operate, which is the next layer.
What a MicroVM Runtime Asks of the Cluster
A microVM gives each workload its own kernel behind a hypervisor, so an escape has to break hardware virtualization rather than a system call filter. On Kubernetes that means nodes that expose virtualization, usually bare metal or nested virtualization, a separate node pool, and a runtime the platform team now patches and upgrades itself. Image pulls and VM boots then add start time to every task.
Solari makes that boundary the default. The dedicated isolation tier is a microVM of your own, and the isolation comparison on the pricing page shows Cloud Hypervisor with a dedicated kernel per session. Sandboxes are still ready in 90 ms, so the stronger boundary does not cost the agent a slow first step.
A cheaper shared tier runs a sandbox as a process tree isolated by namespaces and a cgroup, and even there an organization never shares a VM with another. A strong runtime still lets code talk to the network, which is where most clusters stop.
Why Network Policy Is Not an Egress Control
Egress is the layer the review above tripped on. A Kubernetes NetworkPolicy selects traffic by pod labels, IP blocks and ports, so it can say "deny everything" or "allow this address range", but the core API has no way to say "allow pypi.org". Package mirrors and APIs sit behind CDNs whose addresses change, so teams that need outbound access end up allowing all HTTPS.
That gap matters because the most valuable target is often inside the cloud. A server-side request forgery against the instance metadata address can hand an agent the node's credentials. Real egress filtering for agents means checking hostnames, which on a cluster means an FQDN-aware network plugin or a filtering proxy every pod is forced through. Solari splits the job by surface instead.
Egress on Solari: Block All or Name the Hosts
For code execution, the simplest egress policy is none at all. The hardened tier is the same microVM with all outbound network blocked, chosen in the create call, so a harness can check the boundary instead of trusting a prompt. Volumes are network storage, so a task that needs one runs on the dedicated tier.
Web tasks need the live internet, so browser sessions take a list. The network access setting restricts a stealth session to the hosts in allowedDomains, refuses everything else at the proxy layer and covers subdomains, so example.com also matches api.example.com. An empty list is rejected with an error rather than read as unrestricted, so a configuration that collapses to nothing fails closed.
The setting runs on the Team and Enterprise plans, is sent through the HTTP API, and the create response echoes the list back so the caller can confirm what took effect. It filters hostnames, while direct-IP connections and DNS lookups sit outside its scope, so the code half of a task belongs in a hardened sandbox. With the network settled, what remains is what a run leaves behind.
Clean State and Machine Credentials
Isolation and egress decide what a task can reach; reset decides what the next task inherits. Solari snapshots save a running machine, and revert rewinds the same machine to that point under the same id, so each run starts from a known clean image instead of a pod someone forgot to delete.
The last layer is the handle to the machine itself. A Solari sandbox id and its control and stream URLs act as credentials: whoever holds them can run commands as root in that sandbox until it ends, so they stay out of logs, tickets and client-side code. With every layer covered, the choice comes down to where each one lives.
Choosing the Right Setup
The table lines up each layer on a cluster and on Solari.
The rule is to decide the runtime first, then the egress policy, then the reset, and to set each one where the agent cannot change it. On a cluster every row is a component the platform team builds and owns; on Solari every row is a field in a create call. Teams that keep Kubernetes for the services that coordinate agents and hand each task a Solari machine get the stronger boundary without running the virtualization stack.
Get Started With Solari
Start by moving the agent's code execution into a hardened Solari sandbox and its web steps into a session with an allowlist. Solari is the fastest and cheapest home for that job, about 1.3x faster than E2B on a sandbox's full lifecycle and almost 3x cheaper per sandbox hour, and the Free plan costs $0 with $3 of credits each month. Create your first sandbox from the sandboxes guide and start free, or read the introduction to Solari for the rest of the API.
