Default-Deny Egress for AI Agents: Stopping SSRF and Tool-Call Data Exfiltration

Classic server-side request forgery exploits a specific vulnerable parameter: a URL field, a webhook callback, an image-import feature that a developer wired to accept user input and then fetches it server-side. The set of things the server can be tricked into fetching is bounded by which parameters exist and how they are validated. Finding an SSRF bug in a traditional application means finding one of those parameters and proving it reaches an internal or attacker-controlled destination.

An AI agent with tool access removes that boundary. The agent's next action, including which URL to fetch, which internal API to query, or which endpoint to send a summary to, is a decision the model makes at runtime based on the full context it is holding, which includes untrusted content by design. A retrieved web page can contain text instructing the agent to fetch a second URL. A tool's own JSON response can contain a field the agent interprets as an instruction. A document a user uploaded for summarization can carry hidden text steering a later tool call. None of these are bugs in the traditional sense; they are the intended behavior of a system built to read content and act on it. The result is that any tool capable of making an outbound request is a potential SSRF path, not because the tool is poorly written, but because the caller deciding the destination is a language model reasoning over untrusted input rather than a fixed code path.

The highest-value target for this kind of steering is the cloud metadata service. AWS, Azure, and GCP all expose instance metadata, including temporary IAM credentials, at the link-local address 169.254.169.254, reachable without authentication from inside the VM or container. An agent that can be steered into fetching that address, directly or via a redirect chain, hands back live cloud credentials to whatever untrusted content triggered the request. A second target is anything on the internal network the agent's runtime can otherwise reach: internal admin panels, other services' unauthenticated APIs, or metadata about the deployment itself. A third is exfiltration in the other direction: an agent convinced to POST a summary of sensitive data it has read to an attacker-controlled endpoint disguised as a legitimate-looking callback URL.

Building egress control for agent tool calls requires a specific network architecture in place before the allowlist logic itself matters:

Agent runtime isolation. The process or container executing agent tool calls needs to run in its own network segment or namespace, separate from the rest of your infrastructure, so that "internal network" and "agent network" are distinct zones with a controllable boundary between them. If the agent runs on the same flat network as your databases and internal services with no segmentation, an egress proxy in front of its HTTP client only closes one of several paths to those services.

Forced routing of all outbound traffic. Every outbound connection the agent's tools can make, not just the ones going through an HTTP fetch tool, needs to be forced through the control point. This usually means a combination of a network-level default-deny firewall rule (nothing leaves the agent's subnet unless a rule permits it) and an HTTP-aware forward proxy for the traffic that needs domain-level allowlisting rather than just IP/port rules.

An inventory of what the agent actually needs to reach. You cannot write a default-deny allowlist without first knowing the legitimate destinations: which APIs each tool calls, which internal services are genuinely required, and which of those can be scoped to a specific agent or task rather than granted globally.

Logging and alerting infrastructure. A default-deny policy generates denied-request events by design, both from real attacks and from legitimate new integrations you have not allowlisted yet. You need somewhere those denials land and get reviewed, or the policy either gets disabled the first time it blocks something legitimate, or drifts silently.

The following steps build the egress control layer from the network boundary inward to the allowlist logic itself.

Before trusting this architecture in production, run the following test cases against it. Each should fail (be blocked) except the last, which should succeed:

Metadata endpoint fetch. Configure a test agent or tool call to request http://169.254.169.254/latest/meta-data/ (or the equivalent Azure or GCP metadata path). Confirm the proxy and the network-layer firewall both independently deny it, and confirm the denial is logged and alerts fire.

DNS-rebinding attempt. Register a test domain whose DNS record you control, add it to the allowlist as if it were a legitimate destination, then change its DNS record to resolve to an internal RFC1918 address or 169.254.169.254 and repeat the request. Confirm the proxy's resolve-then-validate step catches the changed resolution rather than trusting the hostname because it matched the allowlist string.

Internal RFC1918 address fetch. Attempt to reach an internal service by its private IP address directly (bypassing DNS entirely) from the agent's network segment. Confirm the network-layer firewall rule from the procedure blocks it independent of whatever the HTTP proxy does, proving the control does not rely solely on hostname-based logic.

Redirect-chain evasion. Point a test request at an allowlisted domain that issues an HTTP redirect to a blocked destination (an internal IP or the metadata range). Confirm the proxy re-applies its validation after following the redirect rather than only checking the original request's destination.

Legitimate allowlisted call. Run a real tool call to a destination that is genuinely on the agent's allowlist (the actual API the tool is meant to reach) and confirm it succeeds with no added latency that would make the control operationally unworkable. A control that blocks everything, including legitimate traffic, will get disabled the first time it causes an incident; validating the positive case is as important as validating the negative ones.

Allowlist drift as agents gain new tools. The most common way this control degrades is silent: a team adds a new tool or integration to an agent, the tool works in testing because a developer manually added a permissive rule to get past the proxy, and that rule is never scoped down or reviewed again. Over time the allowlist accumulates broad exceptions that no longer reflect what any single agent actually needs, and the effective policy converges toward allow-most rather than default-deny. Treat every new tool addition as a required allowlist review, not an optional one, and periodically audit for allowlist entries nobody can explain.

Proxies that only cover HTTP, missing other protocols the agent's tools use. An HTTP-aware forward proxy stops fetch and browse tools cleanly, but agent tool ecosystems increasingly include direct database clients, gRPC calls to internal services, raw DNS lookups performed independently of any HTTP request, and in some deployments a shell or code-execution tool that can invoke curl, wget, or a language runtime's own socket library directly. Any of those paths that does not route through the HTTP proxy bypasses the allowlist entirely unless the network-layer default-deny firewall from the procedure's first steps is also genuinely enforced. Verify coverage by attempting an outbound connection through every distinct tool category the agent has access to, not just the ones that obviously make HTTP calls.

Agents running outside the controlled network path. Browser-based agents, client-side agent extensions, or agents embedded in a desktop application make their outbound requests from the end user's own network, not from infrastructure you control. A server-side egress proxy has no visibility into or control over those requests at all. For these deployment models, the equivalent control has to live in the browser extension or client application itself (a local allowlist enforced in the client, or routing the client's traffic through a company-managed proxy via device management), and it is a fundamentally weaker control because it runs on infrastructure the user, not you, ultimately controls. Any risk assessment for a client-side or browser-based agent needs to treat egress control as substantially harder to guarantee, not as a solved problem carried over from the server-side pattern.

Degraded allowlists under time pressure. During an incident or a rushed feature launch, the fastest way to unblock a failing agent is often to widen an allowlist rule rather than diagnose why the narrower rule was insufficient. Each of these shortcuts is individually reasonable and cumulatively erodes the control. Track allowlist rule count and scope over time as an operational metric, the same way you would track firewall rule sprawl, so the trend is visible before the policy has quietly become permissive.

Default-deny egress for agents is not free, and the costs are worth naming rather than glossing over.

Operational overhead versus blast radius. Maintaining a per-agent, per-task allowlist requires ongoing engineering attention: every new integration needs a reviewed rule, every agent redesign needs the allowlist re-audited, and every denial needs someone to determine whether it is an attack or a legitimate gap. That overhead is real and recurring. The alternative, unrestricted or loosely restricted egress, converts every prompt injection or malicious tool response from a contained event into a potential path to cloud credential theft, internal network reconnaissance, or data exfiltration. The overhead is the cost of keeping the blast radius of a single successful injection bounded to what a specific agent's specific allowlist permits, rather than open to your entire reachable network.

False-positive blocking of legitimate new integrations. A well-enforced default-deny policy will, by design, block a legitimate new API call the first time a team tries it, before anyone has added it to the allowlist. This creates friction that teams will be tempted to route around, either by requesting overly broad allowlist entries or by disabling the proxy for a specific agent "temporarily." Building a fast, low-friction path to review and approve new allowlist entries (ideally as fast as a normal pull request review, not a multi-day change-management process) is what keeps that friction from turning into pressure to weaken the control instead.

DNS-rebinding and redirect-chain checks add latency and complexity. Resolving DNS at the proxy, validating every returned IP, and re-validating after redirects is more code and more processing per request than a naive hostname-string allowlist check. It is also the part of the architecture most likely to have a subtle bug if implemented in a hurry (missing IPv6 ranges, not re-validating after a redirect, caching a resolution longer than the DNS record's TTL in a way that misses a rebinding attempt). This is the piece of the procedure worth the most code review scrutiny, since a control that looks complete but has a gap in exactly this logic is worse than no control, in that it creates false confidence.

For teams already working through where AI tools fit in their broader governance picture, this control is one piece of a larger problem; our guide on shadow AI governance covers the visibility gap that often exists before an organization even knows which agents have outbound network access to begin with. And because many agent tool integrations authenticate via OAuth grants to SaaS platforms rather than static API keys, the access those grants represent is worth auditing on its own terms; see our guide on auditing OAuth app grants across Microsoft 365, Entra ID, and Google Workspace for how to find and review what an agent's connected apps can actually reach, independent of the network-layer controls in this piece.