Network Egress Controls for Coding Agent Sandboxes

Coding agents write and run code that no human reviewed before execution. That single fact breaks most of the security assumptions built into traditional software, and network egress control, the rule set that decides what an agent's sandboxed process is allowed to reach outside itself, is the mechanism engineering teams lean on to survive it.

A conventional application ships with a fixed, audited instruction set. Someone wrote it, someone reviewed it, and its behavior at runtime is (mostly) knowable in advance. Coding agents don't work that way. They generate novel code on the fly, from inputs that can include a scraped webpage, a third-party API response, or a file dropped into a repo by someone with no good intentions. Three things make this threat surface structurally different from anything a security team dealt with before agents showed up.

First, runtime code generation from untrusted input gets treated as trusted execution. An LLM's output is just tokens, but the moment those tokens become a shell command or a script, the system treats them the way it would treat code a developer wrote and tested. Second, agents make unpredictable runtime decisions about which APIs to call and when, so static allowlisting of "expected behavior" doesn't hold, because there often isn't a fixed set of expected behaviors to enumerate. Third, stateful memory systems that persist across sessions create a manipulation vector that a point-in-time security check will miss entirely: an attacker doesn't need to compromise the current session if a manipulated instruction can sit quietly in memory and get retrieved later.

Research from Palo Alto Networks' Unit 42, cited in a 2026 guide from a coding-agent platform, found that ChatGPT-4o, deployed as an autonomous agent, carried out SQL injection, server-side request forgery, and unauthorized data exfiltration, the same model that, as a plain chatbot, consistently refused those requests. Nothing changed about the model's training. What changed was that it got hands: the ability to act, not just answer.

And the scale keeps climbing. Data cited by iternal.ai shows programming rose from about 11% of all LLM token usage on OpenRouter to over half by late 2025, and it's still the single largest use case on that platform. Inside Anthropic, on the order of 90% of the code written for Claude Code is written by Claude Code itself. This is the current operating condition of a large and fast-growing share of software production, not a hypothetical future risk. It's the current operating condition of a large and fast-growing share of software production, so the question of what an agent can reach over the network is the whole ballgame, not a theoretical footnote.

What an agent sandbox is and where network egress sits within it

A sandbox for a coding agent is five controls working together: network egress (a default-deny policy on outbound connections), filesystem boundaries (a scoped workspace with read-only mounts outside the working directory), process iso... It's five, working together: network egress (a default-deny policy on outbound connections), filesystem boundaries (a scoped workspace with read-only mounts outside the working directory), process isolation (a dedicated kernel or userspace interposition layer), secrets scoping (credentials that never sit in environment variables the agent's process can read), and an ephemeral lifecycle (no state persisting across sessions unless someone opts into it deliberately).

Of the five, egress is the one that decides how bad things get if everything else fails. A process that's contained on disk and isolated at the kernel level but still has an open path to the internet can exfiltrate data, pull down a malicious payload, or phone home to a command-and-control server. Filesystem and process isolation limit what an agent can do locally; egress control limits what it can reach beyond that boundary. A widely cited AI vulnerability scoring framework assigns the interpreter-tool attack scenario a CVSS v4.0 base score of 9.4, a number that puts containment, not just prevention, at the center of the design. You cannot assume prompt injection never succeeds. You have to assume it sometimes will, and design for what happens next.

The incident record backs this up in specifics. CVE-2025-58372, affecting Roo Code, chains a prompt injection into a workspace file write and then arbitrary code execution; third-party aggregators assign it a 9.8 critical score, while the assigning authority lists it at 8.1 high. Separately, a malicious npm package impersonating Postmark's MCP server injected a hidden BCC field into outgoing email tool calls, quietly forwarding a copy of every email the agent sent. That's a network-layer breach start to finish; no filesystem control anywhere in the stack would have caught it. And in an incident documented by researcher Johann Rehberger on embracethered.com, an agent running Claude navigated to a page carrying a hidden prompt injection payload, downloaded a binary from that instruction, executed it, and connected out to a command-and-control server. Every link in that chain depended on one thing: the agent had unrestricted outbound network access. Take that away, and the chain breaks at step one.

Why egress controls must live outside the agent's trust boundary

There's no deterministic, fool-proof defense against prompt injection right now. Every mitigation on the market is probabilistic and layered, a filter here, a classifier there, stacked to reduce the odds rather than eliminate the risk. That has a direct architectural consequence: an egress policy enforced by the agent's own parser, or by logic living inside the same process the agent controls, can be defeated by the exact injection it's supposed to stop. The rule checking the policy and the thing that might be compromised are the same thing, which makes it a suggestion rather than a rule. It's a suggestion, not a rule, because the checker and the thing that might be compromised are the same thing.

Defense in depth means putting the actual enforcement point somewhere lower in the stack, outside the agent's reach: a network namespace enforced beneath the operating system, a forward proxy, or a cloud egress gateway sitting between the sandbox and the open internet. If the matcher lives in the harness process, the matcher is the trust boundary, and one bug there undoes every policy layer stacked on top of it.

NVIDIA's NemoClaw, announced at GTC in March 2026, builds this principle into its architecture directly. The same architectural principle calls for enforcement that runs outside the agent's execution context, The same logic should extend to configuration and spend limits generally: version them, and enforce them, outside the agent's execution context, so the agent operates inside constraints it cannot read, and certainly cannot edit. For engineering teams, deciding where in the stack to put egress enforcement is a security architecture decision, not a tuning knob for latency or cost. It's a security architecture decision, and the right answer is close to always the lowest layer the team actually controls.

The threat scenarios that egress controls specifically close

Cloud metadata access is the first and most mechanical case. Any agent that can reach the instance metadata service at 169.254.169.254 can pull host credentials straight off the box it's running on. A default-deny egress policy with an explicit block on link-local address ranges closes that door without needing a single line of application logic.

The ZombAIs pattern, prompt injection leading to a binary download and a call home to C2, gets closed the same structural way. If the sandbox permits outbound connections only to an approved allowlist, the injected instruction to fetch an external payload simply has nowhere to land, even when the injection itself succeeds.

Query-string exfiltration is trickier, and there's a real gap here. A prompt-injected fetch to a domain that's already on the allowlist can still encode sensitive data in the URL's query parameters, smuggling it out through a channel the allowlist was never built to inspect. Domain allowlisting alone doesn't close this. It requires a separate layer, something inspecting outbound content or gating what counts as a legitimate public-web request, and any team relying on allowlisting as a complete exfiltration defense is leaving this gap open.

Credential leakage through environment variables is a distinct failure mode. Credentials passed into a sandbox as environment variables are readable by any process running inside that sandbox, agent included. A compromised agent with open egress can simply POST those credentials to an external endpoint. The fix needs two parts working together: inject credentials at the network proxy layer instead of the environment, and filter egress so unapproved destinations can't be reached even if a credential somehow leaks anyway.

Bandwidth is its own quiet channel. Rate-limiting outbound traffic volume and watching for unusual transfer patterns catches something domain-based rules miss entirely: a large transfer to a destination that's fully approved is still worth a flag in the audit log, because volume itself can be the signal.

Enforcing default-deny logic at the HTTP layer adds latency, but the overhead is generally considered small enough to ship in production. The principle is well-established: placing the enforcement point at the network layer, outside the agent's own logic, is what makes the policy meaningful.

How isolation technology choices constrain what egress enforcement is even possible

An egress policy is only as trustworthy as the isolation boundary it's enforced inside of. Standard containers share the host's kernel, which means a kernel vulnerability or a container-runtime bug can let a process escape the container entirely, before any egress rule ever gets consulted. CVE-2024-21626, nicknamed Leaky Vessels, is the concrete case: in versions of runc up to 1.1.11, a crafted Dockerfile could set a WORKDIR pointing through a /proc/self/fd path back to the host filesystem, giving an attacker a route out onto the host itself. Once a process is out of the container, it's talking to the host's network stack directly, and whatever egress policy was configured inside the container's namespace is simply irrelevant. The wall it was supposed to enforce is gone.

A benchmark called SandboxEscapeBench, published by a UK government AI safety research body in March 2026 and accepted at ICML 2026, measures how well frontier LLM agents can break out of a sandbox under conditions that plausibly occur in real deployed systems. They can, under realistic vulnerability conditions, and the pace of improvement is the real story here. A model referred to in the paper as Claude Mythos Preview saturated the original benchmark within two months of its publication, fast enough that the benchmark's original scope quickly became insufficient to measure continued progress. Separately, success rates on apprentice-level cybersecurity tasks climbed from under 10% in late 2023 and early 2024 to roughly 50% by 2025. Sandbox designs calibrated to what models could do even a year earlier are already behind the curve.

Not every isolation technology gives egress enforcement the same footing. Hardened containers put the egress policy inside the container's network namespace, and a kernel-level escape bypasses it, which makes this tier appropriate mainly for workloads a team already trusts. gVisor intercepts syscalls to shrink the kernel attack surface and can enforce egress via netfilter inside its sentry process, stronger than a plain container but still short of hardware isolation. Firecracker microVMs give each workload its own dedicated kernel, boot in roughly 125 milliseconds, run under 5 MiB of overhead per VM, and can spin up as many as 150 VMs per second on a single host, according to figures cited by Northflank; because the egress policy is enforced at the VMM or host network layer, it's fully external to whatever is running inside the guest. Kata Containers reach that same hardware-level isolation while keeping standard container APIs, with a boot time around 200 milliseconds. Northflank reports running over two million isolated workloads a month on gVisor and Kata Containers combined.

The takeaway for anyone designing this stack: only hardware-level isolation, a microVM or its equivalent, makes platform-layer egress enforcement meaningful independent of what the agent itself does. One pattern runs two isolation tiers side by side, containers for workloads that need GPU access (treating that tier as the weaker boundary it is) and microVMs for everything needing full isolation, with the container tier getting extra monitoring specifically to make up for the gap. Egress policy doesn't need to be identical across both. It needs to match the actual strength of the wall behind it.

Designing an egress policy: allowlisting and denylist layers

Start from zero trust: every outbound connection blocked by default, and every permitted destination enumerated explicitly. That's the baseline, and 169.254.169.254 gets blocked outright, non-negotiable, regardless of anything else on the allowlist.

Build the allowlist from what the agent's actual task requires: package registries, specific APIs, version control hosts, the concrete list of things this workload touches, not a guess at what seems broadly harmless. Wildcard domain matching has its place, and some implementations use it, but scope any wildcard to the narrowest subdomain tree that actually covers the need. CIDR-based rules make more sense for infrastructure with stable IP ranges, and workloads that need to sit on the other side of a third party's firewall will need a static egress IP to be allowlisted against in the first place.

Denials should sit above allowlist wildcards, not below them: an explicit deny for a specific destination has to win over a broader allow rule that happens to match it too, otherwise the wildcard swallows the exception it was supposed to respect.

Query-string exfiltration deserves a second mention here, because it's the case teams most often assume is solved when it isn't. Domain allowlisting stops an agent from reaching a new destination; it does nothing to stop a prompt-injected request to an already-approved destination from carrying stolen data in its URL parameters. Closing that gap takes a separate layer, content inspection on outbound requests or a gate on what counts as a legitimate public-web fetch, and it belongs in the threat model as an acknowledged residual risk, not a solved problem.

Bandwidth limits work as a complementary layer on top of all of this, rate-limiting outbound volume, not just destination, and treating an unusually large transfer to an allowlisted destination as a logged event worth a human glance, even when nothing about the destination itself is wrong.

Daytona's model for secrets is worth studying because it ties two controls together elegantly. Secrets sit as placeholders inside the sandbox and only get swapped in for the real value during an outbound HTTPS request, and only when the destination matches the host allowlist; a request to anywhere else keeps the placeholder text, unchanged, and the real secret never enters the sandboxed environment at all. That means the egress allowlist and the secrets policy are, functionally, the same list: a destination that isn't on it neither receives a real credential nor is reachable in the first place, one rule set doing two jobs.

Vercel's sandbox egress firewall reached its Hobby (free) tier on August 5, 2026, a small but telling signal that egress filtering is drifting out of enterprise-only territory and into standard platform infrastructure that any team can turn on. For teams still running on containers rather than microVMs, a reasonable hardened baseline starts with --network none and re-attaches network access only into explicitly controlled namespaces, paired with --cap-drop ALL, --read-only, and --no-new-privileges. None of that replaces hardware isolation. It's a floor, not a ceiling.

What managed sandbox platforms enforce natively versus what teams must build themselves

Ask a sandbox vendor, in a procurement questionnaire, which static IPs to allowlist and how API keys are kept out of the code-execution environment, and the honest answer from most platforms today involves a proxy VM and a DNS setup the operator has to run themselves. Credentials, in a lot of these setups, still pass in as environment variables that any process inside the sandbox can read. That gap is the practical difference between a sandbox that's good for running untrusted code in a demo and one that's actually built to hold up against a motivated attacker with a prompt injection in hand.

Evaluating any platform against that gap comes down to a short list of concrete questions, not marketing language: does egress enforcement happen outside the agent's own process, at a layer the agent cannot read or modify? Is the underlying isolation hardware-based, a microVM or equivalent, rather than a shared-kernel container? Are secrets injected at the proxy layer instead of the environment? Is there a default-deny posture out of the box, or does the operator have to build that from scratch? Does the platform expose bandwidth and destination monitoring as a first-class feature rather than something bolted on after an incident? The platforms that answer yes across the board are treating egress as infrastructure. The ones that don't are leaving that infrastructure for the team to build, and that team needs to know it's on the hook before the first incident makes the gap obvious.