Sandboxing AI Agents in 2026: Nono vs Wardgate
By 2026 the interesting attack surface isn't the model, it's the loop around it. An autonomous agent reads a webpage, decides to run a shell command, writes a file, calls an API, and chains the next decision off the output, all without a human in the path. You are no longer running code you reviewed; you are running code an agent synthesized in response to inputs you don't control. That is the whole reason agent sandboxing stopped being optional this year, and it's why two tools Starlog has covered in depth, Nono and Wardgate, keep coming up in the same conversations.
The tools
Nono is kernel-level sandboxing for AI agents without the overhead of containers. The pitch is straightforward and, from a practitioner's view, the right instinct: if an agent is going to execute arbitrary code and tool calls, contain that execution at the operating system boundary rather than trusting the agent to behave. It isolates what the agent process can actually do, syscalls, filesystem, the runtime environment, and does it without dragging a full container runtime along for the ride. That last part matters more than it sounds when you're spawning short-lived agent workers at any scale.
Wardgate takes the problem from the other direction. Instead of isolating the process, it builds a security perimeter around your AI agents, a policy and guardrail layer that governs what an agent is allowed to reach. Think of it as the control plane for agent behavior: which tools, which endpoints, which destinations are permitted, and under what conditions. Where Nono asks "what can this process touch on the box," Wardgate asks "what is this agent permitted to do at all."
How they compare
Based on Starlog's deep-dives, the two tools sit at different layers of the same stack. They overlap enough to get confused with each other and differ enough that picking one and assuming you're covered is a mistake.
| Nono | Wardgate | |
|---|---|---|
| Isolation level | OS / kernel boundary around the agent's execution | Policy perimeter around the agent's reach (tools, endpoints, actions) |
| Threat model | Untrusted code execution: agent runs something that touches the filesystem, processes, or host it shouldn't | Untrusted intent and over-reach: agent tries to call a tool, API, or destination it shouldn't, including via prompt injection |
| Where it sits | Below the agent, at the runtime/OS layer | Around the agent, at the action/egress layer |
| Performance overhead | Positioned as lighter than containers; kernel-level isolation without container runtime weight | Policy evaluation in the request path; cost scales with rule complexity, not process isolation |
| What it does NOT do | Won't reason about intent, an allowed action with bad consequences still runs | Won't contain code that escapes the sanctioned path; it gates reach, not execution |
| Best for | Agents that execute code, shell, or untrusted tool output locally | Agents whose risk is what they call and where data flows, not local code execution |
I'm reasoning about architecture and threat model here, not benchmarks. I don't have head-to-head performance numbers for either, and I'd be suspicious of anyone who quoted you precise overhead figures for your specific workload without measuring it.
When to use which
Reach for Nono when the agent runs code. Coding agents, agents that execute shell, anything that evaluates or runs untrusted tool output on a machine you care about, that is exactly the case kernel-level isolation is built for. If your agent's main job is to write and run software, the host is your blast radius, and you want a hard boundary there. The container-overhead angle is the practical kicker: if you're spinning up isolation per task or per agent, the weight you're not paying adds up.
Reach for Wardgate when the risk is reach and data flow rather than local execution. An agent wired into internal APIs, customer data, and third-party services may never run a line of shell, yet a prompt injection can still convince it to call the wrong endpoint or exfiltrate to an attacker-controlled destination. A perimeter that enforces what the agent can touch, regardless of what the model "decided," is the right control. This is also your answer to the auditor who wants to know what an agent was permitted to do, not just what it happened to do.
The honest take is that for most non-trivial deployments you want both, and they compose cleanly because they don't fight over the same layer. Run the agent's execution inside Nono so a compromised or confused agent can't wreck the host, and put Wardgate around it so the same agent can't reach systems and data outside its mandate. Defense in depth, except here the two defenses genuinely cover each other's gaps: Nono contains the code, Wardgate contains the intent.
Verdict
These aren't competitors so much as adjacent controls people mistake for substitutes. If I had to pick one in isolation, I'd let the agent's job decide: code-executing agents start with Nono, integration-and-data agents start with Wardgate. But "pick one" is the wrong frame for anything heading to production. An agent you've isolated at the kernel but left free to call any endpoint is still a data-exfil incident waiting to happen; an agent with a tight policy perimeter that can still trash the host on a single bad tool call is still an outage. Use Nono for the floor and Wardgate for the walls. In 2026, treating autonomous agents as untrusted by default is just table stakes, and these two are how you make that posture real.