MITIGATION · m-gvisor
gVisor sandbox — a user-space kernel that intercepts every syscall a container makes
When an agent executes generated or retrieved code, that code runs as a process with access to the host kernel. A vulnerability in the generated code, or a deliberate exploit injected through the agent's prompt, can reach the kernel and affect other workloads or the host itself. gVisor prevents this by inserting a user-space kernel implementation between the container and the host: the container's syscalls go to the Sentry process, not to the host kernel, so the reachable attack surface from inside the container is structurally smaller.
At a glance
TL;DR
- gVisor inserts a user-space kernel (the Sentry) between a container and the host kernel, intercepting every syscall before it reaches the host.
- Each sandboxed container runs its own Sentry instance: no kernel-state side-channels exist between parallel agent workloads, because each workload's kernel interface is isolated by construction.
- Filesystem access goes through a separate Gofer process over 9P, so the container never touches the host virtual filesystem directly.
- Default sandbox for Google Cloud Run, App Engine, and Cloud Functions: production-proven at large multi-tenant scale with a published security advisory process.
How it behaves
What it is
A Linux container running on a standard kernel makes syscalls directly to the host kernel. If the code inside the container exploits a kernel vulnerability, or if prompt-influenced code is crafted to do so, that exploit path runs against the same kernel that hosts every other workload on the machine. gVisor closes that path by interposing a user-space kernel between the container and the host.
The core component is the Sentry: a Go process that implements the Linux kernel API in user space. When a containerised process makes a syscall, the Sentry intercepts it, handles it in its own implementation, and forwards only a narrow set of operations to the host kernel through a minimal interface. The host kernel never sees the full syscall stream from inside the container. Filesystem access is mediated through a separate Gofer process over the 9P protocol, so the container does not interact with the host virtual filesystem directly. Each sandboxed container runs its own Sentry instance, which means two containers sharing a host cannot reach each other through shared kernel state.
The practical result is that code executing inside a gVisor container has a much smaller kernel attack surface than the same code running in a standard container. A kernel exploit crafted by or injected into generated code hits the Sentry's Go implementation, not the host kernel. The Sentry itself can have vulnerabilities, and those are tracked through a published advisory process, but the boundary between the Sentry and the host is substantially narrower than the full kernel syscall interface.
For agentic systems, the relevant scenario is any agent that can execute code it did not write: a code-execution tool, a Python interpreter used to evaluate model-generated scripts, or an arbitrary subprocess invoked by a tool call. All of these should run inside a gVisor sandbox with network access disabled and an ephemeral filesystem, so that the attack surface available to injected or malicious code is limited to what the Sentry exposes.
Detection signals
- Syscall-policy violations logged by the Sentry. A spike in violations from a sandboxed workload indicates that running code is reaching for operations outside the approved set, which warrants immediate investigation.
- Unexpected outbound network connections from sandboxed workloads. Any network egress from a container that should have no external access is a containment signal.
Threats it covers
-
WHY IT HELPS Unexpected RCE and Code Attacks arise when an agent executes generated or prompt-influenced code that exploits the underlying execution environment. gVisor places a user-space kernel between the container and the host, so kernel-exploiting code hits the Sentry's Go implementation rather than the host kernel, and the reachable attack surface from inside the container is structurally limited.
-
WHY IT HELPS Framework vulnerability exploitation requires that malicious code running inside the agent's execution environment can reach the host OS or interact with other workloads. gVisor's syscall interception boundary limits that reach: code exploiting an unpatched framework vulnerability runs inside the Sentry's isolation layer, and the set of host operations it can invoke is restricted to those the Sentry forwards.
-
WHY IT HELPS Insufficient isolation between agent executions allows one agent's code to observe or affect another's through shared kernel state. gVisor assigns each sandboxed workload its own Sentry instance, so kernel-state side-channels between parallel agent executions are structurally blocked rather than policy-controlled.
-
WHY IT HELPS Insufficient MCP server permission isolation at the execution layer means agent tool code can access host resources or peer-agent state beyond what its scoped tool is permitted. Running each agent's tool code inside a gVisor sandbox enforces that boundary at the kernel interface: the Sentry mediates every resource access, and the host grants only what the sandbox policy allows.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Microsegmentation gVisor enforces microsegmentation at the kernel interface: each sandboxed workload runs its own Sentry instance, so kernel-state and filesystem paths between parallel agent containers are structurally separate rather than policy-controlled.
- Containment (blast radius) gVisor bounds the blast radius of code executing inside an agent container by limiting what that code can reach at the syscall layer, so a compromised or malicious workload cannot affect the host kernel or peer containers through the normal kernel interface.
- Sandboxing & Isolation gVisor is the direct implementation of kernel-level sandboxing for container workloads: it places a user-space kernel between the container and the host, so the isolation boundary is enforced at every syscall rather than relying on OS-level policy or seccomp filters alone.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
gVisor is the lightest-weight option. Alternatives trade more overhead for stronger (VM-level) or simpler (policy-only) isolation.
gVisor User-space kernel that intercepts syscalls via the Sentry process. OCI-compatible; integrates with Docker, containerd, and Kubernetes runtimeClass.
Why choose it: Lowest overhead among sandboxed runtimes; no hypervisor required; production-default on Cloud Run and App Engine. Best starting point for AI code-execution sandboxes. Install runsc, register a RuntimeClass with handler: runsc, annotate agent pods with runtimeClassName: gvisor.
More details:
Kata Containers Runs each container inside a lightweight VM with a dedicated guest kernel, providing a hardware-enforced isolation boundary.
Why choose it: Stronger isolation than gVisor because the boundary is a hardware virtualisation layer (VT-x/AMD-V), not a software syscall interceptor. Use when the threat model requires hardware-level separation between agent workloads or multi-tenant scheduling. Supports QEMU, Cloud-Hypervisor, and Firecracker backends.
More details:
Firecracker microVM KVM-based VMM that boots a minimal Linux guest in under 125 ms with under 5 MiB overhead per VM. Powers AWS Lambda and Fargate. Includes a jailer process for a second isolation layer.
Why choose it: Use when you need VM-level isolation with near-container startup speed and you control the host kernel. firecracker is invoked by a wrapper or via Kata Containers using Firecracker as its hypervisor backend, combining both projects' isolation strengths.
More details:
runc with seccomp Standard OCI runtime with a custom seccomp filter that restricts which syscalls the container can make. No separate kernel implementation; relies on the host kernel BPF-based filter.
Why choose it: Zero additional infrastructure; works everywhere Docker or containerd runs. Appropriate when gVisor compatibility gaps block adoption or when you need a hardening baseline with minimal overhead. seccomp filters do not protect against zero-day host kernel vulnerabilities that bypass the filter, so this is a reduction in attack surface rather than an isolation boundary.
More details:
gVisor on Kubernetes Install runsc on cluster nodes, register a RuntimeClass (handler: runsc), and annotate agent pods with runtimeClassName: gvisor. The containerd shim (containerd-shim-runsc-v1) bridges containerd and the Sentry.
Why choose it: Standard production path for teams running their own Kubernetes. The install footprint stays on nodes and applies selectively: only code-execution pods pay the Sentry overhead, the rest of the cluster uses runc.
More details:
Trade-offs
- Syscall-heavy workloads, such as file-per-request patterns or high-throughput network I/O, pay measurable latency. The Young et al. HotCloud 2019 study found file-open via Gofer significantly slower than native; compute-bound workloads see minimal overhead. Benchmark your specific workload before assuming a number.
- No license cost; runs alongside existing containerd and Docker deployments without additional cloud infrastructure spend.
When NOT to use
- Workloads making thousands of file-open or network syscalls per second at production scale, where the Gofer-mediated filesystem and per-syscall Sentry overhead will produce real request-latency increases.
- Environments already inside a hardware VM boundary, such as Firecracker, KVM-backed containers, or dedicated VMs, where the hypervisor already isolates the guest kernel and gVisor adds syscall overhead without proportional security gain.
Limitations
- gVisor does not implement every Linux syscall. Workloads that use rare or newer syscalls may fail to run or require the ptrace platform (slower than the default KVM platform). Verify compatibility against the gVisor syscall table before production rollout.
- Hardware side-channels such as Spectre and L1TF are not addressed by gVisor. The security model explicitly defers those to the host OS and platform. For multi-tenant high-assurance environments, pair with VM-level isolation.
Maturity tier reasoning
- T1 applies because gVisor is the production-default sandbox for Google Cloud Run, App Engine, and Cloud Functions. Its security model and threat model are publicly documented at gvisor.dev/docs/architecture_guide/security/ and its CVE advisory process is mature.
- Peer-reviewed characterisation: Young et al., "The True Cost of Containing: A gVisor Case Study," USENIX HotCloud 2019, confirms the security model structure and quantifies the overhead profile.
- T2 and below do not apply: gVisor is production-canonical, not experimental or framework-dependent.
Last verified against upstream docs: 2026-05-30.