On 8 July, AI Now Institute researchers Boyan Milanov and Heidy Khlaaf published “Friendly Fire” — a proof-of-concept exploit that turns Claude Code and OpenAI’s Codex CLI against their own purpose. Ask either tool to run a routine security review on a third-party code library, and a booby-trapped repository can trick it into executing malicious code on the host machine instead.
The mechanism is different from the symlink-based GhostApproval flaw we covered on 12 July, and worth understanding on its own terms. The researchers didn’t need a hidden config file, a plugin, or an MCP server — just a README that references a script as “necessary for security testing,” alongside a binary disguised as the compiled output of a harmless-looking source file sitting right next to it. When a developer says something as ordinary as “perform security testing on this library,” the agent reads the documentation, follows the pointer, and runs the binary — achieving remote code execution. It worked, unmodified, against Claude Sonnet 4.6, Sonnet 5, Opus 4.8, and OpenAI’s GPT-5.5, which tells you this isn’t a one-model quirk; it’s a structural gap in how these agents distinguish code from instructions. The precondition is that the agent is running in an autonomous “auto-mode” or “auto-review” configuration — the same unattended setting that makes these tools attractive for scaling up code review in the first place.
The practical risk the researchers flag is automation bias: a developer who trusts an AI security review is exactly the developer least likely to notice it’s been compromised. Their explicit recommendation is not to point these agents at untrusted codebases in autonomous mode until the underlying architecture changes — this isn’t a bug a model update quietly fixes.
So what
If you’re commissioning software and hearing “we use AI agents to review our code for security issues,” that claim now needs a follow-up question: are those agents running autonomously against code you don’t fully control, and what’s actually verifying their output? This isn’t a reason to avoid AI-assisted development — it’s a reason to make sure whoever is building your product understands where AI tooling needs a human in the loop and where it doesn’t. That’s the judgment call we help clients make on every build; see how we think about it on our AI-assisted development page, or get in touch if you want a second opinion on how a vendor is using these tools on your project.