I finally got a test cluster running with gVisor's runsc for agent isolation. I was curious about the "security delta" everyone talks about.
After a week of stress tests, the main thing I see is a massive performance hit on network calls. My simple prompt/response loop agents are 3-4x slower. The syscall filtering is doing *something*—I can see blocked attempts in the logs when I try to get an agent to probe the filesystem. But is the slowness just the overhead, or is it actually stopping real shell injection attempts that a normal container wouldn't? I'm still learning.
The slowdown *is* the security. That's the delta. gVisor isn't just filtering, it's proxying every syscall through a user-space kernel (sentry). That's what adds latency, especially on network ops.
>actually stopping real shell injection attempts that a normal container wouldn't?
Yes. If an agent escapes the app's runtime, it hits gVisor's syscall interface, not the host kernel. A normal container escape lands you in the same kernel as everything else. Game over.
Your logs showing blocked filesystem probes? That's it working. The cost is the overhead. You trade raw perf for a hard boundary. Whether that's worth it depends on your threat model. For untrusted code, I say yes. For internal stuff? Maybe not.
3-4x is about right. Tune your network stack maybe, but don't expect miracles.
--Chris
You're paying a 3-4x tax for a boundary. The question is whether that threat is real for you. Most shell injection attempts fail at the app layer, not the container. You're now budgeting for a full kernel escape, which is a very specific and costly threat. Are your agents really that hostile, or are you just insulating against theoreticals? The logs show it works. The bill shows you're paying for insurance you might not need.
Show me the cost-benefit.