Why AI Coding Agents Need Network Egress Controls

Your coding agent doesn't actually need the internet to write code. It needs the internet to install a dependency, call an API, or push a commit, and that short list of legitimate reasons is exactly the door attackers walk through once they've hijacked it.

AI coding agent egress controls sound like extra plumbing until you see how little it takes to turn a prompt injection into a live breach. In 2026, the Cloud Security Alliance documented an incident researchers nicknamed "Clinejection": a single crafted GitHub issue title was enough to hijack an automated issue-triage workflow built on the Cline coding agent. From there the attack chained four steps with no human in the loop: indirect prompt injection through the issue title, theft of an npm publish token sitting in the workflow's environment variables, poisoning of the CI artifact cache, and publication of a malicious cline@2.3.0 release that installed a rogue AI agent on every machine that pulled it. The package stayed live for about eight hours before anyone caught it.

Prompt injection doesn't need a vulnerability

That's the part worth sitting with. There was no buffer overflow, no leaked credential lying around in a repo, no unpatched CVE. The model just read text it was told to treat as instructions and did what it said. Phoenix Security's supply chain research puts a number on how common this is becoming: across 59 documented campaigns and 657 malicious package versions on npm, PyPI, and the VS Code marketplace since 2024, zero had an assigned CVE. Traditional vulnerability scanning had nothing to catch. Their deep scans also found that AI-agent skills carry a risk rate 2.3 times higher than ordinary IDE extensions, with more than a quarter triggering critical findings, because the attack now targets the agent's trust in its own config files instead of a code path.

That's why input sanitization and careful prompting aren't enough on their own. They're aimed at stopping the injection from landing. Egress control is aimed at what happens if it lands anyway: it can't steal a token, poison a cache, or drop a persistent daemon on a developer's machine if the process running it has nowhere to send the data or fetch the payload.

What agent network isolation actually looks like

The fix isn't exotic. It's the same default-deny instinct you'd apply to a production service that handles secrets, applied to the CI runner or sandbox your agent executes in. Allow outbound traffic to the registries and APIs the job actually needs, and block everything else by default.

# .github/workflows/agent-triage.yml
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - name: Harden the runner's network egress
        uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: >
            github.com:443
            api.github.com:443
            registry.npmjs.org:443
            objects.githubusercontent.com:443
      - uses: actions/checkout@v4
      # agent steps run here with no route to attacker infrastructure

This blocks the exact move that made Clinejection work: an agent process reaching out to attacker-controlled infrastructure to exfiltrate a token or pull down a second-stage payload. Run it in audit mode first to see what your workflow normally talks to, then flip to block once you've built the allowlist.

"But won't this break my agent's workflow?"

This is the real objection, and it's fair. Agents do legitimately need to hit package registries, model APIs, and your own internal services. The answer isn't to cut the agent off from the internet; it's to name exactly what it's allowed to reach instead of trusting it to only reach good things. That's a one-time cost to enumerate, and it's cheaper than the incident response after a token walks out. It also survives the failure mode that sanitization doesn't: even a prompt injection nobody thought to filter for still can't phone home.

One more thing worth knowing: by mid-2026, Phoenix Security found that npm ci --ignore-scripts alone stopped being reliable protection, because attackers found ways to smuggle shell execution through build config files instead of lifecycle scripts. Egress filtering doesn't care which trick got the process running; it cares where the process is trying to send traffic.

Where to start

Pick the one agentic workflow in your pipeline with write access to a registry, a deploy target, or a secret store, and put a default-deny egress policy in front of it this week. Everything else on your roadmap can wait for that one.

If an agent in your production pipeline can read untrusted text and reach the open internet in the same breath, you don't have a prompting problem, you have a network problem wearing a prompting costume.