Evaluating Sandbox Network Egress Controls for Agents

Evaluating Sandbox Network Egress Controls for Agents.

Why network egress is the control surface that determines whether a breach stays contained

The mechanism is not complicated, which is part of why it gets overlooked. A compromised agent can read whatever data sits inside its sandbox, but reading is not the damage. Sending that data somewhere is the damage, and sending requires a network path off the box. Cut the path, and an agent that has been fully tricked, manipulated, or hijacked by a malicious prompt has nowhere to put what it stole. An escaped agent with no egress is, in a meaningful sense, mostly harmless.

The clearest illustration of this on record is the ZombAIs demonstration published by security researcher Johann Rehberger. He built a webpage carrying a hidden prompt injection payload, then let Claude's Computer Use feature navigate to it. The agent read the page, downloaded a binary, ran chmod +x on it, executed it, and connected out to a command-and-control server Rehberger controlled. That is the entire kill chain: injection, download, execution, C2 callback. And it worked on the first try.

Notice what's doing the actual work in that chain. The prompt injection alone didn't do it, and neither did the code execution alone. It's the fact that the sandbox had an open door to the internet the whole time. Isolation (keeping the agent's code from breaking out of its box) and egress control (keeping the agent's data from getting out over the network) are different locks on different doors, and ZombAIs only needed one of them left unlocked.

So why is egress the control most teams skip? Partly it's laziness dressed up as pragmatism: it's much easier to open a port than to sit down and enumerate every destination a task actually needs. And partly it's a framing problem. Most sandbox threat models are built around stopping code execution, containing the fork bomb, preventing the container escape, and they treat data movement as an afterthought. Every section that follows is really asking the same question against each of these five: does this control stop it, or does it just look like it does?

One further point deserves attention before moving on. A paper on deterministic pre-action authorization for autonomous agents found that 83% of companies plan to deploy AI agents Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. At that scale, egress policy becomes essential infrastructure, not an optional security feature bolted on after launch Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. C2 channel establishment, as in ZombAIs, illustrates why network egress is the control surface that determines whether a breach stays contained.

What makes agent egress different from conventional application firewall rules

Conventional application firewalls work because conventional applications are predictable. A payments service calls its database, its logging endpoint, maybe a couple of third-party APIs, and that list barely changes month to month. Write the allowlist once, review it twice a year, done.

Agents break that model, and they break it on purpose. The ReAct pattern (Yao et al., 2022) and the broader tool-calling architecture that most agent frameworks now use mean an agent spins up interpreters, calls APIs, and runs shell commands as a matter of routine operation. The egress surface is the design. It's the design.

That's what makes prompt injection so dangerous as an egress-expansion vector. A page the agent visits, or a tool response it receives, can contain instructions crafted to make the agent call a destination nobody on the security team ever anticipated. The allowlist that made sense at design time is now being tested against inputs the designers never saw, because the whole point of an agent is that its next action depends on what it just read.

That raises an important question: if the destination list can't be fixed in advance, what can be fixed? The answer is scope. Agent tasks tend to be ephemeral, one task, one objective, one narrow set of tools, and a task that needs a single API should be handed exactly that API, matched to what the task actually requires. Disposable, per-run sandboxes make this natural: spin up a container for the task, attach the narrow allowlist, and when the container dies, the allowlist dies with it. Nothing accumulates.

DNS deserves its own callout here, because it's the channel people forget even when they've done everything else right. Treating a core network protocol as safe by default, because "it's just name resolution," is exactly the kind of assumption an attacker is counting on.

None of this is theoretical grumbling. That's more than a quarter of teams voting with their code that the generic, one-size-fits-all controls weren't meeting what agent workloads actually demand Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents.

The default-deny posture: why "block everything, then open what breaks" is the only defensible starting point

Start from zero. The sandbox boots with no outbound network path at all, effectively a network namespace with no default gateway, and only the specific destinations a task genuinely needs get opened up afterward. Everything else stays shut.

Why start from zero rather than start from "reasonable" and tighten later? Because of a basic asymmetry. Nobody can enumerate every bad destination on the internet, there are too many, and new ones appear every day. But almost any given task's list of good destinations, the handful of APIs and domains it actually needs to hit, is short enough to write down by hand. Default-deny bets on the side of the asymmetry that's actually winnable.

The failure mode that undermines this looks reasonable in the moment and disastrous in aggregate. Someone on a team says "the task might need this," opens a rule, and moves on. Repeat that decision across a few dozen tasks over a few months and a supposedly scoped allowlist has quietly become a permanent, global one. Every entry on that list is now attack surface available to every task that runs, whether that particular task needs it or not.

When evaluating a platform against this standard, a handful of concrete questions separate marketing language from an actual security posture. Is the sandbox's network namespace isolated from the moment it boots, or does isolation require someone to configure it correctly, one missed flag away from wide open? Does the platform state its default-deny stance somewhere a customer can read it, or is that posture something you have to infer by reading container flags and hoping? And critically: can a task, from inside its own sandbox, override its own egress policy? If the answer to that last one is yes, the control doesn't really exist.

That last question points at something structural. NVIDIA's NemoClaw design, announced in March 2026 at GTC, builds on the requirement that the policy engine run outside the agent's own process. That's not a small implementation detail. If the thing enforcing the rule lives inside the same process the compromised agent is running in, the agent (or whoever hijacked it) can potentially rewrite the rule. Enforcement has to sit somewhere the agent can't reach, full stop.

The data backing default-deny is about as stark as security research gets. An adversarial testbed built around the pre-action authorization paper, covering 4,437 authorization decisions across 1,151 sessions and backed by a $5,000 bounty for successful attacks, found that under a permissive policy, social engineering attempts against the agent succeeded 74.6% of the time Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents. Under a restrictive, default-deny policy, attackers achieved a 0% success rate across 879 recorded attempts Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents. That's a dramatic improvement from tightening a rule here and there. That's the difference between a coin flip and a wall, and it says the posture itself, not the specific tooling used to enforce it, is the variable that actually matters Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents.

Allowlist granularity: domain-level, protocol-level, and per-task scoping

Once default-deny is established, the next question is what unit the allowlist should be built around. Allowlisting by IP address feels precise, but it fails for agent workloads on two fronts at once. Domains stay stable in a way IPs don't. Domain-based allowlisting, enforced through an egress proxy that can actually resolve and check the hostname, is the more defensible primitive.

Domain-level control alone still isn't the whole story, though. Allowlisting a domain doesn't matter much if any protocol at all can reach it. DNS resolution needs to be handled separately from the rest of traffic, ideally by giving the sandbox a resolver the operator controls rather than trusting whatever resolver the host machine happens to be configured with. And channels that bypass the application layer entirely, ICMP, raw sockets, need to be blocked at the network namespace level itself, because no amount of domain allowlisting touches them.

The scoping issue driving all of this is per-task versus per-system. A task that needs one API should be granted exactly that API, matched to what the task actually requires. That distinction only works if the allowlist gets built at the moment a task is dispatched, rather than baked into a static platform configuration ahead of time. There's a credential hygiene benefit that falls out of this almost for free: route secrets through the egress proxy itself, so the credential never has to sit inside the agent's own code or memory. The proxy holds the key, and the agent only ever sees the response that comes back.

A concrete reference point for what fine-grained enforcement looks like in practice is the CubeVS pattern, which assigns each sandbox its own TAP network device with policy enforced via eBPF. Three eBPF programs sit directly on the kernel's data path: from_cube handles TC ingress on the TAP device, doing source NAT, the policy check itself, and session tracking; from_world handles TC ingress on the host's network interface for the reverse NAT; from_envoy handles TC egress on the overlay network, doing destination NAT back to the sandbox's own address. By default, every private subnet is blocked outright: 10/8, 172.16/12, 192.168/16, 127/8, and 169.254/16 How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. A compromised sandbox can't casually scan its way into whatever internal network happens to sit next to it, even before any task-specific allowlist gets applied.

Egress control doesn't have to live only at the network layer, either. Firecrawl's Lockdown Mode restricts its /scrape endpoint to serve cached results only. A URL smuggled in through a prompt injection can't trigger a fresh, live outbound request at all. It's a reminder that the application layer can do real enforcement work of its own, not just the network stack underneath it.

A more ambitious version of that idea appears in ceLLMate's HTTP-layer sandboxing, described in the same 2026 research Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. Its Agent Sitemap maps individual requests to semantic actions, and a Chrome extension enforces default-deny on outbound traffic at that layer. In testing, frontier models achieved better than 94% accuracy predicting which policy should apply to a given request, and the system blocked all twelve emulated prompt injection attacks thrown at it, at a cost of 7 to 15% added latency. That's a fairly convincing existence proof that policy enforcement at the HTTP layer is conceptually sound. It's measurably accurate, and the performance cost is tolerable. In assessing allowlist granularity across domain-level, protocol-level, and per-task scoping, domain vs. IP allowlisting shows why IP-based rules fail for agent workloads.

Protocol-level enforcement beneath the application layer

Every allowlist and every proxy rule depends on a more basic question that produces the real test: what stops the agent's underlying execution environment from simply bypassing the enforcement layer altogether? The answer depends entirely on which isolation model the sandbox uses.

That shared kernel is exactly what a kernel-level vulnerability can exploit to punch through namespace-based egress rules from the inside. CVE-2024-21626 is a live example: an internal file descriptor leak in runc versions 1.1.11 and earlier, exploitable through a crafted WORKDIR directive to reach the host filesystem How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. CVE-2025-59528, carrying a CVSS score of 10.0, is a second, more severe example of the same category of risk How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation strategies | Blog — Northflank. Neither of those is a hypothetical; they're documented vulnerabilities in widely deployed container tooling.

gVisor takes a different approach, intercepting syscalls in user space so the guest process never touches the host kernel directly. That meaningfully shrinks the kernel attack surface, at a cost of roughly 10 to 30% overhead on I/O-heavy workloads. Egress policy under gVisor gets enforced at the level of its Sentry process, which sits between the sandboxed workload and the world.

MicroVM approaches, Firecracker and Kata Containers among them, go further still, giving each sandbox its own dedicated guest kernel. NIST's own position is blunt about the container end of this spectrum: containers don't offer as clear a security boundary as VMs do, precisely because they share the host kernel, and that applies directly to whether egress rules can be trusted to hold, not only to whether code stays contained.

This is why some platforms run mixed-runtime architectures on purpose, containers for GPU workloads (accepting the weaker boundary there) and VMs where full isolation is non-negotiable. Any egress policy layered on top of a mixed-runtime setup has to account for which runtime a given task is actually running under, because the enforcement guarantee is not the same across the two.

None of this needs to come at a prohibitive performance cost. Strong isolation at the microVM layer and fast task startup aren't in tension with each other.

A moving target drives all of this, and it deserves to be named directly. Frontier model success on apprentice-level cybersecurity tasks went from under 10% in late 2023 and early 2024 to roughly 50% by 2025, with the first expert-level task completed sometime during that same year AI Agent Sandbox Technologies: A Complete 2026 Comparison. A sandbox and egress design calibrated to what a model could pull off in 2023 is being asked to hold against a model with meaningfully sharper capability today AI Agent Sandbox Technologies: A Complete 2026 Comparison. Egress controls that felt generous two years ago deserve a second look now.

Observability: what egress logging must capture

None of the controls above are worth much if nobody can see what actually left the sandbox. Logging is a live signal. It's a live signal, the difference between catching an exfiltration attempt in progress and finding out about it in a postmortem.

At minimum, an egress log record needs to capture the destination (both the domain and the IP it resolved to), the protocol used, the payload size, the timing, the sandbox's identity, and the task's identity. Strip any one of those out and the record stops being useful for investigation. Unusual volume, an unexpected destination, a size that doesn't match the task, timing that doesn't fit the pattern, these are all live indicators that something is wrong, but only if logging happens per request. Aggregate summaries computed after the fact smooth over exactly the anomalies that matter.

The log itself has to be tamper-resistant. Every network request, every shell command, every file write belongs in an immutable audit trail written somewhere outside the sandbox itself, so a compromised agent has no path to editing its own record. Three invariants should be checked against that log directly: the agent should never touch files outside its assigned workspace, it should never send secrets to an external endpoint, and it should never contact anything outside its per-task allowlist. If the log can't confirm all three, the observability layer has a hole in it.

Cryptographic provenance per action is achievable without turning latency into a real cost.

But logging is only as trustworthy as the transport carrying the traffic being logged. The same research that produced the authorization figures above also found more than 492 MCP servers exposed in production without authentication or encryption. Log coverage over an unauthenticated transport is a false sense of security, since anyone in a position to intercept the traffic can also spoof or alter it before it ever reaches the log. Observability, done properly, has to include a record of the authentication state of every outbound connection, along with its destination and size.

Pre-action authorization and post-hoc logging aren't substitutes for each other; they solve different halves of the problem. Pre-action authorization is what stops the unauthorized call before it goes out. Logging is what proves, afterward, exactly what happened, and it's what feeds the next round of policy refinement. A platform with one but not the other has half a system. Per arxiv.org/pdf/2603.20953, the Open Agent Passport enforces authorization decisions in a measured median of 53ms (N=1,000) and produces a cryptographically signed audit record, demonstrating that per-action logging with cryptographic provenance is achievable at low latency, a point relevant to what egress logging must capture and why it is not optional.

How current sandbox platforms handle egress controls in practice

Egress policy here operates at the microVM boundary itself.

Northflank offers a choice of isolation runtimes rather than locking customers into one: Kata Containers with Cloud Hypervisor as the primary VMM (Firecracker and QEMU are also available), standalone Firecracker, or gVisor for user-space kernel protection Blog — Northflank. Sessions have no fixed length limit, deployments can run bring-your-own-cloud on AWS, GCP, Azure, or bare metal, and GPU support spans H100, H200, B200, A100, L4, and L40S hardware, among others Blog — Northflank.

Cloudflare Sandboxes reached general availability on April 13, 2026, priced on the Workers Paid plan at $5 a month. State doesn't survive sleep here: the container stops after a default ten-minute idle timeout, and egress control inherits the broader Workers network model. That statelessness is a real constraint for any agent workflow that needs its egress policy to persist across a longer-running, multi-step task.

Freestyle takes a different route entirely, offering a full hardware-virtualized Linux VM with its own kernel, support for nested virtualization (Docker or KVM running inside the VM), and full Linux networking with genuine root access. The tradeoff is direct: full Linux networking means there's no default-deny posture out of the box, and egress policy is squarely the operator's job to configure.

AgentScope 1.0 splits its architecture into an Engine, handling infrastructure, context, and session management, and a Sandbox component that provides isolated environments for tool execution. Egress posture here is a function of how the Engine gets configured rather than something fixed by the platform itself.

GKE Agent Sandbox, Google Cloud's offering, deploys through a GKE cluster and isolates untrusted code inside a sandboxed Python environment, with documentation last updated September 24, 2026. Egress control inherits whatever GKE network policy is in place, whether that's Kubernetes NetworkPolicy or Dataplane V2. The strength of the egress guarantee here tracks how carefully the operator has configured the underlying Kubernetes networking layer.

A microVM layer for egress policy enforcement can achieve boot times of ~125ms, less than 5 MiB overhead per VM, and up to 150 VMs per second per host, but the answers to the underlying questions matter more than any single benchmark number.

The evaluation

The sources checked for this guide are listed below.