AI Agent Network Egress: Allow Only the Destinations It Needs

An AI agent with a browser, HTTP client, or general-purpose tool can turn a narrow task into an open network path. It may follow a redirected URL, fetch instructions from untrusted content, send data to an unexpected host, or call an endpoint that was never part of the design. A prompt saying “use only approved sites” is useful context, but it is not a network control. The enforcement point must sit outside the model.

Why this deserves a deliberate process

Egress rules reduce both accidental disclosure and the impact of prompt injection. They also make cost, privacy, and incident investigations easier because the team can explain which external systems were reachable. The hard part is avoiding a brittle hostname list that silently breaks on redirects, content delivery networks, authentication flows, or regional endpoints. A good policy starts from the business action, resolves every dependency, and denies everything else with an observable error.

A practical workflow

1. Inventory complete request paths. For each agent task, record the initial hostname, authentication issuer, API hostname, redirect targets, object storage, telemetry, and any human approval service. Capture ports, protocols, HTTP methods, and expected data classes.
2. Place enforcement outside the agent. Route outbound traffic through a workload firewall or authenticated proxy. Deny direct internet access, raw sockets, alternate DNS resolvers, and metadata-service addresses unless the task explicitly requires them.
3. Allow destinations by verified identity. Prefer stable service identities, private endpoints, or documented domain sets. Validate TLS and re-resolve DNS safely. Never allow an IP simply because it was returned once for an approved hostname.
4. Constrain the application request. Limit methods, paths, payload size, content type, and redirect behavior. Strip credentials before a cross-origin redirect and reject loopback, private, link-local, and cloud metadata destinations.
5. Design a reviewed exception path. A blocked request should produce a ticket with agent identity, initiating user, destination, reason, and sample metadata. Time-bound any temporary access and test revocation.

Work through a realistic case

A research agent may read a public vendor documentation site and write a summary to an internal knowledge base. The proxy allows GET requests to the documented public hosts and POST requests only to the knowledge-base API. When a page redirects to an unfamiliar file host, the proxy blocks it and records the redirect chain. An operator checks the vendor documentation, adds the specific read-only host with an expiry date, and reruns the task. The agent never receives authority to approve its own destination.

Evidence and measurements

Track denied connections, newly requested hosts, exception age, bytes sent, credential-bearing requests, redirects, DNS changes, and traffic by agent identity. Review false positives, but also sample successful requests for destinations that are technically allowed yet unusual for the task. A low block count is not proof of safety; it may mean traffic bypasses the proxy. Run a periodic canary that attempts a forbidden private address and confirm the network layer denies it.

Test the network boundary, not only the prompt

Build a small request matrix with an allowed HTTPS URL, a denied public host, a private address, a redirect from the allowed host to the denied host, and a URL containing a username or password. Use harmless endpoints you control. The expected result should identify which layer blocks each request and what the operator sees. Never test against an unrelated private network.

Check the same cases through every tool capable of network access. A browser tool may honor the proxy while a shell tool or package manager does not. An agent can also cause a trusted service to fetch a URL on its behalf; that secondary service needs its own destination checks. Record these indirect paths separately.

For allowed requests, verify that the proxy does not add a shared credential or reveal internal headers. Then change the destination policy while work is queued and confirm the execution-time decision uses the current rule. Approval made before a policy change must not permanently authorize a connection.

Common mistakes

• Wildcarding a vendor domain: A broad suffix may include user-controlled subdomains or services with unrelated risk.
• Trusting URL text: Resolve and validate the final destination after redirects and on every connection.
• Logging secrets: Proxy evidence should retain useful metadata without storing authorization headers or sensitive bodies.
• Permanent emergency rules: Temporary access becomes shadow architecture unless it has an owner and automatic expiry.

Review checklist

• Can the workload reach the internet without the policy enforcement point?
• Are redirects, DNS rebinding, private addresses, and alternate ports tested?
• Does every allowed destination map to a documented agent action?
• Are write methods narrower than read methods?
• Can responders identify and revoke one agent without stopping the whole platform?

Put it into routine operations

Treat egress policy as versioned application configuration. Test it beside the agent’s functional regression suite and deploy changes gradually. Compare observed destinations with the inventory after model, tool, authentication, or vendor changes. Give security and service owners a compact diff during review. During an incident, preserve proxy metadata and immediately narrow the affected identity’s policy rather than applying a blanket network outage.

Related Duck Cloud reading

Pair network controls with AI Agent Sandbox Testing and use the DNS Lookup only for systems you are authorized to examine.

Conclusion

Agent egress should be a small, explainable capability, not ambient internet access. Map the real request path, enforce it outside the model, constrain methods and redirects, and make exceptions temporary and visible. That keeps useful automation connected without making every fetched page part of the security boundary.