An agent sandbox with open egress is a laptop that can call the world. Allowlists shrink that world to the hosts the task needs. Without them, a prompt injection or a confused tool call can exfiltrate files, hit internal admin APIs, or buy you a surprise cloud bill.
Egress control is not anti-productivity. It is how you keep demos from becoming incidents. Most teams discover this only after a model helpfully posts a secret to a paste site.
Start from the tools, not from the internet
List every host your tools must reach: model API, package mirror, docs domain, ticket system. Put those on the allowlist. Deny the rest by default. If a new tool needs a host, add it in review, not in a panicked hotfix after a blocked call.
DNS wildcards feel convenient and age badly. Prefer exact hosts. When you need a pattern, keep it narrow and logged. Document why each entry exists so the next engineer can delete it safely.
Separate build egress from runtime egress
Installing packages and running the agent are different trust levels. Use a tighter runtime allowlist once dependencies are present. A session that can reach every package mirror forever is a session that can download surprise payloads mid-run.
Pair this with short-lived sandbox API keys so a leaked token dies with the session.
Log denials with enough context to fix policy
When a call is blocked, record the sandbox id, tool name, destination host, and whether the model retried. Engineers need that to tell a missing allowlist entry from an attack probe.
Silent blocks create thrash. The agent retries, burns tokens, and invents workarounds. Surface a clear tool error: destination not allowed. Then the model can ask for a different approach instead of looping.
Block metadata and link-local targets
Cloud metadata endpoints and link-local addresses are classic escape hatches. Deny them explicitly even if your main allowlist looks small. Also deny raw IP access if your policy is hostname-based, or you will watch attackers skip DNS.
Related hardening: prompt injection defenses in app assistants and signed webhooks for AI callbacks.
Review allowlists like code
Store allowlists in version control. Require a second reviewer for new hosts. Expire temporary entries. A one-week vendor domain that becomes permanent is how policies rot.
Run a monthly prune. If no tool used a host in thirty days, mark it for removal. Dead entries hide the real attack surface.
Test with intentional bad calls
In staging, ask the agent to fetch a random external URL and to hit a metadata path. Confirm both fail closed. Add those cases to your eval harness so a future config change cannot reopen the gate quietly.
Also test a legitimate tool path after every allowlist edit. False denials train humans to disable the control. Keep a golden path check beside the negative tests.
Sandbox egress allowlists will annoy someone once. Open egress will annoy your security team forever. Default deny, log clearly, and grow the list with review.
FAQ
What is a sandbox egress allowlist?
It is a default-deny list of hosts the sandbox may contact, limited to what tools need for the task.
Why separate build and runtime egress?
Dependency install often needs broader network access than agent runtime. Keeping runtime tighter reduces mid-run downloads.
What should denial logs include?
Sandbox id, tool name, destination host, and retry behavior so you can fix policy or spot probes.
Should metadata endpoints be allowed?
No. Deny cloud metadata and link-local targets explicitly.
How do allowlists stay maintainable?
Keep them in version control, review new hosts, expire temporary entries, and prune unused hosts monthly.
How do I test the policy?
In staging, attempt a random external fetch and a metadata call, expect both to fail, and keep golden-path checks for legitimate tools.