On July 8, 2026, researchers at the AI Now Institute published a proof-of-concept exploit called Friendly Fire. It does something specific and uncomfortable: it turns an AI coding agent’s own security review into the attack. Point Claude Code in auto-mode, or Codex in auto-review, at a library laced with the right prompt injection, and the agent will conclude that running an embedded binary is a necessary part of auditing that code. Then it runs the binary. No hooks, no plugins, no MCP server, no special configuration. Out of the box behavior, doing exactly what it was told to do by the thing it was supposed to be inspecting.
The researchers tested it against Claude Sonnet 4.6, Claude Sonnet 5, and Claude Opus 4.8 in Claude Code, and against GPT-5.5 in Codex. The same injection worked across all of them without modification. That transferability is the part worth sitting with. This wasn’t a bug in one model’s training or one tool’s sandboxing. It’s a structural problem with asking an autonomous agent to make trust decisions about code that is actively trying to manipulate the decision-maker.
Why this is different from a normal vulnerability
Most security bugs get patched. A buffer overflow gets fixed, a dependency gets bumped, a CVE gets closed. Friendly Fire is closer to a category error. You’re asking a language model to read text (the source code) and decide whether to execute other text (a binary, a script, a shell command) based on what the first text tells it. When the source code is adversarial, you’ve built a review process where the thing under review gets a vote in its own verdict.
This matters more than it would have two years ago because “have the agent look it over” has become a real step in a lot of teams’ workflows. Vetting a new dependency, reviewing a contractor’s pull request, doing a first pass on an open-source library before it goes into production. All reasonable uses of the tools we build with every day. The problem is that auto-mode and auto-review were designed for trusted code, and teams are increasingly pointing them at code they don’t trust yet, which is the one context those modes were never evaluated for.
Autonomy is the wrong default for anything adversarial
We use AI coding tools daily and we’re not walking that back. They’re faster at a first pass than a human, and for code you already trust, letting an agent execute tests, run linters, and even apply fixes autonomously is a reasonable tradeoff. The mistake is treating that same level of autonomy as safe for code whose author you don’t know and can’t vouch for.
Our rule, and it’s a blunt one: if the code came from outside your team and hasn’t been reviewed by a person yet, no agent gets execution rights on it. Read-only analysis, sure. Summarize it, flag suspicious patterns, diff it against a known-good version. But the moment a security review requires running something to “verify” it, that step goes to a disposable sandbox with no network access and no credentials, reviewed by a person before anything from that run touches your actual environment. That’s not a new idea, it’s the same principle that’s kept us from double-clicking email attachments for twenty years. It just needs to be re-applied now that the thing opening the attachment is an agent with shell access.
This is part of why we treat AI tooling as something to design a workflow around rather than something to switch on and trust by default. Our AI-assisted engineering work is mostly this: figuring out where autonomy earns its keep and where it needs a human gate, then wiring the guardrails in before the tool touches anything sensitive, not after an incident makes the gap obvious.
The accountability question doesn’t go away
Here’s the part that gets skipped in most of the coverage of this exploit: if an autonomous review agent runs malicious code on a build machine and something gets exfiltrated, who’s responsible? Not legally, we’re not lawyers, but practically, inside your own team. “The AI did it” isn’t an incident report. Someone configured that tool to run in auto-mode, someone decided a third-party library didn’t need a human review step, someone chose the sandboxing (or didn’t). Those are ordinary engineering decisions and they deserve ordinary engineering scrutiny, not a pass because a language model was involved.
The teams that come out of incidents like this fine are the ones who already knew exactly what their tools had access to and why. If you can’t answer, right now, which of your build steps run with real credentials and which of your AI tooling can reach the internet unsupervised, that’s worth fixing before your next dependency update, not after.
What we’d actually recommend this week
Audit which of your AI coding tools run in an autonomous mode by default, and check whether that default extends to code you haven’t reviewed yet. If it does, turn it off for that case specifically. Run any first-pass review of external code in a sandbox with no credentials and no outbound network access. And treat “the agent said it was safe” the same way you’d treat a junior engineer saying it: a useful data point, not a decision.
None of this is exotic. It’s the same discipline good teams already apply to unreviewed pull requests, just extended to cover a new kind of reviewer. If you’re building out an AI-assisted workflow and want a second opinion on where the guardrails should sit, get in touch.