What are the security risks of AI coding agents?
The security risk of an AI coding agent is not the model. It is the combination of three capabilities in a single process: the agent reads your private data, it reads content an attacker controls, and it can send data out. Each one is routine. Together, one poisoned input can turn your coding agent into a data breach. A coding agent that opens a project can read a secrets file, pull in a poisoned README from a repository you do not control, and run shell commands. That is the whole risk in one sentence.
The harder problem is how these systems arrived. Almost none of them came through architectural review. They showed up bottom-up, on developer laptops and in CI pipelines, faster than the engineering discipline required to run them safely. We assess agent environments for a living, and the pattern is consistent: capable agents in production with none of the containment that mature teams apply to every other system. This is a maturity gap, not a knowledge gap. The controls are well understood. They are simply absent.
This guide gives you one lens for seeing the risk clearly, and four engineering disciplines that close it.
The lethal trifecta is the lens
Simon Willison, the developer who coined the term prompt injection, calls it the lethal trifecta: three capabilities that are individually common and dangerous only in combination.
- Access to private data. Secrets, customer records, internal documents, source code.
- Exposure to untrusted content. Attacker-controlled text or images entering the agent's context.
- An exfiltration channel. Network calls, messages, file writes, or tool use that can carry data out.
Here is the load-bearing part. A large language model cannot reliably tell instructions from data. Any content the agent reads can be interpreted as a command. So when all three legs are present, a poisoned input can tell the agent to collect private data and send it somewhere. This is demonstrated, not theoretical.
The reframe that makes it tractable: the trifecta is a design choice, not a fact of nature. Every architectural decision either widens it or narrows it. You do not need a perfect model. You need a system where the three legs never converge without a control in between.
Where the risk actually lives
The trifecta assembles in three layers, each in its own way.
In the development lifecycle, coding agents, AI-assisted code review, CI/CD agents, and data-science notebooks each combine private data, external content, and execution. Most coding agents offer sandboxing, but it ships opt-in. As of mid 2026, only OpenAI's Codex enables it by default.
In the software supply chain, the risk is hardest to see. Community Model Context Protocol (MCP) servers are unaudited third-party code handed real credentials, and the tool descriptions themselves are a prompt-injection surface, because the model treats that text as instructions. AI-assisted dependency updates ingest changelogs an attacker can control. RAG systems index internal wikis next to customer tickets and public documents with no trust boundary. OWASP's 2025 Top 10 for large language models now lists supply chain as a top risk category.
At the organization level, shadow AI is the new shadow IT, except worse, because an AI system acts on data instead of only storing it somewhere it should not be. The risk to watch is compositional. Agent A reads your pipeline and ingests market reports but cannot send data out. Agent B sends email but has no access to private data. Each passes its own review. Connect them and the composite has all three legs. No per-system audit catches this.
The four disciplines that close the gap
Each discipline maps to a leg of the trifecta. None of them requires slowing adoption. They are the controls mature teams already run on every other production system, extended to agents. Each links to a deeper breakdown.
Network egress control breaks exfiltration
Default-deny outbound access for every agent environment, with allowlists scoped per agent and per task. Block the cloud metadata endpoint at 169.254.169.254 explicitly, because reaching it hands over host credentials. NVIDIA's red team, OWASP, and Microsoft treat egress control as mandatory. If data cannot leave, it cannot be exfiltrated. Full breakdown
Sandboxing limits the blast radius
Make the execution environment a containment boundary so a compromise stays contained. Shared-kernel containers are not enough for adversarial workloads. Firecracker, Kata, or gVisor give you real isolation. Most teams have isolation available and switched off, which makes flipping that default one of the highest-return moves you have. Full breakdown
Architectural trust boundaries disarm the injection
If you cannot remove a leg, architect the system so the legs never converge in one step. The dual-LLM, or split-context, pattern does this: one model call reads the untrusted content and emits validated, structured data, and a separate call that holds the tools and the private data only ever sees that validated output. Scope tools to least privilege. Gate irreversible actions with a human. Full breakdown
Observability catches the composition
You cannot secure what you cannot see, and the most dangerous flaws live between systems, not inside them. Start with an inventory: what agents run, what each one accesses, what untrusted content reaches it, what it can do. Instrument every agent-to-agent handoff with trust provenance. Then run the compositional question across the graph: does untrusted content entering one system reach an action channel in another? Full breakdown
What this means if you run agents in production
The question is no longer whether your organization runs agentic systems. It is whether anyone understands the risk profile of the ones already in production. Four shifts define maturity. Treat the trifecta as a design constraint, not a review finding. Enforce containment programmatically, not by policy. Reason about composition, not only components. Instrument agent boundaries like service boundaries. None of it is aspirational. These are defaults, not aspirations.
Frequently asked questions
What is the biggest security risk of AI coding agents? Three capabilities combining in one process: access to private data, exposure to untrusted content, and a way to send data out. Individually routine. Together, a poisoned input can instruct the agent to collect private data and exfiltrate it. Simon Willison calls this the lethal trifecta.
What is prompt injection in the context of coding agents? It is when attacker-controlled content the agent reads, such as a README, a changelog, an issue comment, or an MCP tool description, gets interpreted by the model as an instruction. Because a language model cannot reliably separate instructions from data, anything it ingests can become a command.
Are AI coding agents sandboxed by default? Mostly not. Sandboxing is typically opt-in. As of early 2026, only OpenAI's Codex ships with it enabled by default. In most environments, isolation is available and switched off.
How do you secure an AI coding agent without slowing development? Apply four disciplines: default-deny network egress with per-task allowlists, execution sandboxing with kernel-level isolation for adversarial workloads, architectural trust boundaries that separate untrusted reads from tool-using actions, and observability across agent boundaries. The work is decomposing the real dependency graph so the controls are tight without breaking the workflow.
What is the lethal trifecta? A framework from Simon Willison describing three agent capabilities that are dangerous only in combination: access to private data, exposure to untrusted content, and an exfiltration channel.
Where to start
If you run coding agents in production, start with the inventory. Which agents run, what each can access, what untrusted content reaches them, and what they can do. Most teams cannot answer that today, and the gaps are exactly where the trifecta converges unseen.
Stride is an AI-native engineering firm. Since 2014 we have helped enterprises in regulated industries move from AI experimentation to production-grade systems. Our agent security work is hands-on: we assess where untrusted content enters and propagates, build egress and sandboxing controls into agent environments, design trust boundaries that hold in production, and stand up observability across agent systems.
For the full framework, including a maturity self-assessment you can run against your own environment, download The Agentic AI Security Maturity Guide. Download the guide.
