Friendly Fire: The AI Security Review That Executes the Attack It's Supposed to Catch

You point an AI coding agent at a third-party repository and ask it to check the code for problems before you merge it. That's the job — that's the whole pitch of an "auto-mode" security review. On July 8, 2026, the AI Now Institute published a proof-of-concept called Friendly Fire showing that the review itself can be the attack: prompt injections hidden in ordinary repository files — a README, a comment, a config — can talk the reviewing agent into running attacker-controlled code, during the exact task it was deployed to prevent.

The exploit worked against Anthropic's Claude Code (tested on Sonnet 4.6, Sonnet 5, and Opus 4.8) and OpenAI's Codex CLI (tested on GPT-5.5), out of the box, with no hooks, skills, plugins, or MCP servers required as an injection path. That last detail is the one worth sitting with: this isn't a misconfigured integration or a rogue plugin. It's what happens when an agent with broad execution rights reads untrusted text and treats it as instructions.

How the attack actually works​

The attack chain is almost insultingly simple once you see it laid out:

1. An attacker publishes (or compromises) an open-source repository and plants a prompt injection in a file the agent will naturally read during review — documentation, a code comment, a config file. The injected text describes something plausible: a "security check script" the maintainers supposedly use, or a step the review is "supposed" to include.
2. A developer or CI pipeline points a defensive coding agent at the repo in autonomous mode — Claude Code's auto-mode or Codex's auto-review — and asks it to assess the library for security problems before it's pulled in as a dependency.
3. The agent, reading the repository as data, encounters the injected text and — because nothing in its workflow distinguishes "instructions from the operator" from "text found in the thing being reviewed" — treats it as a legitimate part of the task. Running the referenced script looks like due diligence, not compliance with an attacker.
4. The script executes with whatever privileges the agent's own session already has, and the payload runs. The reviewer becomes the delivery mechanism.

Nothing about this requires a jailbreak, a model bug, or an unusual configuration. The AI Now Institute's brief is explicit that it targeted the default behavior of two of the most widely deployed coding agents on the market, doing exactly the job they're sold for: unattended review of code nobody at the company has vetted yet.

Why there's no patch — and why that's the real story​

Here's the detail that separates Friendly Fire from a routine disclosure: there is no patch. The AI Now Institute frames it as a workflow-design flaw rather than a version-specific software bug, which is precisely why it doesn't fit the CVE model that security teams use to track "fixed in version X." You can't rev a model to make it stop treating repository content as potential instructions — that's a property of how these agents currently read and act on text, not a bounds check that shipped broken.

The Institute's recommended mitigations are correspondingly architectural, not cosmetic:

• Disable unattended autonomous execution modes when reviewing repositories you don't control.
• Require human approval before executing any binary or script surfaced by the review target itself.
• Treat sandboxing as one layer of defense, not a complete fix — a sandboxed agent that still has broad tool access inside the sandbox can still do real damage to whatever the sandbox contains.

It's worth putting Friendly Fire next to a second, related disclosure from the same week to see how representative the pattern is, not just how bad one exploit is. Wiz also published GhostApproval on July 8, 2026 — a symlink-based technique (CWE-61) letting six AI coding assistants (Amazon Q Developer, Claude Code, Augment Code, Cursor, Google Antigravity, Windsurf) write files outside their supposed workspace sandbox, in Wiz's demo by planting a symlink disguised as an innocuous file like project_settings.json that actually resolved to ~/.ssh/authorized_keys. The mechanism is different — path-resolution trickery rather than prompt injection — but the shape is the same: a tool trusted to operate inside a boundary gets tricked into acting outside it, because the boundary was enforced by convention rather than by the tool's own permission model.

The vendor responses split in a way that's itself informative. AWS, Anthropic, Cursor, and Google shipped fixes for GhostApproval; Windsurf's report stayed pending; Augment Code told SC Media it doesn't consider the finding a vulnerability at all. Anthropic's own initial response to GhostApproval called it "outside our current threat model," reasoning that a user who trusts a directory and approves a permission prompt inside it has implicitly accepted the risk. That's a defensible position for a single symlink-escape bug. It's a much shakier one once you place it next to Friendly Fire, where the "permission" a user granted was "go review this untrusted code," and the thing being escaped wasn't a directory boundary but the entire premise that a security review agent won't execute the thing it's reviewing.

What it means for a deploy API that treats an agent as a first-class caller​

This is where the exploit stops being a story about Claude Code and Codex specifically and starts being a design constraint for any platform whose deploy pipeline lets an AI agent act as a caller — which, per bex's own roadmap of MCP-driven, agent-operable infrastructure, is exactly the shape a self-hosted PaaS's deploy gate is heading toward.

The failure mode in both Friendly Fire and GhostApproval is the same one-sentence bug: the tool that reviews or approves a change had the same execution rights as the tool that deploys it. Once an agent doing pre-merge review can run arbitrary scripts, read arbitrary files, or write anywhere its session can reach, "the agent approved this PR" and "the agent has already done whatever it wants to your infrastructure" become the same event. A deploy gate built that way doesn't add a review step — it adds a second, less-audited path to the same blast radius the deploy itself has.

The fix isn't "be more careful" or "sandbox harder" — both are true and both are insufficient on their own, per the Institute's own mitigation list. The fix is scoping what a review agent's tool calls are allowed to be, before the model ever sees the repository:

• Tool-level allow-listing, not blanket repo access. An MCP-style gateway in front of the review step should expose exactly the tools the review needs — read a diff, read specific files, post a comment, flag a finding — and nothing else. Not "the agent has a shell in the repo's working directory." The model should never see an execute-arbitrary-script tool in its context during a review, because a tool that isn't offered can't be invoked by an injection, no matter how persuasive the injected text is.
• Task-scoped capability tokens, not the operator's full credentials. Each review invocation gets a token scoped to that specific PR/repo/task, collapsing what a successful injection can reach even in the worst case — the same task-scoped-token pattern already emerging in MCP authorization designs for exactly this reason. A compromised review session should be able to damage, at most, the sandbox it's reviewing in, not the fleet doing the deploying.
• A separate, audited approval for anything the review target itself wants to run. If a "security script" the repository references genuinely needs to execute — Friendly Fire's actual injection vector — that execution should require a distinct, logged capability grant a human (or a stricter policy) signs off on, never something the review agent grants itself mid-task because the text in front of it said to.
• An audit trail that answers "which agent called which tool, on whose authority, when" for the review step specifically, not just for the deploy it precedes. If the review agent's actions aren't logged with the same rigor as the deploy API's, the platform has a blind spot exactly where Friendly Fire and GhostApproval both landed.

None of this is exotic — it's the same least-privilege discipline a deploy API already needs for its own callers, applied one step earlier, to the review that's supposed to gate what reaches the deploy API in the first place. The mistake Friendly Fire exposes isn't that Claude Code and Codex have a bug. It's that "let an agent look at untrusted code" and "let an agent execute code" were, by default, the same permission. A platform that wants AI agents as first-class operators of its deploy pipeline has to make sure that's never true on its own infrastructure — that the agent doing the reviewing has strictly less reach than the agent (or human) doing the deploying, enforced by the permission model, not by hoping the injected text isn't persuasive enough.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Every agent call against its deploy API goes through the same scoped, audited MCP surface, by design, not as an afterthought bolted on after a disclosure. Star the repo on GitHub or deploy your first app today.

Sources:

• Friendly Fire: Hijacking Defensive Cyber AI Agents for Remote Code Execution — AI Now Institute
• Policy Brief: Friendly Fire — AI Now Institute
• Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It — The Hacker News
• Friendly Fire Bug Hits 2 AI Coding Agents, 0 Patches — Tech Insider
• GhostApproval: AI Coding Assistant Trust Boundary Flaw — Wiz Blog
• GhostApproval technique leads AI coding tools to alter files outside of sandbox — SC Media
• MCP RBAC: Tool-Level Permissions for Production AI Agents — Maxim.