Egress Firewall Rules for Sandboxed LLM Tool Calls

Egress firewall rules are what actually stop a compromised agent from doing damage. They define exactly which outbound connections a sandboxed tool call gets to make, and they block everything else at the network boundary before a bad call reaches the outside world. That's the short version. Most teams building agents right now haven't even settled the sandboxing question, let alone the network policy sitting inside it, so it's worth slowing down and working through the mechanics: this is the layer that decides whether a prompt injection stays a curiosity or turns into a breach.

What egress filtering actually does at the agent layer, and how it differs from adjacent controls

Four kinds of controls get lumped together in agent security conversations, and pulling them apart matters more than it sounds like it should. Guardrails decide whether text the model produces is fit to show a user. Gateways decide where agent traffic gets routed. Hooks decide whether a tool call runs at all, checking before execution happens. Egress firewalls sit after all of that. They block the outbound network effect of a tool call that already ran.

That ordering is the whole point. An LLM firewall, the kind Radware or Akamai sell, watches the inference API for prompt injection coming in, but it has no view of what the agent does once the model responds. Traditional egress proxies and data loss prevention gateways watch outbound traffic too, but they were built to catch a credit card number leaving a corporate network, not a tool response poisoned mid-session or a tool description quietly altered to steer the model toward a dangerous call. Neither one was built with agents in mind, and it shows.

An agent egress firewall combines outbound traffic filtering with inbound scanning of tool responses and integrity checks on the tools themselves, all at one enforcement point. A CSA, SANS, and OWASP joint briefing on AI vulnerabilities, version 0.4 from April 2026, puts egress filtering first on its list of hardening priorities. The reasoning is almost historical: egress filtering blocked every public exploit of Log4j back when that vulnerability was the internet's biggest headache, because no matter how the exploit got in, it still had to phone home to do anything useful. Agent traffic exfiltrating data works the same way. The compromise happens inside; the damage happens on the way out.

This piece isn't about which vendor's product wraps around this layer. It's about the rules that live inside it, and what those rules actually need to cover.

How MCP has concentrated the attack surface that egress rules must cover

Model Context Protocol is now the standard way agents talk to tools, which means whatever's broken in MCP is a huge chunk of what your egress rules have to defend against. A 2026 audit summarized by Zuplo found that 40% of MCP servers run with no authentication at all, 43% carry command-injection vulnerabilities, and 79% handle credentials in plaintext. Separately, Endor Labs looked at more than 2,600 MCP implementations and found 82% used file operations prone to path traversal, 67% used APIs tied to code injection, and 34% used APIs susceptible to command injection outright. This isn't a handful of edge cases somebody forgot to patch. It's the plumbing most agent deployments run on, every day, right now.

A handful of attack patterns show up over and over, and each one matters because each one produces something an egress rule can actually catch. Tool poisoning hides malicious instructions inside a tool's own metadata, hijacking the model before the user does anything at all; Invariant Labs demonstrated this with a poisoned math tool that read SSH keys off the host and encoded them inside a math function's parameter, no user interaction required. Server-side request forgery through tool-supplied URLs is another pattern: a connector that accepts arbitrary URLs turns into a way to probe internal endpoints or cloud metadata services. Tool description poisoning changes what the model believes a tool does without changing what the tool actually does. Tool rug-pulls happen when a tool's behavior changes mid-session, something most session-level checks miss because they only look once, at the start. And supply-chain injection is real too; CVE-2025-49596, found in MCP Inspector, showed a crafted webpage triggering remote code execution through a developer utility nobody thought to treat as an attack surface.

The Vulnerable MCP Project was tracking more than 50 known MCP vulnerabilities as of April 2026, a notable share rated critical, including a remote code execution chain found in Anthropic's own mcp-server-git. Even the people building the protocol aren't immune to bugs in their own reference implementations. Sit with that for a second.

What makes rule design tractable is that every one of these vectors ends in an outbound network request. The injected command still has to call out somewhere. The SSRF request still has to reach the metadata service. The exfiltrated data still has to leave, even hidden inside a parameter that looks innocent on its face. A tightly scoped egress allowlist stops the damage at that last step, even after the tool call already ran and the injection already worked. That's the leverage point, and it's the reason this layer gets so much attention from people who've had to clean up after one of these.

Why running agent tool calls inside a sandbox is the prerequisite that makes egress rules meaningful

None of this works if the tool call runs directly on a machine you care about. Egress rules assume there's a boundary to enforce them at, and that boundary has to come from a sandbox. Full stop.

The 2025 Veracode report found 45% of AI-generated code fails basic security tests. That's nearly half the code an agent might write and then immediately try to run as a tool call. OWASP's Agentic AI Top 10, published December 2025, lists unexpected code execution as a top-tier risk, category ASI05, and its guidance is blunt about it: never run agent-generated code without strict sandboxing, input validation, and allowlisting together, because they're not really separable in practice.

The clearest demonstration of what happens without a sandbox is the ZombAIs incident involving Anthropic's Claude Computer Use beta. A hidden prompt injection sitting on a webpage caused Claude to download a binary, mark it executable, run it, and connect out to a command-and-control server. No user clicked anything, and it worked on the first attempt. That's not a hypothetical risk model. It's a documented chain from webpage to host compromise, with the agent playing the unwitting middleman the whole way through.

Don't Docker containers already solve this? Fair question, and the answer is not really, for architectural reasons. Containers share the host kernel, so an agent running in a permissive container can, under the right conditions, escape to the host underneath it. By default, containers also have wide-open egress, reaching the full internet and often the local network without anyone configuring a thing. The isolation people assume containers provide on the network side just isn't there out of the box.

There's a real hierarchy in how seriously teams end up taking this. Standard containers are fine only for low-trust, well-understood calls where teams layer egress rules on top explicitly. gVisor intercepts system calls and shrinks the kernel's attack surface without the overhead of a full virtual machine. Firecracker microVMs and Kata Containers go further, putting an actual hardware boundary between the agent and the host, ruling out entire categories of kernel-based escape. For production agent workloads handling more than one tenant, that hardware boundary is close to a consensus requirement now, not a nice-to-have.

Recent CVEs back this up plainly. CVE-2025-59528 and the Antigravity sandbox escape, CVE-2025-59536, both show unsandboxed agent execution reaching the host. OWASP, NVIDIA, and Microsoft have landed on the same pairing independently: kernel-level isolation plus network egress allowlists, together, as the control that holds up under pressure. The sandbox draws the boundary; egress rules decide what's allowed to cross it. Neither does much good without the other, which is why the rest of this piece treats them as one problem instead of two.

Designing egress rules that match the actual trust model of a tool-calling agent

Start from deny-all, then open specific holes one at a time. That's the opposite of how most corporate networks get built, where the default is permissive and security teams spend entire careers trying to close things off after the fact. For untrusted, autonomous code, the inversion is the whole point: nothing gets out unless someone explicitly said it could.

Each rule needs to specify a few things concretely, no vagueness allowed. The destination should be a fully qualified domain or a defined IP range, never a wildcard, never "the internet" as a category. Protocol and port matter too; HTTPS to port 443 for one specific API is a very different risk than open TCP to anywhere on the map. Direction should be egress-only for tool calls, since an agent has no legitimate business receiving inbound connections it didn't ask for. Duration should be scoped to the session or the task at hand, not left open as some standing rule nobody remembers granting six months later.

Some ranges need to stay blocked no matter what a tool claims it needs. The RFC 1918 private ranges(10.x, 172.16 through 172.31.x, and 192.168.x) need to stay closed to prevent SSRF into internal infrastructure. Cloud metadata endpoints, 169.254.169.254 and its equivalents on other clouds, need to be blocked by default, because that's the exact path Sonrai used to demonstrate credential extraction against AWS AgentCore. Localhost and loopback addresses need closing off too, so a tool call can't reach sideways into another process running on the same host.

DNS deserves more attention than it usually gets. It's not just a lookup mechanism, it's a control surface in its own right, and a lot of teams miss that. Agents should resolve names through a controlled resolver, not whatever nameserver happens to be configured on the box. DNS-over-HTTPS to unconfigured resolvers should be blocked outright, since it slides right past traditional DNS filtering without anyone noticing. DNS-based exfiltration, where attackers encode data into subdomains of a domain they control, is a documented, working technique, not a theoretical one; BeyondTrust demonstrated exactly this gap in AWS AgentCore's default network mode.

Allowlists should live at the tool level, not the agent level. A weather API tool has no reason to inherit the same network permissions as a database tool running in the same session. Treating them as one undifferentiated agent identity throws away a useful boundary for basically no benefit.

One more thing worth building in from day one: any tool call with an irreversible network side effect (sending an email, posting to an external API, firing a webhook) should require a human to confirm before the egress rule lets it through. This lines up with what the broader MCP security community has been recommending for sensitive or irreversible actions, and it costs very little friction if scoped narrowly.

On authentication, use OAuth 2.1 with mandatory PKCE for tool access, and check the token's audience so a token minted for one tool can't get replayed against another. Never pass a client's token straight through to an upstream API either, no matter how tempting the shortcut looks. These sound like protocol details, and they are, but egress filtering is what actually enforces them in practice: a request without the right credentials gets rejected at the boundary, no matter what the agent thought it was doing.

Operationalizing egress rules across sessions, snapshots, and long-running agent work

Agents don't always run start to finish in one sitting. Many checkpoint mid-task, pause, and resume later, sometimes on different hardware entirely, and the egress rules attached to that agent need to survive the trip intact. If those rules only live inside the running process, they vanish the moment a snapshot tears the process down. The agent could come back online with no restrictions at all, and nobody would necessarily notice right away.

The fix is to store egress policy at the sandbox configuration layer, separate from the agent's own process state, so it survives being paused, snapshotted, migrated, and restored. On restore, the enforcement layer needs to reapply those rules before the agent process makes a single outbound connection, not after. And if the permitted destinations for a tool changed since the snapshot was taken, the restored sandbox should pick up the current policy rather than resurrect a stale one frozen at whatever moment the snapshot happened to catch it.

Long-running agents build up a lot of tool-call history. Logging every outbound attempt, allowed or denied, is really the only way to reconstruct what happened later if something looks off. Each log entry should carry the timestamp, the sandbox ID, the tool name, the destination, the protocol and port, the verdict, and which rule matched it. Denied attempts matter just as much as allowed ones here, maybe more: a sudden spike in denied requests toward private IP ranges is a pretty reliable sign of SSRF probing, or of a tool that's already been compromised and is testing its leash.

As agent workloads scale, evaluating rules per sandbox starts to become a real throughput bottleneck. The better approach pushes enforcement down to the hypervisor or network layer instead of running it inside the sandbox process itself, keeping the enforcement mechanism outside the same attack surface it's supposed to be protecting, while still holding up under load.

Daytona's architecture is a good example of this working in practice. Its sandboxes keep filesystem state, environment variables, and process state persistent across interactions, provision in under 90 milliseconds, and apply egress policy at the infrastructure layer rather than inside the agent's own runtime. That design choice matches the requirement above almost exactly: rules need to outlive the agent's current session, not just its current process. Anthropic's own Sandbox Runtime takes a similar approach, pairing Seatbelt or bubblewrap for isolation with a network-filtering proxy for outbound control in one tool. Isolation and egress filtering, handled together, at the same layer, by design rather than by accident.

What "sandboxed" actually guarantees when a vendor claims it — and what to ask

AWS AgentCore is worth sitting with for a minute, because it shows how a vendor can be technically accurate and still leave a real gap open. BeyondTrust found that AgentCore's default sandbox network mode allowed DNS-based exfiltration and command-and-control communication straight through, no extra work required on an attacker's part. Sonrai separately showed credential extraction via the metadata service, the same 169.254.169.254 endpoint mentioned earlier. AWS's response was to call the network behavior intentional and publish hardening guidance, rather than treat it as a bug needing a patch. So was AgentCore actually sandboxed? At the isolation layer, yes. At the egress layer, not by default, and that gap is exactly what a lot of teams miss when they read "sandboxed" on a product page and assume it covers everything underneath it.

"Sandboxed" turns out to be a spectrum, not a checkbox you either have or don't. A few questions separate a real answer from marketing copy. What's the default egress posture, deny-all or permit-all? Are cloud metadata endpoints blocked out of the box, or only if someone remembers to configure it themselves? Does egress policy live at the infrastructure layer, where it survives a snapshot, or inside the agent process, where it doesn't survive anything? Can you scope rules per tool, or only per sandbox as one undivided whole? Is there an audit log of denied connections specifically, not just a record of what got through?

The platforms in this space answer those questions differently, and the differences matter. Daytona builds specifically for AI agent workloads, with cold starts under 90 milliseconds and a stateful design where filesystem, environment, and process state persist by default. It runs Docker-native with a microVM option, carries SOC 2, HIPAA, and GDPR compliance, and runs on infrastructure the customer controls in their own cloud rather than a black box you're asked to trust blindly, since the platform is open-source and auditable end to end. For teams that need egress policy to survive an agent's snapshot and restore cycle, and need real compliance evidence to hand an auditor, that combination is hard to overlook.

Northflank runs on Kata Containers and gVisor isolation, handles more than 2 million isolated workloads a month, and supports bring-your-own-cloud deployment, which suits teams wanting microVM-grade isolation as the default rather than something bolted on after the fact. Google's Agent Sandbox is an open-source CNCF project, launched at KubeCon North America 2025, offering a declarative API for stateful, isolated sandbox pods running on a cluster you already operate. That fits teams already deep in Kubernetes who want to manage egress through networking controls they already know. microsandbox, an open-source project out of the Y Combinator X26 batch, is self-hosted and uses libkrun for hardware-level microVM isolation, with startup times under 200 milliseconds and around 3,300 GitHub stars since launching in May 2025. It's built for teams that want full control and are willing to run their own infrastructure to get it. AWS AgentCore itself is managed, bills per second, and integrates with CloudTrail for audit logging, though as the case above shows, it needs explicit configuration to close egress gaps that don't close themselves by default.

None of these are wrong choices, exactly. They just answer the "what does sandboxed actually mean here" question in different ways, and that's the question worth asking before the tool call runs, not after you're reading an incident report about the one that didn't.