The moment an agent can run code, write files, or call an internal API, it stops being a feature and starts being a workload with your permissions. The industry's default answer has been to restrict agents until they're safe and useless. The honest answer is that a standard container is not a security boundary — it shares a kernel, and a kernel exploit is the whole game. If you want agents doing real work against real systems, isolation is the product, not a checkbox.
An agent runtime platform and Kubernetes-based sandbox with two layers of enforcement: gVisor intercepting syscalls in userspace so a compromised workload never talks directly to the host kernel, and Cilium eBPF enforcing network policy at the sandbox boundary so egress is allowlisted rather than assumed. Built for production coding agents and AI-native workloads, not for a demo environment.
Isolation costs latency and developer patience. Every boundary you add is a boundary a team has to understand before they ship. The design work wasn't picking gVisor — it was making the secure path the default path, so a team onboarding didn't have to become kernel-security experts to get their agent running.
Teams shipping agent features do not want to run this themselves. The category is converging fast — managed agent runtimes from the hyperscalers, ephemeral sandbox products from the edge platforms — and they're all competing on the same axis: how little does the customer have to know. Whoever makes strong isolation a one-line default instead of a research project owns this layer. Everyone else is selling a kit of parts.