Is an egress allowlist realistic for an agent that browses the web?

Yes, if you constrain the shape rather than the set. Permit wide GET traffic through a proxy that forbids request bodies and caps sizes: the agent can read broadly while having no channel wide enough to write out what it read.

Does DNS need to be on the list?

It does. A resolver the agent can query freely is an exfiltration channel — data encoded into subdomain lookups leaves without a single HTTP request. Route DNS through the same policy.

We already have least-privilege tools. Is this redundant?

No; they cover different halves. Least privilege bounds what the agent can do, egress control bounds where what it already read can go. A read-only agent with open egress can still leak everything it can read.

Safety & oversightUpdated 2026-08-25 · Version 1.1

Egress Allowlist

Restrict where an agent's traffic is allowed to go. Data theft and injection payload delivery both end in an outbound request, so a default-deny list of permitted destinations is the control that still works after every other one has failed.

Evidence: Industry observationConfidence: HighSource: Industry observationSource: Personal experienceSource: Paper

Machine-readable: JSON

Definition

An egress allowlist is a network- or sandbox-level policy that permits an agent's outbound requests only to an explicitly named set of destinations and denies everything else by default, so data cannot leave to an attacker-chosen endpoint even when the agent has been fully hijacked.

Problem

Every exfiltration path ends in an outbound request. An agent that can reach arbitrary hosts can be instructed to send anything it has read to any address, and no prompt-level instruction prevents that.

When to use it

Use it wherever an agent both processes untrusted content and can make network requests — fetching pages, calling tools, rendering images, running generated code. The pattern is most valuable exactly where injection is most likely.

Solution

Default deny. The allowlist is the only way out; anything not named is refused, and the refusal is logged as a signal rather than swallowed as an error.

Enumerate destinations from the task: the APIs the agent must call, the domains it must fetch, the registries it must install from — each with an owner and a written reason.

Enforce below the agent. Put the policy in the sandbox, the proxy or the network, never in tool code the model can be argued out of. A rule the agent can talk its way past is documentation, not a control.

Close the quiet channels. Rendered image URLs, link previews, DNS lookups, webhooks, error reporters and package installs are all egress, and all of them get used.

Allow hosts you can reason about. A wildcard over a host that serves user-supplied content — a raw-file CDN, a paste site, a public object store — is an open channel wearing an allowlist's clothes.

Derive the list from measurement and re-derive it when the task changes. Start from what the agent actually calls, not from what someone assumes it calls.

Components

An egress gateway or sandbox network policy that all traffic must traverse.A deny-by-default rule with an explicit, owned destination inventory.Per-role policies, so a research agent and a deployment agent do not share one list.Denial logging wired to alerting, because a denial is a high-signal event.Method and payload constraints where the destination alone is not enough (GET-only, body size caps).A review cadence that removes destinations nothing has used.

Benefits

Bounds exfiltration even after a complete compromise of the agent's reasoning.
Makes attempts visible: a denied destination is one of the few unambiguous attack signals an agent stack produces.
Model-independent — it keeps working across model swaps, prompt changes and framework migrations.
Cheap to extend once the gateway exists; each new agent inherits the enforcement point.

Risks

The allowlisted relay: a permitted host that itself forwards data onward turns the allowlist into a formality.
Breakage when a legitimate dependency moves host, which creates pressure to widen the list under time pressure.
Wildcard erosion: each broad entry added 'temporarily' is permanent until someone audits it.
Enforcement at the wrong layer — an in-process check the generated code can simply bypass.

When not to use it

Fully offline agents, where there is no egress to constrain and the control would be theatre.
When the design already permits exactly one destination, so the allowlist is a property of the architecture rather than a policy to add.
When a corporate proxy already enforces the same policy and a second list would split ownership without adding a constraint.

Technologies

Egress proxiesContainer network policiesService mesh policyDNS filteringDenial logging and alerting

Examples

A coding agent in a container whose egress policy names the package registry and the internal Git host and nothing else. An injected instruction to POST the repository to an external collector fails at the network layer and shows up as a denial.
A research agent allowed to fetch widely but forced through a proxy that permits GET only and caps outbound bodies — able to read the web without having a channel to write to it.
The stdio package published for this knowledge base: its only outbound destination is the public endpoint it proxies, so the allowlist is a property of the design rather than a policy layered on afterwards.

KPIs

Denied egress attempts: The signal the pattern exists to produce. A sustained rise is either an attack or a task that outgrew its list — both worth knowing.
Allowlist size: Destinations permitted per agent role. Growth without removals is the list decaying toward 'allow all'.
Wildcard entries: Count of broad entries. Every one is a channel you cannot reason about; the target is zero.
Time from denial to triage: How long a denial waits before a human looks. An unread denial is an alert you do not actually have.

Observed failure modes

The allowlisted relay: an approved host that will forward whatever it is given, so the destination check passes and the data still leaves.
Wildcard erosion: temporary broad entries that outlive the reason they were added.
In-process enforcement: the check lives where the generated code runs, so the code can skip it.
Silent denials: refusals logged as ordinary network errors, so the one signal the pattern generates never reaches anyone.

Lessons learned

Egress is the last control that still works after the model has been convinced. Build it before you need it.
Derive the list from measured traffic rather than assumption. Doing exactly that for the inbound origin rule on our own MCP endpoint produced a rule that differed from the one we would have written from a default.
Treat a denial as an alert, not an error. It is the cheapest attack signal in the stack.
Every wildcard is a promise you cannot keep. Name hosts, or accept that you do not have an allowlist.

FAQs

Is an egress allowlist realistic for an agent that browses the web?: Yes, if you constrain the shape rather than the set. Permit wide GET traffic through a proxy that forbids request bodies and caps sizes: the agent can read broadly while having no channel wide enough to write out what it read.
Does DNS need to be on the list?: It does. A resolver the agent can query freely is an exfiltration channel — data encoded into subdomain lookups leaves without a single HTTP request. Route DNS through the same policy.
We already have least-privilege tools. Is this redundant?: No; they cover different halves. Least privilege bounds what the agent can do, egress control bounds where what it already read can go. A read-only agent with open egress can still leak everything it can read.