AI coding agents have moved from autocomplete to autonomy. Tools like Cursor, Claude Code, and Devin no longer just suggest a line of code — they run shell commands, install dependencies, hit APIs, push branches, and open pull requests. To do that work, they receive three of the most dangerous capabilities you can hand an autonomous process: a shell, a network connection, and a set of live credentials. In a CI pipeline, all three are wide open.
That combination is the entire problem. A coding agent that can read your .env, run curl, and resolve arbitrary domains is one poisoned README or one indirect prompt injection away from exfiltrating every secret in the build environment. The fix is not a smarter prompt or a better model — it is enforcing what the agent is allowed to do on the wire. This is exactly the layer Agent G operates at.
Why coding agents are a different threat class
Most LLM security tooling assumes a chat-shaped workload: a user types something, the model answers, you filter the input and output. Coding agents break that model in three ways.
They execute, they don't just generate
A chatbot that hallucinates a malicious URL is harmless until a human clicks it. A coding agent that hallucinates a malicious URL pip installs it, runs the post-install hook, and now has code execution inside your runner. The action and the output are the same event. There is no human in between to catch it.
They run where the secrets live
CI environments are credential-dense by design: cloud deploy keys, registry tokens, signing keys, database URLs, third-party API keys. A developer's laptop running Cursor has SSH keys, cloud CLI sessions, and browser cookies. The agent inherits all of it because it runs as the same identity.
Their instructions come from untrusted sources
Coding agents read issues, pull request comments, dependency README files, error messages, and retrieved documentation. Any of these can carry an indirect prompt injection that redirects the agent. This is the lethal trifecta in its purest form: private data, untrusted content, and an outbound channel, all in one process.
The attack paths that actually matter
When teams threat-model coding agents, they fixate on the model saying something rude. The real risks are quieter.
- Secret exfiltration over an allowed protocol. The agent reads an API key from the environment and sends it to an attacker-controlled host using ordinary HTTPS — the same protocol it uses for legitimate API calls. A blanket network policy that allows port 443 sees nothing wrong.
- Dependency poisoning and slopsquatting. The agent installs a hallucinated or typosquatted package from an unapproved registry. See our deep dive on slopsquatting for how often models invent package names that attackers then register.
- Source code exfiltration. Proprietary code is pushed to an unauthorized remote, posted to a paste service, or sent through a webhook the agent was told to call.
- DNS-based exfiltration. Even with HTTP blocked, an agent can encode data into subdomain lookups. Most pipelines never inspect DNS — see DNS as the agent exfil channel nobody monitors.
- Destructive operations. A
rm -rf, aDROP TABLEagainst a production database reachable from CI, or a force-push that rewrites history. Catching these requires intercepting the action, which we cover in blocking the destructive action.
Every one of these paths shares a single chokepoint: the agent has to make an outbound network call to do real damage. That is where you put the control.
Why prompt-level and IAM controls fall short
Three defenses get proposed first, and each leaves a gap.
Prompt filtering and model guardrails inspect what goes into and out of the model. But the dangerous event is the subprocess call or the HTTP request the agent's harness executes after the model responds. The guardrail never sees the wire. This is the inference boundary versus network boundary distinction, and coding agents make it concrete.
Scoped IAM credentials are necessary but not sufficient. Least-privilege tokens shrink the blast radius, but a coding agent legitimately needs broad access to do its job — read the repo, install deps, deploy. A token scoped tightly enough to be safe is often scoped too tightly to be useful, and the agent can still leak whatever it can read.
Sandboxing isolates the filesystem and process tree, but most sandboxes still grant outbound network access so the agent can fetch packages and call APIs. The network path becomes the exfil route. A sandbox without an egress policy is a locked room with an open window.
The egress-control model for coding agents
The reliable posture is default-deny egress with an explicit allowlist. The agent can only reach the destinations you have approved, and every call is inspected, logged, and policy-checked. Agent G sits inline as a drop-in proxy and enforces this at the wire, regardless of which framework or harness the agent runs in.
1. Allowlist the destinations the agent genuinely needs
A coding agent in CI typically needs your package registries (npm, PyPI, your private Artifactory), your VCS host, your model provider's API, and perhaps a handful of internal services. That is a short, knowable list. Everything else is denied by default. An attacker-controlled exfil host is simply not reachable, no matter what the model was tricked into doing.
2. Inspect tool arguments and payloads, not just hostnames
Allowing api.github.com is not enough — you need to know what the agent is pushing and where. Agent G performs deep tool-argument inspection, so a push to an unexpected fork or a payload containing a private key triggers policy. This is the difference between a host-level firewall and an application-aware agent firewall.
3. Scan outbound traffic for secrets
Even on allowed channels, you want to catch credentials leaving. Agent G runs DLP-style normalization on egress to catch leaked API keys and tokens on the way out, including base64-encoded and lightly obfuscated variants that naive pattern matching misses.
4. Gate the irreversible actions with human approval
For high-stakes operations — a production deploy, a database migration, a force-push to main — route the call through a human-in-the-loop approval gate. The agent pauses, a human reviews the exact action, and only then does it proceed. Throughput on routine work stays untouched; the dangerous 1% gets a checkpoint.
5. Log every call as audit evidence
Because Agent G inspects traffic out-of-band from the agent's own process, its logs are trustworthy even if the agent is compromised. You get a complete, tamper-resistant record of every outbound action — invaluable for incident forensics and for proving controls to auditors.
Wiring it into Cursor, Claude Code, and Devin
The deployment pattern is consistent across tools because they all ultimately make HTTP, DNS, and socket calls that you can route through a proxy.
Cursor and local IDE agents: point the agent's runtime — and the shell it spawns — at Agent G via standard proxy environment variables (HTTPS_PROXY, HTTP_PROXY, NO_PROXY) and trust the inspection CA. Now every curl, git, and npm the agent runs is policy-checked.
Claude Code in CI: run the agent inside a network namespace whose only egress route is Agent G. Combine this with the package-registry allowlist to neutralize slopsquatting and dependency confusion in one move.
Devin and hosted autonomous agents: place Agent G as the egress proxy in the VPC or namespace where the agent executes. See our Kubernetes egress filtering guide for the cluster-native pattern and the platform engineer's guide to agent egress for operating it as shared infrastructure.
Because the enforcement happens on the wire, you do not need to modify the agent's code or wait for the vendor to ship a security feature. You control the network the agent lives on.
A concrete failure, contained
Picture a CI job where a coding agent is asked to fix a failing test. A dependency it pulls contains a poisoned README instructing the agent to read AWS_SECRET_ACCESS_KEY and POST it to collect.evil-metrics.io. The model, following its instructions, generates the exfil command. The harness runs it.
With Agent G in default-deny mode, the DNS resolution and connection to collect.evil-metrics.io are denied — that host was never on the allowlist. The attempt is logged with the full request, the policy that blocked it, and the agent identity that made it. Your secret never leaves the runner, and your security team gets an alert instead of a breach notification. The model was compromised; the action was not.
Get started
Coding agents are too useful to ban and too powerful to trust by default. Egress enforcement gives you the middle path: full autonomy on approved actions, hard stops on everything else. Read the Agent G docs to see the proxy and policy model, compare plans on pricing, or request access to put a default-deny boundary in front of your coding agents this week.