An agent that reads public documentation and an agent that administers a private database both need network access. They should not inherit the same network permission.
Design outbound access around the tool's job, the requesting identity, and the data it sends.
First decide what connection is expected
A documentation fetcher may need public HTTPS destinations while having no legitimate route to cloud metadata. An internal reporting tool may need one private API, using a credential that must never follow a caller-selected URL.
Start with approved destination groups and a default for everything outside them. Review address resolution and redirects as part of the same decision.
The Grafana SSRF chain and LiteLLM compromise paths illustrate why the server's own network reach matters after an input or authorization flaw.
Then decide what may leave
A destination allowlist does not answer whether a particular payload belongs there. A legitimate SaaS endpoint can still receive a secret or an unauthorized export.
Preserve user, workload, and tool identity at the enforcement point. Where payload inspection is appropriate, evaluate sensitive-data policy as well as destination policy. If a proxy cannot inspect encrypted application content, document that coverage limit and enforce the relevant rule closer to the sender.
Destination and payload checks answer different questions. Both must pass for an inspected request to leave.
Handle the exception as a bounded change
Suppose a new integration needs a private API. The exception should name the owner, identity, destination, operation, credential scope, and expiry or review date.
Avoid widening the entire agent host to reach a whole private range because one tool needs a single service. Give that tool its own route or proxy policy when practical.
Find paths around the proxy
Check shell tools, SDKs, subprocesses, browser automation, and callbacks. An MCP-only proxy cannot govern a separate command that opens its own network connection.
Use network enforcement to constrain those alternate paths. If the architecture depends on a proxy, the process should not have a convenient unrestricted route around it.
Measure decisions without collecting secrets
Log destination, tool identity, policy result, and useful volume metadata. Redact tokens and sensitive bodies. Watch for new destinations, repeated denials, unusual exports, and traffic bypassing the approved path.
Test with controlled endpoints and canary data. Confirm that policy still applies after DNS resolution and every redirect, and that a denied request does not reach its target.