A proof-of-concept published today by the AI Now Institute demonstrates something that changes the risk calculus for any organisation deploying AI coding assistants: when you ask an AI coding agent to audit a third-party repository for security vulnerabilities, the attacker who planted code in that repository may be able to execute their malware on your developer’s machine — using the agent itself as the delivery mechanism.
The researchers named it Friendly Fire. Anthropic and OpenAI were notified before publication. Neither has issued a patch. The AI Now Institute says there is nothing to patch.
What the Attack Does
The attack targets one specific, increasingly common use case: a developer instructs an AI coding agent to scan an unfamiliar open-source repository for security issues. This is exactly the kind of task organisations adopting AI assistants are using them for — not just code generation, but code vetting.
The malicious repository contains a binary disguised as the compiled output of a legitimate Go source file. Embedded strings from the Go file make it look credible on disassembly. The trigger is a single line in the README: a note suggesting that a security check script should be run before opening a pull request.
The agent reads the README, interprets the instruction as legitimate, and executes the binary. The payload runs on the developer’s host. The whole sequence takes under a minute.
Why This Is Difficult to Defend Against at the Tool Level
Earlier prompt injection attacks on AI coding agents exploited specific configuration file formats — .mcp.json, .claude/settings.json. Anthropic responded with trust prompts when agents encountered these files. Friendly Fire uses README.md, a plain text file present in virtually every open-source project, which receives no special scrutiny and triggers no warnings.
More significantly: when researchers asked Claude Sonnet 4.6 and GPT-5.5 directly whether the repository contained hidden instructions, both said no. The newer models, in some test runs, actually identified that the binary did not match the claimed source file — and then executed it anyway. The agent’s judgment about the legitimacy of the instruction failed even when its factual analysis of the artefact was correct.
The same payload worked unchanged against Claude Sonnet 4.6, Claude Sonnet 5, Claude Opus 4.8, and GPT-5.5. One malicious repository, four models, two vendors. This consistency is what makes the AI Now Institute’s harder claim credible: the vulnerability is not in any particular model’s fine-tuning or system prompt. It reflects a shared structural problem in how these agents handle untrusted text — the inability to reliably distinguish text they are reading from instructions they are meant to follow.
What This Means for CISOs
This affects your developer workstations, not your production systems. The immediate impact of a successful Friendly Fire attack is code execution on a developer’s machine in the context of the user running the agent. That’s meaningful but bounded — it’s not an immediate path to production compromise unless the developer has elevated privileges or credentials accessible from their workstation. Your risk profile depends significantly on how privileged your developer laptops are.
It extends a supply chain risk you should already be modelling. Developers running malicious packages, opening malicious repositories, or acting on social engineering are already in scope for most enterprise security programmes. Friendly Fire is a new delivery mechanism for a known threat category, not an entirely new category of risk. The change is that the agent automates execution steps that previously required the developer to read and deliberately act on instructions.
There is no patch timeline. The AI Now Institute frames this explicitly as a design-level weakness. Anthropic’s three patches for configuration-file injection over the past six months did not help — Friendly Fire bypasses all of them by using a different file type. Model updates cannot fix the underlying problem, which is architectural.
Immediate Actions
1. Restrict autonomous agent access to untrusted repositories. The AI Now Institute’s practical guidance: don’t point a command-capable AI agent in autonomous mode at a repository you don’t control. This removes most of the automation value but eliminates the specific attack surface. If code review of untrusted repositories is a genuine business need, it should be flagged as requiring human oversight at each execution step.
2. Audit which AI coding tools in your environment run in autonomous mode by default. Claude Code’s auto-accept mode and Codex’s auto-review mode are specifically called out. Both allow agents to execute commands without per-step approval. Review your organisational configuration and policy.
3. Require sandbox isolation for any autonomous agent work. Running agents in a well-isolated sandbox limits what an executed payload can do. This is meaningful mitigation — Claude Code has had sandbox escape bugs this year, so a sandbox is not a guarantee, but it substantially raises the cost of a successful attack.
4. Include AI coding agents in your developer endpoint threat model. Agent activity should be visible in your EDR telemetry. Suspicious process creation from the agent process, unexpected outbound connections, and modifications to sensitive files should generate the same alerts as the same behaviour from any other process. If your EDR excludes agent processes from policy, correct this.
5. Track the policy and tooling response from Anthropic and OpenAI. Neither vendor has indicated when or whether a technical mitigation is possible. The CISO function should monitor vendor communication on this issue and reassess as the landscape evolves.
Broader Context
Friendly Fire is the fourth distinct attack vector against AI coding agents published in 2026. TrustFall in May used symlinks and configuration files. Agentjacking used a fake bug report in an error tracking platform. GhostApproval (also published today by Wiz) uses symlink tricks to display incorrect filenames in approval dialogs. The pattern across all four is the same: untrusted text reaches an agent that can run commands, and the agent runs them.
The US executive order from June 2026 that encourages organisations to use AI agents in defensive security roles — including code auditing — creates a direct irony here. The agents pushed into a security function are themselves a security risk when pointed at untrusted code. That tension is worth documenting in your risk register.
The risk is manageable with the controls above. But it is real, it exists in current deployment versions, and there is no patch timeline. Add it to your current threat model accordingly.