TL;DR

AI Now Institute's Friendly Fire exploit shows that defensive AI coding agents can be manipulated into executing attacker-controlled code while reviewing an untrusted repository. The attack was demonstrated against Anthropic Claude Code and OpenAI Codex CLI when used in autonomous approval modes: Claude Code auto-mode and Codex auto-review. The exploit does not require MCP servers, plugins, hooks, skills, or special configuration files. It uses ordinary repository content such as documentation and source-adjacent files to steer the agent into running a script or binary as part of a supposed security review.

The core issue is not simply "bad code in a repo." The real failure is that an AI agent reviewing untrusted code can treat repository text as operational instruction, convert that instruction into tool use, and execute it on the user's machine. Our independent validation strengthens the finding: by injecting instructions into a README that caused the agent to execute a bash script, download a remote Python file, and run it under allow all permissions, we confirmed the same class of failure in a practical agent workflow.

The Core Attack Pattern

AI Now's researchers published a proof-of-concept showing that AI agents used for defensive code analysis can be turned into the attacker's execution mechanism. The tested scenario was straightforward: a user asks an AI coding agent to perform security testing on a third-party or open-source codebase. The codebase contains prompt injections placed across normal project files. The agent reads those files, interprets the embedded instructions as relevant to the task, and executes attacker-controlled logic.

The researchers tested Claude Code CLI versions 2.1.116, 2.1.196, 2.1.198, and 2.1.199 using Claude Sonnet 4.6, Sonnet 5, and Opus 4.8, as well as OpenAI Codex CLI 0.142.4 using GPT-5.5. The attack succeeded in the tested autonomous configurations, where an AI classifier allows commands considered safe and pauses only for commands considered sensitive.

The demonstrated attack used a modified copy of the geopy Python library. The malicious instructions were placed in documentation-like content, including references to a security script. When the agent was asked to perform security testing, it discovered the repository guidance, inferred that the script was part of the security review, and executed the payload path.

The attacker did not need to compromise the model, exploit a traditional memory corruption bug, or abuse a special agent extension. The attacker weaponized the repository itself.

The attack pattern was:

1. Place seemingly legitimate security-review instructions inside repository content.
2. Reference a helper script or binary as if it were part of normal project security testing.
3. Allow the agent to discover the instruction during code review.
4. Let the agent reason that executing the script is aligned with the user's request.
5. Rely on autonomous command approval to run the attacker-controlled payload.

In AI Now's proof-of-concept, the repository content steered the agent to execute a script or binary. In our validation, the same pattern was confirmed with a README instruction that led the agent to execute a bash script, download a remote Python file, and execute it when the agent permission mode was set to allow all.

That validation is important because it shows the attack does not depend on the exact AI Now payload structure. The broader failure mode is: untrusted repository text can become agent instruction, agent instruction can become tool invocation, and tool invocation can become host-side code execution.

The Attack Progression Across the AI Kill Chain

1. Reconnaissance — Active. The attacker targets workflows where agents review untrusted repositories with autonomous command execution enabled — mapping the tool surface available to the agent before ever placing a payload.
2. Trust Manipulation — Active. Malicious instructions are placed in normal project files such as README content and made to look like legitimate security-review guidance, abusing the implicit trust an agent extends to ordinary repository documentation.
3. Input & Instruction Weaponization — Active. The repository carries instructions that influence the agent during code review without requiring plugins, MCP servers, or config-file abuse — instruction smuggling through ordinary project text.
4. Reasoning-Time Execution — Active. The agent reasons that running the referenced script is part of the user's requested security assessment, substituting the attacker's embedded goal for the review task it was actually asked to do.
5. Tool Invocation — Active. The agent invokes shell execution based on instructions discovered in repository content, bypassing the boundary that should separate "reviewing" from "running."
6. Privilege Escalation — Active. Under broad permission modes such as allow all, the agent can execute commands without meaningful human gating — credential and authority overreach granted to the AI itself.
7. Lateral Movement — Bypassed entirely. Not demonstrated in the reporting. If the host contains secrets, SSH keys, repo tokens, or cloud credentials, the executed payload could move beyond the initial repository context — but this step was not exercised in the tested proof-of-concept or in our validation.
8. Persistence — Active. Persistent project files such as CLAUDE.md, agent.md, or modified documentation could preserve malicious instructions across future sessions. AI Now notes that variants using CLAUDE.md or agent.md also succeeded, extending the dependency/supply-chain abuse beyond a single session.
9. AI Native C2 — Bypassed entirely. Not demonstrated as a full command-and-control channel in the reporting, though the mechanism was present: a malicious script downloaded a remote Python file and executed it, showing how the agent's tool access could become a remote payload delivery channel if extended further.
10. Action on Objectives — Active. The final objective is remote code execution on the machine running the defensive AI agent. AI Now's brief describes this as RCE through review of a malicious or compromised third-party codebase.

The Difference with Traditional Systems

In a traditional code review workflow, a README is inert documentation unless a human decides to follow it. In an agentic workflow, that same README can become operational context. If the agent has shell access and broad approval permissions, documentation can influence execution.

This is why Friendly Fire is different from ordinary malicious packages or dependency attacks. The malicious code does not need to be imported by the application, called by a build system, or triggered by package installation. The agent itself can become the execution bridge. AI Now specifically notes that the attack does not require hooks, skills, plugins, MCP servers, or configuration files as the injection vector.

The failure is also not limited to one vendor or one model. AI Now reports that an exploit initially developed for Claude Sonnet 4.6 also succeeded against Claude Sonnet 5, Claude Opus 4.8, and GPT-5.5 without further changes. In some cases, newer models noticed inconsistencies in files but still executed the payload path.

Why This Worked

Friendly Fire works because agentic security review collapses three things that traditional systems try to keep separate: untrusted data, trusted instruction, and execution authority.

The agent is asked to review untrusted code. To perform that job well, it must read project files, documentation, scripts, and source code. But once those files enter the model context, malicious repository text can compete with the user's original instruction. If the agent also has command execution access, the attack moves from prompt injection to operational compromise.

The dangerous chain is:

Untrusted repository → model context → reasoning drift → shell invocation → payload execution

Our validation confirms the most dangerous version of this pattern:

README instruction → bash execution → remote Python download → remote Python execution → allow-all permission abuse

That is the security boundary failure. The model did not merely produce a bad answer. It converted untrusted text into host-side behavior.

How to Prevent This Class of Attack

The primary mitigation is not better prompting. The primary mitigation is reducing what the agent is allowed to do with untrusted content.

Recommended controls:

• Do not run command capable agents against untrusted repositories in unrestricted or allow-all modes.
• Treat repository documentation, comments, tests, scripts, markdown, and agent instruction files as untrusted input.
• Require explicit human approval before executing any script, binary, package manager command, curl/wget download, interpreter invocation, or shell pipeline discovered from repository content.
• Run agent reviews inside disposable, network-restricted sandboxes with no host secrets, no SSH keys, no cloud credentials, and no persistent developer tokens.
• Block outbound network access by default during repository review unless explicitly required and approved.
• Detect and alert on agent-initiated execution paths such as bash, sh, python, node, curl, wget, package installers, and downloaded artifacts.
• Prevent agents from executing files referenced only by documentation unless a separate policy engine validates the action.
• Separate "read-only review" mode from "execute/test/fix" mode.
• Log all agent tool calls, command arguments, working directories, spawned processes, network calls, and downloaded artifacts.
• Add policy checks that specifically detect instructions embedded in README, comments, markdown, tests, examples, and agent memory files.

The most important control is simple: untrusted content may be read by the agent, but it must not be allowed to authorize execution.

This traces back to policies Lineaje already enforces around agent trust and instruction handling: prompt injection — whether hidden in plain text, encoded, disguised through leetspeak-style obfuscation, or arriving through user input, uploaded files, retrieved content, or other external sources — should never be allowed to silently steer an agent's behavior. Just as importantly, any high-risk command an agent surfaces on its own, the kind Friendly Fire relied on to reach execution, should require a human to sign off before it runs rather than the agent's own judgment alone.

Lineaje UnifAI policies: AI_APP_SEC_001, AI_APP_SEC_002, AI_APP_SEC_032, AI_APP_SEC_066, AI_APP_SEC_070

Friendly Fire, Unfriendly Outcome

Friendly Fire shows that defensive AI agents can become offensive execution paths when they are allowed to reason over untrusted content and act autonomously on the host. The attack does not require a novel exploit chain, a malicious MCP server, or a compromised plugin. It only requires the agent to read attacker-controlled repository content and have enough permission to act on it.

Our validation makes the risk even more concrete. A README instruction was enough to drive bash execution, remote Python download, and execution when the agent was granted allow-all permission. That is not just prompt injection. It is instruction to execution drift, and it leaves us with one clear takeaway: the agent reviewing the code must not become the mechanism that runs the code.