Hope Is Not a Security Strategy: Why Secure-by-Default Beats Hardening
Posted on February 9, 2026 • 4 minutes • 692 words
Agents break the contract of trust
Agents are underdeterministic. Underdeterminism is incompatible with trust. Period.
Security has always assumed deterministic behavior. We can’t write policy to prevent bad outcomes when we don’t even know what the agent will do. Sandboxing is the natural answer: everyone is buying Mac Minis to run Moltbot (OpenClaw now), Docker is using microVMs for coding agent sandboxes, and countless projects offer sandboxing tools for AI agents.
That’s why in late 2024 I wrote hyper-mcp , a WASM-based sandboxing MCP server. I’ve been in banking for a long time and care about security deeply. The moment enterprises turned to AI agents, I know for sure that security had to step up.
For a long time, AI didn’t need sandboxing; most use was chat and image generation. Introduce tool calling and MCP, and that changes. Sandboxing the MCP layer is the easy part: the servers themselves behave deterministically. The overall flow does not; the agent orchestrates it. So for agents, the direction is clear: isolate by default, run them in microVMs or sandboxed runtimes, draw hard boundaries.
Your production still runs on a shared kernel
We’re settling on that for agents. Meanwhile, your production infrastructure is still using containers with a shared kernel. Namespaces and cgroups limit visibility and resource use, but every container shares the same kernel. One escape or kernel bug can blur the line between workloads. We’ve learned to live with that trade-off: cheaper, lighter, good enough for most of the time. Until it isn’t.
The industry has optimized for density and speed, not for hard boundaries. Multi-tenant clusters, sidecars, and shared nodes are the default. When something goes wrong, we rely on the same playbook we’ve always had: harden the image, lock down the config, monitor like crazy, and respond when the alert fires. That playbook assumes we can define and enforce “good” behavior. It doesn’t assume a process can do anything the kernel allows and we simply won’t know in advance what that is. So we patch, we scan, we segment, and we hope nothing broke. But hope is not a strategy.
We do golden-image hardening. We invest heavily in protection and monitor everything we can think of. We invest in response and remediation. But guess where most of those security tools live: in or around the same kernel. eBPF, runtime detectors, syscall hooks, network policies, seccomp profiles. We’re layering more and more on the very surface we don’t trust when it breaks. It’s the same playbook, and it still assumes we can define and enforce what “good” looks like.
What if we architect for secure by default?
What if we started thinking like a cloud hyperscaler? Run anything you throw at us; treat all of it as untrusted by default. No exceptions.
That’s exactly what gVisor, Firecracker, and the like do. The tech came from hyperscalers because they have to assume every workload is hostile. Yet adoption is thin: gVisor is barely used, Firecracker a bit more but still niche. Why? Setup is fiddly and the developer experience is poor. Isolation has felt like a Google-scale investment, something you justify only when you’re big enough. It shouldn’t. Security should be easy to use and operate, or invisible: secure by default.
Secure by design, not by hope
We’ve spent decades hardening, monitoring, and responding, and crossing our fingers. That model assumed we could predict and constrain behavior. Agents break that assumption. We can’t write policy for outcomes we can’t enumerate; we can only bound what code is allowed to do in the first place. Sandboxing and strong isolation aren’t a nice-to-have for AI; they’re the only way to get trust when the system is inherently non-deterministic.
The same lesson applies beyond agents. If hyperscalers treat every workload as untrusted and isolate by default, maybe we should stop treating “shared kernel + hope” as good enough for our own production. The tech exists: gVisor, Firecracker, microVMs, WASM. What’s missing is making it trivial to adopt, so that secure-by-default becomes the path of least resistance, not a Google-scale project.
Until then, we’re not securing by design; we’re securing by hope. And hope is not a strategy.