Skip to content
agentics.download
all field notes

· Wes Klaassen

Your agent's tools need a default-deny egress wall

  • security
  • architecture

Ask someone how they secure an MCP server and you’ll usually hear about auth: who can call the tool. The more important question is almost never asked: who can the tool call?

The threat that actually keeps you up

The scary failure mode for agent tooling isn’t a stranger invoking your server. It’s a dependency, three levels deep in your tool’s requirements, that ships an update which quietly posts your environment variables to a domain you’ve never heard of. Or a prompt-injected agent that convinces a tool to fetch a “config file” from an attacker’s host.

Both attacks have one thing in common: they need outbound network access to an arbitrary destination. Take that away and whole classes of attack collapse — exfiltration has nowhere to go.

Default-deny, per tool

The pattern that works: each tool runs on an internal network with no route to the internet except through a proxy sidecar, and that proxy enforces a domain allowlist that is empty by default. A market data tool gets its data API and nothing else. A search tool gets the search API and nothing else. Not “block known-bad hosts” — allow known-good ones, deny the rest, log the denials.

Per-tool matters as much as default-deny. A shared allowlist across tools converges on “the union of everything anyone needs,” which is just the internet with extra steps. When each tool carries its own list, adding a host is a reviewable, one-line diff that says exactly which tool gained exactly which destination.

”We have an egress policy” vs. proof

An egress wall you haven’t tested is a diagram, not a control. Three checks make it real:

  1. Allowlisted hosts succeed through the proxy. The happy path works.
  2. Everything else is denied and logged. Pick a random domain, watch the request die, find the denial in the audit log.
  3. Bypass attempts fail. From inside the tool container, try to reach the internet directly — not via the proxy. The packets should have nowhere to go, because the network has no other route. If the tool can opt out of the proxy, you don’t have an egress wall; you have an egress suggestion.

The audit log is the quiet bonus: one place that answers “what did my tools talk to this week?” — which is also exactly the question you’ll be asked after any incident.

The cost is real but small

Yes, you’ll occasionally add a host to an allowlist when a tool grows a feature, and yes, an API that moves to a new CDN domain will break until you allow it. That friction is the control working. Each interruption is a moment where a human confirms “this tool should talk to this host” — the exact decision you never get to make when everything can talk to everything.

Auth decides who gets in. Egress decides what gets out. For agent tools, the second one is where your accounts live or die.