Friendly Fire Exploit Shows How AI Coding Agents Can Be Tricked Into Running Malicious Code
A new proof-of-concept attack called Friendly Fire shows how AI coding agents can be hijacked during routine security reviews of third-party code. The attack targets agents with command-execution privileges and can lead to remote code execution on the machine running the agent.
The Friendly Fire exploit brief from the AI Now Institute says the technique works against Anthropic’s Claude Code CLI and OpenAI’s Codex CLI when they review a compromised or malicious open-source codebase in automated approval modes.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The researchers tested Claude Code with Claude Sonnet 4.6, Claude Sonnet 5, and Claude Opus 4.8, as well as Codex CLI with GPT-5.5. The attack used prompt injections hidden in normal repository files, not hooks, plugins, MCP servers, custom configuration files, or special extensions.
What Friendly Fire Does
Friendly Fire turns a defensive AI agent into the execution path for malicious code. The user asks the agent to perform a security review of a third-party library, and the agent follows instructions planted inside that library’s files.
In the demonstration, researchers modified a copy of the open-source geopy Python library. They added a script presented as a security checker, a malicious binary, and a decoy Go source file intended to make the binary look like a legitimate compiled tool.
When the agent reviewed the repository, it read the documentation, inspected the files, treated the security checker as relevant to the task, and executed the binary. That gave the attacker code execution on the host running the AI agent.
| Attack element | Purpose |
|---|---|
| Compromised repository | Gives the agent untrusted source files and documentation to inspect |
| README instructions | Nudges the agent toward a fake security-check workflow |
| Security script | Appears related to code review but launches the payload |
| Decoy source file | Makes the binary look explainable and less suspicious |
| Automated approval mode | Allows the agent to proceed without a normal human approval step |
Why Claude Code and Codex Were Exposed
The issue sits in the way coding agents mix trusted user instructions with untrusted data from a repository. During a review, the agent must read source files, documentation, scripts, and project notes. Friendly Fire abuses that normal behavior.
Anthropic introduced Claude Code auto mode to reduce permission friction while still using a classifier to decide which actions can run automatically. In its Claude Code auto mode explanation, Anthropic said users approved 93% of permission prompts, which created a reason to reduce repetitive approvals.
OpenAI’s Codex has a similar safety concept for certain workflows. The Codex auto-review documentation says auto-review routes eligible sandbox-boundary approval requests through a reviewer agent instead of always stopping for a human decision.
| Tool | Mode discussed in the report | Models tested |
|---|---|---|
| Claude Code CLI | Auto mode | Claude Sonnet 4.6, Claude Sonnet 5, Claude Opus 4.8 |
| Codex CLI | Auto-review | GPT-5.5 |
How the Prompt Injection Was Hidden
The attack did not ask the model directly to run malware. Instead, it placed ordinary-looking security guidance in the repository documentation. The instruction pointed to a local security-check script and made it appear useful for the requested review.
The agent then connected that documentation to the local script and binary. The decoy source file helped the binary appear consistent with a normal development workflow, even though the binary contained the attacker-controlled payload.
AI Now said the same attack worked against Codex without modification after being built for Claude Code. That transfer matters because it suggests the weakness comes from a broader trust-boundary problem in agentic coding workflows, not only from one vendor’s implementation.
- The attack uses normal repository files as the injection surface.
- The user only needs to ask the agent to review the codebase.
- The malicious files do not need to be called by the project’s normal source code.
- The agent can treat attacker-controlled documentation as task-relevant guidance.
- The payload runs on the machine or container hosting the agent.
Why This Matters for Security Reviews
AI coding agents increasingly help developers inspect dependencies, review pull requests, generate fixes, and run tests. Those tasks often require access to untrusted code, which creates a serious risk if the agent can also execute commands.
The Friendly Fire researchers warn that automated dependency-review workflows could trigger this kind of attack without a human seeing the planted instructions. A malicious update to an open-source package could reach downstream teams through normal supply-chain channels, then get reviewed by an AI agent with local execution rights.
The AI Now Institute argues that organizations should avoid using AI agents to ingest untrusted data when those agents can execute arbitrary code or access security-critical environments.
| Use case | Friendly Fire risk |
|---|---|
| Dependency security review | A compromised library may steer the agent into running attacker code |
| Pull request review | Prompt injections may hide in comments, docs, tests, or scripts |
| CI/CD automation | The agent may act before a human reviews the change |
| Security scanning | A fake checker may look relevant to the assigned task |
Sandboxing Helps, but It Does Not Remove the Risk
Sandboxing can reduce damage by limiting what a coding agent can access. However, Friendly Fire shows that the first failure can still happen inside the sandbox if the agent chooses to run attacker-controlled code.
OpenAI’s Codex sandbox documentation describes the sandbox as the boundary that lets an agent act autonomously without giving it unrestricted access to the user’s machine by default.
That boundary still needs careful configuration. If the agent has access to secrets, source repositories, build systems, internal package registries, cloud credentials, or deployment tools, even limited execution can create meaningful exposure.
- Run AI coding agents in disposable containers or virtual machines.
- Keep secrets, tokens, SSH keys, and cloud credentials out of the agent environment.
- Block network access unless the task clearly requires it.
- Use read-only mounts for untrusted source code when possible.
- Log commands, file changes, and network requests from agent sessions.
Human Approval Can Also Fail
Human approval remains useful, but it cannot serve as the only safety layer. Reviewers can become tired by frequent prompts, especially when most requests look routine and the agent already appears to be doing expected work.
Anthropic’s auto mode engineering post discusses approval fatigue as one reason for automated permission decisions. Friendly Fire shows the tradeoff: reducing friction can also reduce the number of moments when a human might stop an unsafe action.

OpenAI’s auto-review guidance keeps the main agent inside the same sandbox boundary, but moves some approval decisions to a reviewer agent. That design can improve workflow speed, but it still depends on correctly separating safe actions from unsafe ones.
What Developers and Security Teams Should Do
Teams should treat AI coding agents as tools that need the same controls as any other system capable of running commands. The main rule is simple: do not point an agent with execution privileges at untrusted code unless the environment can safely absorb compromise.
For open-source dependency reviews, security teams should separate reading from execution. An agent can summarize files, identify risky changes, or prepare a report in a restricted environment before any scripts, tests, or binaries run.
Organizations should also define clear policies for when agents can execute commands, what they can access, and which repositories or package sources count as trusted.
- Disable automated command approval for untrusted repositories.
- Review repository documentation, agent instruction files, and scripts before agent execution.
- Run third-party code reviews in isolated, short-lived environments.
- Use allowlists for commands that agents can run during security reviews.
- Require manual review before executing binaries from a repository.
- Block agents from accessing production credentials and deployment systems.
The Bigger Lesson for AI Agent Security
Friendly Fire highlights a core problem in agentic AI systems: the model must read untrusted data to do useful work, but it may also treat that data as instructions. That trust-boundary failure becomes more serious when the agent can run commands.
The attack also shows why defensive AI tools need more than prompt filters. Security systems must track where instructions come from, whether the source is trusted, what the agent wants to execute, and whether the action matches the user’s real intent.
For now, the safest approach is caution. AI coding agents can help with reviews and security work, but teams should restrict execution rights, isolate environments, and assume that malicious repositories may try to manipulate the agent during analysis. The Codex sandbox model is one control layer, but it should sit alongside environment isolation, strict permissions, and human review for high-risk codebases.
FAQ
Friendly Fire is a proof-of-concept attack that tricks AI coding agents into executing attacker-controlled code while reviewing a compromised or malicious third-party codebase.
The AI Now Institute tested Anthropic’s Claude Code CLI with Claude Sonnet 4.6, Claude Sonnet 5, and Claude Opus 4.8, as well as OpenAI’s Codex CLI with GPT-5.5.
The attack hides prompt injections in repository files such as documentation and supporting scripts. When the agent reviews the codebase, it can treat those instructions as part of the task and run a malicious binary.
No. The reported proof of concept does not require hooks, plugins, MCP servers, skills, or custom configuration files. It uses prompt injections placed in normal repository files.
Teams should avoid running agents with command-execution privileges against untrusted code, use isolated environments, remove secrets from agent workspaces, restrict network access, and require manual review before running repository scripts or binaries.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
User forum
0 messages