Running 8,764 Sandboxes in Production Taught Me What Sandboxing Really Costs

I spent three days last month debugging why a CI/CD pipeline kept failing silently on GitHub Actions. The logs showed nothing. The code worked locally. It worked on my coworker's machine. When I finally SSH'd into the runner and manually ran the same command, it succeeded immediately. That's when I realized: we weren't actually testing what production would run.

That frustration is probably why this post about auditing AI agent sandboxes hit me so hard. It's not about MCP servers specifically—it's about the uncomfortable truth that security measures always have a cost, and you need to know exactly what you're paying for.

What gVisor Actually Is (And Isn't)

I'll admit, I was fuzzy on the details before digging into this. gVisor is basically a userspace kernel that intercepts system calls instead of letting them hit the real kernel. It's clever because you don't need special hardware support or elevated privileges in the traditional sense. The trade-off? It adds overhead and—this is crucial—it won't let through syscalls it doesn't recognize.

The MarketNow team found that roughly 50% of their tested servers just... won't start under gVisor. Not because they're malicious. Because they use syscalls that gVisor hasn't implemented. That's the real tension nobody talks about in the abstract security papers. In practice, this means you're building a compatibility problem, not just a security solution.

The Actual Security Win (It's Real, But Specific)

Here's what grabbed my attention: across 8,764 audited servers, gVisor caught legitimate attack attempts—a ptrace() call and a bpf() syscall. That's not theoretical. That's real malware behavior that traditional seccomp profiles might miss because they're reactive.

But here's the honest part—zero servers attempted actual kernel exploits. So the question becomes: are you protecting against threats that exist in your threat model, or are you over-engineering? For a marketplace exposing untrusted code, gVisor makes sense. For a private tool running your own scripts? Probably overkill.

GitHub Actions Is Not Your Production

The implementation details matter here, and this is where I'd push back slightly on the approach. The team had to use sudo to install gVisor, which immediately tells me their GitHub Actions workflow isn't replicable in a self-hosted scenario without similar privilege escalation. They also had to allow network access during the build phase (docker build) but lock it down at runtime.

This is fine. It's pragmatic. But it means their L2.5 layer (gVisor) is specifically engineered for GitHub Actions infrastructure. When they move to Firecracker in Q1 2027, they'll be moving to KVM-capable runners on AWS. That's a different game entirely.

The Fallback Is Actually the Reliable One

What I found most useful was their enhanced seccomp profile. Even though gVisor is theoretically better, they built a seccomp fallback that blocks ptrace, bpf, mount, and a bunch of module-loading syscalls. This is the layer that will actually survive across different deployment environments.

# Simplified seccomp profile structure
# (not the actual JSON, just the concept)
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "defaultErrnoRet": "EPERM",
  "syscalls": [
    { "names": ["ptrace", "bpf"], "action": "SCMP_ACT_ERRNO" },
    { "names": ["mount", "umount2"], "action": "SCMP_ACT_ERRNO" },
    { "names": ["clone3", "unshare"], "action": "SCMP_ACT_ERRNO" }
  ]
}

This is what I'd actually run in most production systems. It's explicit, auditable, and doesn't require betting on gVisor's implementation completeness.

My Take on the Six-Layer Approach

I respect the rigor here. Static analysis → behavioral analysis → active probes → gVisor → Firecracker → supply chain attestation → third-party audit. It's layers, and each layer catches something different.

But realistically? Most teams don't have the resources for layer 5 (Trail of Bits audit bills aren't cheap). So the question is: what's the minimum viable security posture that actually protects you without becoming unmaintainable?

For AI agents specifically—code that can execute and access your systems—I'd argue layers 1-3 plus the seccomp fallback give you 80% of the benefit with 20% of the overhead. gVisor becomes valuable when you're running completely untrusted workloads on multi-tenant infrastructure.

What I'm Actually Taking Away

This research validates that sandboxing isn't binary. You don't get perfect security from gVisor, but you do get predictable failure modes (things won't start if they use certain syscalls). That's useful information. It means you can test for compatibility early instead of discovering problems in production.

If you're building something that runs user-submitted code, start with seccomp. Measure your overhead. Only move to gVisor if you actually see attacks that seccomp would have missed.

What's your current approach to sandboxing untrusted workloads? Are you using seccomp, containers, or something else entirely?

Source: This post was inspired by "Response to 'gVisor vs Firecracker for AI Agent Sandboxing' — what we learned auditing 8,764 MCP servers" by Dev.to. Read the original article