Are domain allow-lists enough? How AI agent egress control really works

01What does egress control mean for an AI agent?

Egress is traffic leaving the agent's environment. Egress control is a rule about that traffic, and for agents the sensible default is deny: nothing leaves unless it is going to a destination you named. That rule can be enforced at three different layers, and they see very different things.

Most real setups combine two or three of these. The rest of this post is about what each layer can and cannot see, because the gaps between them are where data leaves.

• Address rules: a firewall that allows a list of IP addresses, usually filled in by resolving the allowed names. Anthropic's reference devcontainer firewall works this way.
• DNS filtering: the agent's name lookups are answered only for allowed names, so other names never resolve.
• A proxy: the agent's HTTP and HTTPS traffic goes through a proxy that reads the requested host name and decides. Claude Code's built-in sandbox and Docker Sandboxes both route traffic through a proxy on the host.

02Why do IP-based allow-lists leak?

An address rule only knows addresses. Once registry.npmjs.org is resolved and its addresses are allowed, the firewall cannot tell a request to the registry from a request to any other site on the same content delivery network address. It also usually allows that address on every port and protocol, not only HTTPS on 443. And addresses resolved once at start go stale when the provider changes them.

The second leak is the rules around the list. Anthropic's reference init-firewall.sh, as published, drops other outbound traffic but allows DNS on UDP port 53 and SSH on TCP port 22 to any destination, so the agent can still talk to any DNS server in the world. That is convenient for development and it is exactly the channel the next section describes.

03How does DNS exfiltration work, and how do you close it?

DNS exfiltration needs no allowed host at all. The agent looks up a name such as <encoded-data>.attacker.example. Its resolver does not know the answer, so it asks the name servers for attacker.example, which the attacker runs, and they log the query. The data has left in the question. MITRE ATT&CK lists DNS as an application-layer protocol adversaries use precisely because it blends into normal traffic, and CVE-2025-55284 in Claude Code was this pattern: auto-approved commands such as ping and dig let an injected agent send a .env file out through lookups.

Closing it takes two steps. First, the sandbox must not be able to reach a resolver of its choosing: lookups are intercepted and answered by something you control. Second, that resolver must refuse names that are not on the list, rather than forwarding them. A wildcard such as *.example.com reopens a small version of the channel, because every name under it is forwarded to that domain's name servers, so only allow wildcards over domains you trust.

Some sandboxes remove the problem by not offering UDP. Claude Code's sandbox documentation says UDP, QUIC and ICMP cannot leave the sandbox, and Docker documents that its Sandboxes block outbound UDP unless an experimental setting is on.

04Proxy vs DNS filtering: what does each one see?

DNS filtering sees a name once, at lookup. After that it sees nothing, and a program that connects to a literal IP address never asks it at all, so it has to be paired with an address rule. A forward proxy sees the host name on every connection, in the CONNECT line for HTTPS or the URL for plain HTTP, which makes its decisions more precise. But unless it terminates TLS, it does not see the method, path or body of an HTTPS request, and it cannot check that the name inside the encrypted connection matches the name it was asked for.

Anthropic's sandboxing documentation spells out the consequence. Its proxy decides from the client-supplied host name without inspecting TLS, so code in the sandbox can potentially use domain fronting or similar techniques to reach hosts outside the allow-list. For stronger isolation it suggests a custom proxy that terminates TLS and inspects traffic, with its CA certificate installed in the sandbox. That buys content visibility at the cost of decrypting everything the agent sends, including credentials, inside your proxy.

05What is allowed-domain exfiltration, and how do you limit it?

This is the hole every allow-list keeps. If the agent can reach a host that accepts data, it can put data there: a gist on GitHub, a comment on an issue, a file in a storage bucket, a request body to any API. MITRE ATT&CK calls it exfiltration over a web service, and it is attractive to attackers because the destination is legitimate. Anthropic's documentation warns specifically that allowing broad domains such as github.com can create paths for data exfiltration, and Docker's notes that its default allowed domains include broad wildcards such as *.googleapis.com.

Nothing at the network layer fully closes this, because the traffic is shaped exactly like legitimate work. What helps is making the list short and specific, and reducing what the agent holds to send.

• Allow exact host names for the APIs the task needs, not whole platforms or wildcards.
• Leave out hosts that accept uploads or user content unless the task needs them.
• Restrict methods and paths where your proxy can see them, which means plain HTTP or credential routes it terminates.
• Keep secrets out of the agent's environment and give it one workspace folder, so there is less to send.

06What does an egress broker add to an allow-list?

An egress broker is a proxy that is also the only way out: the sandbox's address policy is deny, and every request has to name its destination to the broker. That gives you host-level decisions on every request rather than once at lookup, a port limit per host, a check that an allowed name does not resolve to a private or metadata address, and a log of what was allowed as well as what was refused. When the broker also holds API keys, it adds them after the request leaves, so the agent can call an API without being able to read its key.

It does not remove the limits above. HTTPS to an allowed host is still a tunnel the broker carries without opening, programs that ignore proxy settings simply reach nothing, and an allowed host that accepts uploads is still a way out. Treat a broker as the layer that makes the allow-list precise and auditable, then keep the list short.