Why every AI agent setup needs an egress proxy

Count the outbound connections your AI agent setup makes in an hour. Model API calls, MCP servers, package registries, git remotes, internal dashboards the agent scrapes for context. Now ask how many of those connections pass through anything you control. For most setups the answer is none — the agent’s egress is a direct line to the internet, and the only policy is whatever the model decides to do.

An egress proxy is the missing middle: one hop that outbound HTTP(S) connections cross, where you can see, filter, and modify traffic.

One choke point instead of N tools

Without a proxy, visibility means instrumenting each tool — logging in the agent, wrapping the CLI, hoping the SDK cooperates. With a proxy, every request lands in one place. You get a single audit trail of what the agent talked to, when, and with what payload. That is exactly the data you need when something goes wrong, and exactly the data you can’t reconstruct from scattered tool logs.

TLS interception is the price of inspection

The catch: modern traffic is encrypted end to end. To inspect request bodies, the proxy must terminate TLS and re-encrypt — a man-in-the-middle with a locally trusted CA. That’s a real operational decision. Install the CA into the tools and processes you want to monitor, leave the rest alone. It’s a trade between privacy of the byte stream and visibility of its contents, and for agent traffic the latter usually wins.

What an egress proxy buys you

• Secret control. Scan outbound bodies for secret-shaped strings and mask or block them before they leave — DLP at the network boundary, not the clipboard.
• Credential injection. The proxy adds per-host headers or query parameters with keys the agent never holds. The agent calls the same URL; the proxy adds the auth.
• Deny by default. Blocklist endpoints, disable tool categories, refuse requests to unexpected hosts — policy enforced outside the agent’s reach, where prompt injection can’t override it.
• Consistency. Curl, the coding agent, the MCP server — they all cross the same gate, so rules apply to everything, not just the tools you remembered to wrap.

The failure modes

Egress proxying is not free. MITM breaks clients that pin certificates or run strict TLS checks. A proxy that blocks too aggressively can stall agent loops — the agent retries, burns tokens, and fails in confusing ways. And an egress proxy sees only traffic that actually goes through it: DNS exfiltration and non-HTTP channels need other controls. The pragmatic posture is selective proxying — route the high-value destinations (model APIs, external services) through the gate, not every byte.

Fitting it into an agent setup

For the common case — agents talking to OpenAI-compatible model endpoints — a reverse proxy in front of the endpoint is enough: the agent keeps its URL, the proxy scans, masks, and injects on the way through. For HTTP tools, a credential-injecting proxy plays the same role. Either way the agent never holds the keys, and every request gets inspected.

trustless ships both halves: trustless serve, a DLP reverse proxy for any OpenAI-compatible endpoint with per-host header and query injection and HTTPS MITM, and trustless proxy for credential injection into HTTP tools — a single static Go binary with no runtime dependencies, and an audit log that never contains token values. Setup is covered in the command reference.

Here’s the question to answer honestly: can you list every outbound connection your agents made last week, and what was in each one — or would you be guessing?