DEV Community

Cover image for Giving AI agents network access without getting owned
Weston Carnes
Weston Carnes

Posted on • Originally published at stellarbytecapital.com

Giving AI agents network access without getting owned

Cross-post. Original: stellarbytecapital.com/blog/ai-agent-network-egress-control

Most useful AI agents need the network. They fetch market data, call an API, hit a database. But the moment your sandbox can reach the open internet, you've built the exact channel an attacker needs to exfiltrate data or pull a payload. Network egress is where a contained breach turns into a real one — and it's the control teams skip most often.

Why egress is the control that matters most

Think about what a compromised agent actually needs to cause damage. It can read data in its sandbox, sure. But to exfiltrate it, it needs a network path off the box. Cut that path, and a "successful" compromise has nowhere to send anything.

An escaped agent with no egress is mostly harmless. Isolation stops the code from breaking out; egress control stops the data from getting out. You want both.

The principle: default-deny, then allowlist

The sandbox starts with zero outbound network. You open specific destinations the task genuinely needs, and nothing else. You can't enumerate every bad destination, but you can enumerate the handful of good ones a task actually requires.

How to actually implement it

  1. Start with no route. Give the sandbox a network namespace with no default gateway.
  2. Allowlist by domain, through a proxy. Route outbound traffic through an egress proxy that permits an explicit list. Allowlist by domain, not IP — IPs rotate and shared CDNs mean one IP serves thousands of hosts.
  3. Control DNS. Give the sandbox a resolver you control. DNS is itself an exfiltration channel — data can be smuggled inside lookup names.
  4. Scope per task, not per system. A task that needs Bitget's API gets Bitget's API — not every endpoint every task has ever needed. Disposable sandboxes make this natural: the allowlist dies with the container.
  5. Log every outbound call. Destination, size, timing. Unusual egress volume is a live signal that something's off.

Common mistakes

  • "The task might need it," so open everything. Default-deny, then add what breaks.
  • Allowlisting by IP. Shared CDNs and rotating IPs make this too permissive and too brittle.
  • Forgetting DNS. An otherwise-locked sandbox with open DNS still has an exfiltration channel.
  • No logging. If you can't see what left the sandbox, you can't investigate or detect abuse.
  • A permanent global allowlist. It only grows, and every entry is attack surface for every task.

Egress control is a layer, not the whole wall

Locking down egress doesn't replace isolation — it complements it. The controls stack: disposable per-run isolation, least privilege, no secrets in the sandbox, and default-deny egress. Each closes a door the others don't.

Give the agent exactly the network it needs for the task in front of it — and not one destination more.


We're Xingyao Byte — building secure AI-execution layers, quant trading systems, and payment platforms. Remote, async-first → stellarbytecapital.com

Top comments (0)