The fastest way to understand AI coding agent security is to accept an uncomfortable fact: the model cannot tell the difference between an instruction you gave it and an instruction hidden in the files it reads. That single property is the root of nearly every serious attack on coding assistants, and it is why a vulnerability disclosed this week let a booby-trapped GitHub repository hand an attacker full control of a developer's machine through Claude Code. This piece explains the threat model behind these attacks, walks through a real example, and lays out the practical safeguards that actually contain the damage.
- Prompt injection works because language models follow instructions found in any content they read, with no reliable way to separate trusted from untrusted text.
- Simon Willison's "lethal trifecta," coined in June 2025, names the three capabilities that turn injection into data theft: private data access, untrusted content, and external communication.
- A repo-based attack on Claude Code, reported this week, executed hidden malware during setup and opened a reverse shell.
- You cannot fully prevent injection at the model layer, so the real defense is containing what an injected agent is allowed to do.
None of this is exotic. The attacks need no memory-corruption exploit, no stolen password, and no bug in the traditional sense. They abuse the agent's normal, intended behavior. That is what makes the topic worth treating seriously rather than as a niche concern for security teams.
What the lethal trifecta means for AI coding agent security
In June 2025, engineer Simon Willison gave the core problem a memorable name in a post on his blog. He called it the lethal trifecta: the combination of three capabilities that, when present together, turn an ordinary AI agent into an exfiltration tool. The three are access to private data, exposure to untrusted content, and the ability to communicate externally.
Each capability is harmless on its own. An agent that can read your private files but has no way to send anything out cannot leak them. An agent that ingests untrusted web pages but holds no secrets has nothing worth stealing. The danger appears only when all three coexist, because then a single poisoned document can instruct the model to read something sensitive and ship it to an attacker. Willison's key insight is that removing any one leg of the trifecta breaks the chain. Two are safe. Three are lethal.
Coding agents tend to acquire all three almost by default. They read your repository, which often contains secrets or sits next to a file full of them, satisfying private data access. They pull in issues, pull request comments, documentation, package metadata, and web content, any of which an attacker can write, satisfying untrusted content. They can run shell commands, hit APIs, and open network connections, satisfying external communication. A general-purpose coding assistant is, almost by construction, a lethal-trifecta machine. That is the structural reason AI coding agent security is hard, and why bolting on a filter after the fact rarely works.
How prompt injection actually works
Prompt injection is the technique that turns the trifecta from a theoretical risk into a working attack. The idea is simple. An attacker writes malicious instructions into some piece of content the agent will read later, then waits for the agent to treat those instructions as if they came from the user. A comment in a source file, a line in a README, the body of an issue, or text returned by an API can all carry the payload.
Because the model processes that text the same way it processes your prompt, it may follow the planted commands. Willison has catalogued real examples affecting Microsoft 365 Copilot, GitHub's own Model Context Protocol server, GitLab's Duo chatbot, and many other production systems. The GitHub case is instructive: one tool could read public issues, which anyone can write, while also reaching private repositories and opening pull requests, so an attacker could plant instructions in an issue and have the agent quietly move private code into a public place.
This is what security people mean when they call prompt injection an unsolved problem. It is not a coding mistake you can patch. The attack surface is the entire information environment the agent works in, since any document or response the model reads could carry hostile text. Defenses that try to detect malicious prompts catch the obvious cases and miss the creative ones, which is why so many practitioners have stopped treating detection as the primary line of defense.
It helps to separate two flavors of the attack. Direct prompt injection is when the user themselves types something adversarial, which matters mostly for systems exposed to the public. The harder case is indirect prompt injection, where the hostile text rides in on content the agent fetches on its own: a web page it browses, a dependency's documentation, or the output of a tool it called. The developer never sees the payload, and neither does any reviewer, because it arrives at runtime. Indirect injection is the variant security researchers describe as hardest to defend, precisely because the agent's usefulness depends on reading exactly the kind of external content an attacker can poison. The more autonomous and well-connected the coding agent becomes, the larger that surface grows, which is the unglamorous tradeoff at the center of every agent deployment.
A real attack: hidden malware in a GitHub repo
The threat stopped being abstract this week. As The Decoder reported, security researchers at 0DIN, Mozilla's generative-AI bug bounty platform, demonstrated an attack that uses a malicious GitHub repository to seize control of a developer's machine through Claude Code. The cleverness is in how it hides.
Rather than storing obvious malware in the repository, the attack ships a setup script that fetches its real commands at runtime from a DNS record. Because the harmful payload lives outside the repo until the moment it runs, it is effectively invisible to scanners, to human code review, and to the AI agent reading the files. When a developer opens the repository with Claude Code, the tool hits a routine-looking error during setup and runs the script to resolve it. That script opens a reverse shell, handing the attacker full access to the machine. From there the intruder can lift API keys and credentials and establish a lasting foothold.
The social engineering required is minimal. An attacker only has to get someone to open the repo, which a link in a job posting, a tutorial, or a chat message accomplishes easily. The researchers' recommended fix is exactly what the trifecta framing would predict: agents should show the contents of a setup script before running it, and developers should treat any third-party repository's setup instructions as untrusted code that needs manual review. The deeper lesson is that an AI coding agent quietly executing repository initialization steps is making a dangerous trust assumption on the developer's behalf.
The attack above did not break Claude Code's permission model so much as exploit the developer's willingness to let an error get auto-resolved. The same pattern threatens every coding agent that can run shell commands. Treat the example as a property of the category, not a flaw in one product.
Why guardrails alone will not save you
A tempting response is to buy a product that promises to block prompt injection. Willison is openly skeptical of that approach, warning that guardrails marketed with high prevention rates still leave a gap, and a defense that stops 95 percent of attacks is not much comfort against an adversary who only needs to succeed once. Filtering helps at the margins, but it cannot be the foundation, because the model's inability to separate trusted from untrusted text is a property of how these systems work, not a setting you can toggle off.
The more durable framing, echoed across security writing this year, is that you cannot reliably prevent injection but you can contain its blast radius. The fix lives at the execution layer, not the model layer. If an injected agent can only act inside a disposable sandbox, can only reach an allowlisted set of destinations, and cannot take consequential actions without a human saying yes, then a successful injection becomes an annoyance rather than a breach. The goal shifts from stopping the attacker's words from reaching the model to stopping the model's compromised actions from reaching anything that matters.
This is the same reliability problem that haunts agents more broadly. As the research on whether agents can act as dependable coworkers makes clear, the gap between a system that sounds capable and one you can trust to act unsupervised is wide, a theme explored in our piece on whether AI agent coworkers are real. Security is one sharp edge of that same gap.
7 practical safeguards for AI coding agent security
None of the following is a silver bullet, and the honest position is that no single control closes the risk. Layered together, though, they turn a catastrophic injection into a contained one. Think of them as defense in depth for an agent you have decided to run anyway.
1. Break the lethal trifecta
The most reliable control is also the simplest: do not let one agent hold all three dangerous capabilities at once. If an agent needs to read untrusted content, deny it access to secrets, or cut off its ability to send data outbound. Willison's own advice to people wiring tools together is to avoid combining the three legs in a single context. In practice that can mean running untrusted-input tasks in a throwaway environment with no credentials, or splitting a workflow so the part that reads the web never touches the part that can exfiltrate.
2. Sandbox and isolate execution
Run the agent where it can do little harm. Guidance from infrastructure vendors such as Northflank describes layered isolation using microVMs, gVisor, or hardened containers, so that code the agent executes lands in a disposable boundary rather than on your real machine. A sandbox that resets between tasks means a reverse shell opened by a malicious setup script connects to nothing worth having. Isolation does not stop the injection, it makes the injection's success irrelevant.
3. Require human approval for consequential actions
For anything with real-world stakes, put a person in the loop. Sending email, moving money, deploying code, or writing to a production database should each demand explicit confirmation. A guide from TrueFoundry on Claude Code in enterprise settings makes the point that mandatory tool confirmation is among the strongest structural defenses, because it inserts a break in the automated chain that the model cannot talk its way past. An injected instruction can convince the model to attempt an action, but it cannot click the human's approve button.
4. Scope permissions to least privilege
Give the agent the narrowest set of permissions the task needs and nothing more. An assistant fixing a frontend bug does not need production database credentials or the ability to push to every repository. Scoped tokens, read-only access where writes are not required, and short-lived credentials all shrink what an injection can reach. The trifecta teaches that capability is the danger, so the fewer capabilities an agent carries into untrusted territory, the smaller the attack.
5. Treat all repository content as untrusted
Adopt the mindset the 0DIN researchers recommend. Any repository you did not write, and any file an outside party can influence, is untrusted code until proven otherwise. Configure the agent to display setup scripts and shell commands before it runs them, and read them. The friction is real, but it is the friction that would have stopped this week's attack cold. A setup script that phones a DNS record for its instructions should never run unseen.
6. Restrict network egress
Control where the agent can send data. An allowlist of permitted destinations, or a default-deny network policy in the sandbox, removes the third leg of the trifecta even when the other two are present. If the model is tricked into reading a secret, an egress rule that blocks unknown hosts means it has nowhere to send the loot. Network controls are among the least glamorous and most effective parts of agent security, because exfiltration needs a route out.
7. Monitor, log, and be ready to roll back
Assume something will slip through and instrument for it. Log the tools the agent calls, the commands it runs, and the destinations it contacts, then review anomalies. Output monitoring can catch an agent suddenly trying to reach an unfamiliar host or read files outside its task. Pair logging with a clean way to revert changes, so a compromised session can be undone rather than excavated. Detection is a weak first line but a strong last one.
Research-backed directions worth watching
Beyond the operational controls, a few research approaches aim at the problem more fundamentally. Willison points to design patterns that deliberately limit what an agent may do after it has ingested untrusted input, restoring a kind of separation the model itself lacks. He also highlights the CaMeL approach from Google DeepMind, which treats the untrusted text as data to be handled rather than instructions to be obeyed, building the trust boundary into the system around the model instead of hoping the model enforces it.
These ideas share a philosophy with the safeguards above. They accept that the model will keep following instructions in whatever it reads, and they put the security boundary somewhere the model does not control. That is the throughline of serious agent security work right now. Stop asking the model to police itself, and architect the system so that a fooled model cannot do much damage. The model is the part you cannot trust, so it should not be the part holding the keys.
Securing agents without giving up on them
The point of all this is not to scare developers away from AI coding agents. They are genuinely useful, and the productivity gains are real enough that abstinence is not the answer for most teams. The point is to run them with clear eyes. An agent that reads untrusted content, holds secrets, and can reach the network is a loaded tool, and this week's Claude Code attack is a concrete reminder of what happens when all three line up without containment.
Good AI coding agent security comes from accepting the model's limits and designing around them. You cannot make a language model immune to prompt injection, but you can sandbox its execution, scope its permissions, gate its consequential actions behind a human, and box in where it can send data. Break the lethal trifecta wherever you can, and contain it everywhere you cannot. Do that, and an injection becomes a contained incident in a disposable environment rather than a stranger with a shell on your laptop. The technology is worth using. It is just not worth trusting blindly, and the difference between those two stances is the whole of agent security.