← Blog
AI SecurityNetworkAgents

The Egress Problem You Did Not Know You Had

Network egress policy is a mature control in most security programs. It has been refined over years, against real attackers, with real telemetry. Teams know their baseline, know their exceptions, know what anomalous traffic looks like when it shows up. The control works.

The control was not designed against agents.

Why agents are different

The workloads egress policy was designed against are predictable. A web application talks to its database, its cache, its payment processor, its analytics vendor. The destination set is small, stable, and documented. Anomalies stand out because the baseline is tight.

An agent's destination set is not small. It is a function of what the agent is asked to do. A research agent may touch dozens of external domains in a single session. A code generation agent may fetch documentation from a long tail of sites. A support agent may look up information on customer-referenced systems across the public internet. The baseline is wide because the task is wide.

When the baseline is wide, anomalous traffic does not stand out. It hides. An exfiltration attempt dressed as a research lookup is in-distribution traffic, and the egress policy that works beautifully for the web application cannot see it.

The default response, and why it fails

The default response when this is raised is to narrow the allowlist. "Agents can only reach these approved destinations." This works for narrow-purpose agents with stable destinations. It breaks for the agents that are actually interesting — the ones whose value comes from their ability to work across an open-ended set of sources.

Narrowing the allowlist against a research-style agent either kneecaps the agent or produces a hopelessly broad allowlist that provides no meaningful control. The team ends up with an allowlist that permits "the internet" for practical purposes, at which point the control is theater.

A better response is to treat agent egress as a separate policy surface with its own telemetry, its own review cadence, and its own detection logic tuned to the actual threat model for that workload.

What "tuned to the threat model" looks like

A few specifics we have found useful.

Per-session egress budgets. An agent session has a ceiling on the number of external destinations it can contact. The ceiling is generous — wide enough for normal work — but finite. Sessions that hit the ceiling are flagged for review. Most real work does not hit it. Sessions that do usually have an explanation or a problem.

Destination-category anomaly detection. Agent traffic is categorized — documentation, search, API, unknown. The distribution is stable for a given agent type. A session where a normally-documentation-heavy agent suddenly has half its traffic in "unknown" is a detection surface that the raw destination list was not giving you.

Payload-shape telemetry on outbound requests. Not content inspection — that is often infeasible — but shape. How much data, in what kind of encoding, with what URL structure. An agent that starts putting long base64 strings in URL paths is doing something worth understanding, even if each individual request looks allowed.

Deny-list exit ramps, not allow-list entry ramps. For broad-purpose agents, a maintained deny list of known-bad destinations, combined with the telemetry above, tends to be more practical than a maintained allow list. This is the opposite of conventional egress policy; it is the choice that matches how the workload actually behaves.

The uncomfortable conclusion

Egress policy for agents is not egress policy for applications with more allowlist entries. It is a different control surface that happens to live on the same network layer. Teams that treat it as the former will either over-constrain their agents or under-constrain their security. Teams that treat it as its own thing have a chance at getting it right.

This is another instance of a pattern that recurs in agent security: a familiar-looking control does not transfer cleanly from the old workload to the new, and the instinct to apply the old control unchanged is the instinct to leave a gap.