Egress Control: The 7 Hidden Paths Out of Your Agent

There is one structural argument for this control, and it is worth stating precisely because everything else follows from it.

Input filtering must recognize the attack. Egress control does not.

A classifier watching for injection has to identify a payload it has never seen, phrased in a way its training did not anticipate, possibly in a language or encoding it does not handle well. Attackers iterate against it directly.

A blocked outbound request does not care. It fails whether the injection was a crude override instruction or an elegantly camouflaged paragraph of domain-appropriate prose. The control operates on what the attack was trying to accomplish rather than how it was written.

That property is rare in security, and it is why egress control keeps appearing at the top of practitioner recommendations rather than in the middle of a checklist.

The taxonomy of what you are defending against — eight distinct injection classes, only one of which arrives through the input box — is covered in prompt injection classes and what stops each.

Key Takeaways

• Egress control is the only prompt injection defence that works without recognising the attack. Input filters must identify a payload; a blocked outbound request fails regardless of how clever the injection was.
• Most implementations block one channel and call it done. There are at least seven, and the commonly-open ones include DNS, markdown image rendering, and query strings to allowlisted domains.
• Amazon Bedrock AgentCore’s Code Interpreter sandbox mode permitted unrestricted outbound DNS despite isolation claims, enabling bidirectional covert command-and-control, with no patch available as of March 2026.
• Markdown image exfiltration needs no tool call at all. The render is the attack, and it happens in the user’s browser rather than the agent’s sandbox.
• Egress control does not defeat destructive writes, fraudulent transactions, or misinformation. Those never leave the building.

---

Quick Navigation

---

The Lethal Trifecta and Which Leg to Cut

Simon Willison’s framing from June 2025 has become the field’s standard screening test, and it holds up.

An agent becomes an exfiltration weapon when three properties coexist:

1. Access to private data
2. Exposure to untrusted content
3. An ability to communicate externally

Each is individually benign. A system with all three can be turned by a single injected instruction.

Remove any one and the chain breaks. The question is which one you can actually remove.

Private data access is usually the point of the agent. Take it away and the product stops being useful.

Untrusted content exposure is also usually the point. An agent that reads email, browses the web, or processes documents is exposed by design.

External communication is the leg that most often turns out to be incidental. Many agents have network reach because containers have network reach by default, not because the task requires it.

Willison’s own conclusion is that removing the exfiltration ability is the preferred cut. That is the correct instinct — and the rest of this article is about why “block egress” is considerably harder than it sounds.

---

The 7 Exfiltration Paths Egress Control Must Cover

Here is the inventory. Most implementations cover the first two and stop.

#	Channel	Typically blocked?
1	Direct HTTP from agent tool calls	Usually
2	Non-allowlisted domains	Usually
3	Query strings to allowlisted domains	Rarely
4	Markdown and HTML image rendering	Rarely
5	DNS queries	Rarely
6	Redirect chains through trusted domains	Rarely
7	Non-harness subprocesses and raw sockets	Rarely

The gap between rows 2 and 3 is where most real incidents live. A team adds a domain allowlist, tests that attacker.com is blocked, and reasonably concludes egress is controlled.

It is not. Five channels remain open, and several of them do not pass through the agent’s network stack at all.

---

Egress Control Channels Most Teams Block

The first two are worth covering briefly because they are the baseline, and because the standard configuration has known gaps.

Channel 1 —Direct HTTP from tool calls. The agent invokes a fetch or HTTP tool with an attacker-supplied URL. A default-deny policy with a task-specific allowlist handles this.

The standard pattern also blocks private ranges to prevent lateral movement, and specifically blocks the cloud metadata endpoint at 169.254.169.254, which is a favored credential-theft target.

Channel 2 — Non-allowlisted domains. Same mechanism, and the place where implementation detail matters more than teams expect.

Wildcard allowlists are the common failure. A policy permitting *.google.com has been bypassed by a hostname structured as attacker-host.com\x00.google.com — the null byte causes the sandbox’s parser and the resolver to disagree about where the hostname ends.

Two rules follow. Prefer exact hostnames over wildcards. And place enforcement below the agent harness — at an OS-level network namespace or a forward proxy at the container boundary — because a policy enforced inside the harness only covers tools the harness mediates. This is layer two of the four-layer model in sandbox isolation and the layers that contain failure.

---

Egress Control Channels Most Teams Miss

These five are where the work actually is.

Channel 3 — Query strings to allowlisted domains. The allowlist decides whether a request reaches a destination. It says nothing about what the request carries.

A prompt-injected fetch of a legitimate allowlisted target still encodes user data in the URL path or query string. If the attacker controls any page on an allowlisted domain, or can read that domain’s access logs, the data has left.

Channel 4 — Markdown and HTML image rendering. This is the one that surprises people most, because it bypasses the agent’s network stack entirely.

The agent emits a markdown image reference with sensitive data base64-encoded into the URL. The chat interface renders it. The user’s browser makes the GET request. Data arrives at the attacker’s server.

No tool call. No MCP server. No registered capability. The render is the attack. Your agent sandbox can be perfectly sealed and this channel still works, because the request originates from the client.

The variants worth testing are broader than markdown images: HTML img tags, CSS background-image, HTML5 media elements, hyperlinks with auto-preview, iframes and video. NVIDIA’s garak includes an XSS probe family covering these.

Channel 5 — DNS. Even a strict HTTP allowlist usually permits DNS resolution, because without it nothing works.

Researchers at BeyondTrust’s Phantom Labs demonstrated that Amazon Bedrock AgentCore Code Interpreter’s Sandbox network mode permitted unrestricted outbound DNS queries despite documentation describing complete isolation. The result was a fully bidirectional covert command-and-control channel capable of exfiltrating S3 contents, Secrets Manager credentials, PII and financial data. No patch was available as of March 2026.

DNS tunnelling is decades old. What is new is agent platforms marketing network isolation while leaving it open.

Channel 6 — Redirect chains. A static allowlist checks the first hostname. A trusted domain that returns a 3xx redirect to an attacker-controlled host bypasses the check unless the agent refuses to follow redirects.

Channel 7 — Non-harness subprocesses. An egress policy implemented in the agent framework covers tools the framework mediates. A subprocess that opens a raw socket or bundles its own HTTP client goes around it.

This connects to a related failure worth naming: allowlisted commands can be execution primitives. CVE-2026-22708, disclosed against Cursor, let an attacker poison the execution environment so that allowlisted commands such as git branch delivered arbitrary payloads. Separately, git -c core.hooksPath= or a git alias configured to shell out turns a git-only allowlist into arbitrary code execution.

As one analysis of that class put it, the allowlist made the attack easier rather than harder, because it auto-approved precisely the commands the attacker needed.

---

Where Egress Control Fails in Practice

Beyond the seven channels, three structural limits deserve honest treatment.

Covert channels below the URL layer. Academic work on agent egress reference monitors catalogues carriers that no domain allowlist addresses: data hidden in HTTP headers to allowlisted endpoints, timing side channels, least-significant-bit encoding in generated images, and audio-band encoding in synthesized speech. These are low-bandwidth and impractical for bulk theft. They are entirely adequate for credentials.

Enforcement placed above the sandbox. A domain-allowlisted network proxy is only as good as the isolation beneath it. One disclosed 2026 case chained a DLL sideloading issue with an undocumented flag to escape a Windows agent sandbox that ran an isolated VM with per-session unprivileged users, seccomp filtering, and exactly such a proxy. The proxy was correct; the boundary under it was not.

TLS inspection is expensive and brittle. Inspecting request contents rather than just destinations requires terminating TLS, which is operationally costly and fails in ways that are difficult to debug.

The practical conclusion is not that egress control fails. It is that a single-layer domain allowlist is a starting point rather than a solution.

---

What Egress Control Does Not Defeat

This is the qualification the headline claim needs, and skipping it would be dishonest.

The lethal trifecta models prompt-injection-driven exfiltration. It does not model the whole of agent security. Several serious outcomes never require anything to leave the building.

Destructive writes. An injected instruction that deletes records, drops a table, or corrupts a dataset is fully executed inside your perimeter. Egress control is irrelevant.

Fraudulent transactions. An agent with payment or transfer authority, redirected to move funds within permitted systems, is using authorized paths for an unauthorized purpose.

Misinformation to the user. An injection that causes the agent to give a false answer, misrepresent a document, or recommend a harmful action has already achieved its goal at the point of output.

Lateral movement inside the network. Blocking outbound internet does not stop an agent reaching internal services it should not touch. That requires network segmentation, not egress filtering.

Confused deputy against internal systems. An injected agent invoking a privileged internal tool on the attacker’s behalf never crosses the perimeter.

There is also a deeper point about why scope alone does not save you. In documented cases, the agent had permission for every individual step — reading the document, reading the customer data, making an outbound request. Grant that it needed each permission for its actual job and the attack still works, because it misuses paths the agent was right to have.

The breach came from the path the data took on the way out, not from excess access. That is the strongest argument for egress control and simultaneously the clearest statement of its scope.

---

The Real Cost of Egress Control

Strict egress allowlisting conflicts directly with agent utility, and pretending otherwise leads to policies that get disabled in week three.

Research and browsing agents cannot work through a tight allowlist. An agent whose job is to investigate arbitrary topics needs to reach arbitrary domains. You can restrict it to a curated index, and you have then built a different product.

Every new integration is allowlist maintenance. Scaling that across a fleet of agents is real operational overhead, and the pressure to add wildcards to reduce it is exactly how *.google.com policies happen.

Network controls fail in hard-to-debug ways. An agent that silently cannot reach a dependency produces confusing failures that look like model errors.

Two mitigations make this tractable.

Sealed tool endpoints. Rather than letting the agent author network calls, give it functions. A broker process holds the credential, makes the actual call against a fixed schema, enforces a per-tool egress allowlist, and returns only the parsed response. The agent never composes a URL, so URL-based exfiltration channels close structurally.

Trust-on-first-use secret binding. Rather than curating an allowlist manually, bind hashed secrets or canary tokens to the endpoints where they were first legitimately used, then alert and block on deviation. This removes most of the manual curation burden — and it depends on each agent having a distinct, traceable identity, as set out in why shared credentials are the real exposure.

---

How to Verify Egress Control Actually Works

Configuration is not verification, and the gap between them accounts for a striking share of documented failures.

Consider the pattern in the disclosed lab containment incidents of mid-2026. Environments documented as isolated were not. Prompts told models there was no internet access while the network stack said otherwise. In one case a model spent substantial effort searching for a route out and found one through infrastructure nobody had classified as an egress path.

Nobody had tested the claim. They had written it down.

Four tests, each doable in under a day.

Attempt egress from inside. Open a shell in your agent’s runtime and try to reach the internet by every method available — HTTP to an arbitrary host, DNS lookup of a domain you control, a raw socket. Anything that succeeds is a channel.

Use a canary domain with logging. Register a host, point it at a logging endpoint, and inject a benign instruction into a document your agent processes telling it to fetch that host with a marker string. If your access log records a hit, the path is open.

Test the render surface separately. As described above, generate each image-tag variant with unique URLs. This test exercises the client, not the agent, and it is the one teams skip because it does not feel like a network control.

Enumerate what counts as egress. Package installation is egress. A build step pulling from a registry is egress. A proxy cache is egress. In documented incidents, package registries were the exit route, not an oversight in the firewall.

Two operational notes make verification durable rather than a one-off. Instrument denied attempts and treat them as a signal, because a permissive configuration produces silence and silence reads as safety. And re-test after every dependency or infrastructure change, since egress paths are usually inherited rather than chosen.

The standard to hold yourself to: you should be able to state which of the seven channels are closed, how each is enforced, and when each was last tested. Anything less is a documented intention.

---

Building Egress Control That Holds

Seven steps, ordered by leverage.

1. Default deny, then allowlist exact hostnames. No wildcards. Block private ranges and the cloud metadata endpoint explicitly.
2. Enforce below the harness. OS-level network namespaces or a forward proxy at the container boundary. A policy inside the framework misses subprocesses.
3. Proxy every image URL in agent output. Rewrite to your own proxy with an allowlist, or strip. This is the pattern most production AI products converge on, and it closes the render channel.
4. Add a Content Security Policy with an img-src allowlist at the rendering layer as a second control on the same channel.
5. Restrict DNS. Route through a controlled resolver, log queries, and alert on high-entropy or high-volume lookups. Do not assume a sandbox blocks DNS because it claims isolation.
6. Refuse redirects on agent-initiated fetches, or re-validate the destination after each hop.
7. Test your own product for the render channel. Generate output containing each variant — markdown image, HTML img, CSS background, media elements, hyperlink autopreview, iframe — with unique URLs pointing at a host you control, render each surface, and watch your access log. Anything that arrives is an open channel.

That last step takes an afternoon and routinely finds something.

---

Primary sources

• Simon Willison — The lethal trifecta for AI agents
• Cloud Security Alliance — AI sandbox DNS exfiltration research note
• OWASP Top 10 for LLM Applications
• NVIDIA garak XSS probe family

Channel coverage assessments reflect commonly observed configurations rather than measured survey data. Verify each channel against your own deployment.

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.