How to Restrict What an Agent Can Reach on the Network

Quick answer
Default-deny egress and allow only the hosts the task needs; an agent with open internet access can send data anywhere it can encode.
Block cloud metadata endpoints explicitly — they hand out credentials that do not appear in any environment file.
Put third-party APIs behind a proxy that holds the credential, so the agent calls an operation rather than a raw endpoint.
Log every destination and byte count; egress logs are the primary evidence in an agent incident.
Container network policies and egress-only proxies are easier to audit than per-process firewall rules.

Why is network access the control that matters most?

Almost every data-exfiltration path ends in a network request. If the agent can reach any host, then anything it can read it can also send, whether through a tool call, a markdown image, or a request in a script. Restricting destinations converts a large class of incidents into a blocked connection.

It also constrains what the agent can be convinced to do. An injected instruction to post data to an external endpoint fails at the network layer even when the model complied. That is a control that does not depend on the model behaving.

What should the allowlist contain?

The package registry the project uses, the API endpoints the task needs, and the internal services it must talk to. Nothing else. Build the list from an observed successful run rather than from imagination, then prune it.

Explicitly deny link-local and metadata addresses. On a cloud host, the metadata service can issue credentials that never appear in the environment, which turns a read-only agent into one with cloud permissions.

# Example: run the agent in a network namespace with a proxy-only path
# and no route to the metadata service (169.254.169.254).
docker run --rm -it \
  --network agent-net \
  --env HTTPS_PROXY=http://egress-proxy:3128 \
  --env NO_PROXY=localhost,127.0.0.1 \
  -v "$PWD":/workspace -w /workspace agent-image:1.4.2
# The proxy holds the allowlist and logs every destination.

How do you decide between a proxy and a firewall?

A proxy sees the request: method, host, path, size. That lets you allow POST /v1/issues while denying POST /v1/admin, and it gives you a log with arguments. A firewall sees addresses and ports, which is coarser and blind to what was sent.

For third-party APIs, proxy. For internal services on a private network, a network policy is often enough. Most setups need both: a policy that prevents arbitrary egress, and a proxy that holds credentials for the calls that remain.

What breaks when you turn this on?

Package installs, telemetry, and editor plugins. Decide deliberately: a build that needs a registry should get the registry, not the internet. Web search tools need their own endpoint. Everything that fails should fail loudly, so the allowlist is a reviewed list rather than a habit of adding hosts until it works.

Also test the agent’s error handling. An agent that cannot reach a host may retry for minutes, which looks like a slow task rather than a blocked action. Make the policy return an explicit denial the agent can report.

Where this bites vibecoders
The default container has internet access, and the first failure after you restrict it will tempt you to remove the restriction. Add the one host the task needed, keep the metadata endpoint blocked, and write down why each host is allowed.

Where AI coding assistants get this wrong

Leaving egress open because package installs are convenient.
Forgetting the cloud metadata endpoint, which issues credentials.
Allowing a whole domain when one path is needed.
Letting the agent hold the third-party credential the proxy should hold.
Not logging destinations, so an incident cannot be scoped.
Treating a blocked host as a bug and re-opening egress broadly.

Checklist

Start from a deny-all egress policy.
Allow the registry, the task APIs, and internal services.
Block metadata and link-local addresses.
Proxy third-party calls and keep credentials there.
Log destination, method, and bytes.
Review the allowlist whenever a host is added.

FAQ

Is blocking the internet enough to stop exfiltration?

Only if the allowlist is narrow. An allowed destination can still receive data through a path or parameter you did not consider, especially a general-purpose API. Pair the allowlist with scoped credentials and argument-level rules where the proxy supports them.

What about DNS exfiltration?

A resolver can carry data in query names. If the agent does not need DNS beyond a known set of hosts, restrict resolution to those. A proxy-only path removes the direct resolver from the agent’s reach, which closes that channel.

Do I need this for a local agent on my laptop?

A laptop agent can reach your internal network, your cloud metadata endpoint if you are on a cloud VM, and any service that trusts your IP. The risk is lower than a shared runner, but the control is still worth having for anything with write access.

How do I test the policy?

Run a task that should succeed and one that should be blocked, then confirm the logs show allowed and denied destinations. A policy nobody tested is usually a policy with an accidental allow-all rule at the top.