Network Egress

Which hosts an agent's own HTTP requests may reach. Set per agent, enforced in the agent's process at two layers, and reported by mur agent perm.

mur agent perm show coach network              # the whole outbound block
mur agent perm list-hosts coach                # allow list + what else is reachable
mur agent perm set-mode coach network.outbound restricted
mur agent perm allow-host coach api.example.com
mur agent perm allow-host coach '*.api.example.com'
mur agent perm deny-host coach api.example.com # removes that glob from the allow list

Changes land on the agent's next start — mur agent perm warns when the agent is running.

The four modes

What the allow list matches

Matching is case-insensitive. An IP literal is matched as a host string, so allow_hosts: ["203.0.113.5"] permits http://203.0.113.5/ and nothing else on that subnet.

What is reachable without being listed

The agent's own model host. Choosing a provider is permission to reach it, so you never have to allow-list your own model endpoint. mur agent perm list-hosts says so explicitly in restricted and proxy_only.

Loopback — 127.0.0.1, localhost, ::1. A local model, and MUR's own loopback model gateway, live here. Loopback is deliberately not an entry on the allow list: the sandbox grants the agent's local LLM port instead, so the decision about what on this machine an agent may reach is made at the OS layer, where it can be enforced. proxy_only depends on this — its whole definition is egress through loopback proxies.

off is the exception: it means no network, and that includes loopback.

What is never reachable, in any mode

Link-local and unspecified addresses — 169.254.169.254 and friends, the cloud metadata endpoints, including their IPv6-mapped spellings. This screen runs before the allow list and applies even under unrestricted, because an agent with no host policy still must not be steered at instance credentials. A hostname that resolves to one of those addresses is dropped too, which is what stops DNS rebinding.

Where the check happens

Two layers, because neither alone sees everything:

• DNS resolution screens hostnames as they are resolved.
• The request URL is checked before the request goes out, which is the only place the real destination is visible. reqwest never consults a custom resolver for an IP-literal URL, so without this layer allow_hosts simply did not apply to http://203.0.113.5/.

Both consult one rule, so a host cannot be permitted by one and refused by the other. On top of that:

• Every redirect hop is re-checked. An allowed host answering 302 Location: http://elsewhere/ does not get to move the request somewhere the list forbids. A redirect the list does permit is still followed.
• HTTP_PROXY in the agent's environment is ignored for these requests. A proxied request would have its proxy's hostname resolved rather than its target's, which would leave the allow list unapplied — and it would let a debug proxy capture model traffic.

What this does and does not cover

It covers the agent process's own HTTP: model calls and anything else the runtime issues itself.

It is not the boundary for MCP servers. Those are child processes with their own per-server policy, routed through a loopback egress proxy, and that layer is advisory — a child that ignores HTTP_PROXY can still reach the network. See MCP Pinning for what is and is not enforced there.

And it is an in-process defence, not a kernel one. The OS sandbox can restrict ports, not hostnames, so host policy has to live in the process that makes the request. proxy_only is the mode that narrows this: with general outbound TCP denied at the OS layer, egress has to go through a proxy that can see the destination.