Research on “Friendly Fire” shows AI agents can be tricked by prompt injections in repo docs into executing malicious binaries and causing RCE.
According to a research summary reposted by TWCERT/CC, researchers at the AI Now Institute proposed a proof of concept (Proof of Concept, PoC) called “Friendly Fire,” demonstrating how attackers can use an AI agent’s reasoning and tool-calling capabilities to turn a defensive workflow originally used for cybersecurity detection into part of an attack chain, ultimately leading to Remote Code Execution (RCE)[1].
The key issue in this research is not a single vulnerability, but a “misplaced trust boundary.” The attacker first inserts a malicious binary into a code repository and disguises it as a legitimate cybersecurity detection component; then, they add guiding text to project documentation that developers frequently read, inducing the agent to execute the file on its own[1]. When the AI agent runs the file according to the text prompt, it effectively turns the defensive check into an execution entry point for the malicious program[1].
TWCERT/CC views this scenario as a new kind of “friendly fire” risk: the tool is originally on the defensive side, but because data and instructions are mixed together, permissions are too broad, and source verification is lacking, it is manipulated in reverse by the attacker[1].
The core technical point of Friendly Fire is placing “natural language instructions” and “executable content” on the same decision plane, causing the AI agent to treat suggestions in documentation as operational commands when the system is not sufficiently strict[1]. This kind of design is common in generative AI and agent architectures: the model reads repository contents, summarizes risks, selects tools, and then executes files or commands; but if mandatory source verification and permission isolation are missing, the agent may treat attacker-embedded content as trusted data[1].
From the attack chain perspective, the first stage is “content poisoning.” The attacker does not directly compromise the target host, but instead poisons the project repository so that malicious files coexist with normal code and documentation[1]. The second stage is “behavioral inducement.” Project documentation that is commonly read first is well suited for inserting seemingly reasonable text that actually provides execution guidance[1]. When the agent follows the prompt and executes the file, the malicious binary gains an execution opportunity and can further trigger RCE[1].
The danger of this method is that it does not rely on the signature-based malware characteristics that traditional vulnerability scanners can easily detect, but instead exploits the AI system’s design assumption that it “trusts context.” In other words, the attack surface is not a single CVE, but the agent’s workflow, permission configuration, toolchain integration, and human-machine collaboration habits[1]. Once the agent is allowed direct access to the file system, shell commands, or external tools, the attacker only needs to make it “willingly” perform a dangerous action to complete the compromise[1].
More importantly, this reflects the dual nature of AI defensive tools themselves: they can help analyze malicious files, but they can also become manipulable executors[1]. Therefore, the issue is not just whether AI “misreads” something, but whether the system allows AI to take high-risk actions directly without verifying inputs[1].
Those affected first include teams that use AI agents for code review, malware analysis, CI/CD assistance, document summarization, or automated operations[1]. These scenarios often allow agents to read repository contents and even automatically run tests, scans, or remediation workflows; if access control is not properly enforced, attackers may be able to directly manipulate the execution path through repository content[1].
Second are enterprise environments that use “multi-tool orchestration.” When an agent can call shell commands, download files, execute scripts, query APIs, or modify project documentation, any one of those steps may become an attack surface[1]. This is especially true in cases where agents are connected to development pipelines, weakly isolated sandboxes, or shared workstations; without the principle of least privilege, a single malicious file can spill over into a higher-privilege environment[1].
In addition, this attack also affects cybersecurity governance. The traditional assumption behind defensive tools is that “the detector is trusted,” but Friendly Fire shows that the detection workflow itself can be injected with malicious guidance, causing an enterprise to believe it is performing a security scan when it is actually executing unauthorized code[1]. For large organizations, this introduces supply chain risk, internal lateral movement risk, and audit issues that are difficult to trace after an automated system is abused[1].
TWCERT/CC recommends that enterprises and development teams build defenses from four aspects: “data isolation, privilege reduction, execution verification, and behavior monitoring”[1]. First, untrusted content must be separated from agent instructions, and project documentation or external submissions should not be treated directly as execution basis[1]. Second, the principle of least privilege should be implemented, and sensitive environments should be isolated from general analysis environments to reduce the blast radius after accidental execution by the agent[1].
Third, the tools and commands the agent can call should be restricted, especially high-risk operations such as shell execution, file writing, privilege escalation, and network connections; a whitelist mechanism is preferable to unrestricted access[1]. Fourth, pre-execution checks and file source verification mechanisms should be established, such as signature verification for executables, source path comparison, and hash validation, to prevent the agent from treating disguised files as trusted components[1].
Finally, enterprises should monitor abnormal AI agent behavior, including unusual tool calls, unexpected path execution, repeated attempts on unknown files, or sensitive operations initiated at non-standard times; at the same time, multi-layer isolation such as containerization, read-only mounts, restricted network segments, and review workflows should be used to reduce cascading risk caused by a single point of failure[1]. For cybersecurity teams, the focus is not only on making AI “work,” but on ensuring it works only within verifiable, traceable, and stoppable boundaries[1].
5-Step Remediation Checklist