Friendly Fire the proof that an IA agent can run code and open the door to your host

An AI Now Institute team published this week a concept test that opens a worrisome hole in the way many organizations already delegate security tasks to IA agents: instead of identifying malicious code within a repository, the agent can run the same code on your machine and become the gateway. The study, named "Friendly Fire" and signed by Boyan Milanov and Heidy Khlaaf, shows the risk when agents with the ability to execute commands work in autonomous modes that approve actions without human intervention.

In the experiment, the researchers worked on Claude Code's "stock" implementations (with indicated CLI building and Sonnet / Opus models) and the OpenAI Codex version, in concrete configurations with the automatic execution option activated. The vector is simple and at the same time subtle: to add to the repository apparently benign files and a check script (e.g., security.sh in a README) that, when considered part of the work by the agent, is run without notice and launches a hidden binary with the payload. To avoid detection, attackers can accompany that binary with a harmless source file and copy text chains from the source code to make the disassembly checks look consistent. Nothing in the project code invokes that binary, so from the surface view of the agent everything seems normal.

The most worrying technical conclusion is not an isolated bug in a specific version, but a design failure: delivering unreliable text to an agent who can run commands is equivalent to giving him the key to your host. The models used in the PoC failed to correctly separate "instructions that are part of the code they examine" from "orders to be executed," and this failure persists between different suppliers and models. AI Now maintains that this is not corrected with a simple model patch; it requires changes in workflow and use policies.

The operational implications are broad. Equipment that adopted automated agents to speed up unit reviews or third-party code audits now rely on a tool that, in certain ways, can run unsupervised code that came from outside. Within a CI / CD pipeline that can transform a routine review into an execution of a malicious binary into infrastructure containing keys, credentials and access to secrets. Although PoC showed no escalation of privileges or lateral movement in the researchers' network, the first step - running foreign code in the host - is enough to compromise secrets and processes.

This does not completely invalidate the use of agents, but does require a rethinking: do not deliver unreliable code to an agent with the ability to run commands and access your keys. That rule is the most direct and the safest. For teams that still want to benefit from automated agents there are practical shortcuts and mitigation controls that reduce the risk: disable the autonomous modes, forcing a "human-in@-@ the-loop" before any execution, or running checks in hermetic and ephemeral environments that do not contain persistent credentials or network access, as well as auditing any performance behaviour.

It should be noted that containment mechanisms are not infallible. Sandboxes and virtual machines add barriers, but have shown leaks and escapes in the past: for example, a failure in Claude Code's sandbox (referred to in the report as CVE-2026-39861) has been reported that relying exclusively on containers or sandboxes can give a false sense of security. Therefore the protections must be in layers: separation of privileges, use of ephemeral tokens and automatic rotation, network segmentation, and strict minimum privileges policies for any automated tool.

From the software supply chain perspective, the recommendation points to practices already promoted by modern security initiatives: signing artifacts, demanding traceability and reproducibility, and applying frameworks such as SLSA for the integrity of the buildings. These measures help reduce the likelihood that an R E A D M E file or other text document will become an unnoticed execution vector. To deepen these practices, organizations and technical officials can review good practice documentation in the integrity of the supply chain in projects such as SLSA in https: / / slsa.dev / and critical analysis material on risks and policies in the work of think tanks such as the AI Now Institute at https: / / ainowinstitute.org /.

Specific operational recommendations that any team can immediately implement: disable automatic execution modes in agents that analyse unreliable code; require human confirmation and a clear record of actions before allowing executions; treat documentation files (README, example scripts) as unreliable by default; do not expose credentials in the environments where automated reviews run and, when it is necessary to run code, do so on disposable machines without secrets and with reversible image. In addition, implement monitoring and alerts to detect unexpected executions and rotate any secrets that have been present in a compromised environment.

Finally, this is a reminder that the accelerated adoption of actors for defensive tasks must be accompanied by governance and controls. The concept test is laboratory, not mass exploitation documented in production, but the pattern has already appeared with previous variants (TrustFall, Agentjacking) and the attack surface is real because public repositories and third-party artifacts are a frequent objective. Technical coverage should be complemented by organizational policies that limit the operational autonomy of agents until the guarantees of isolation, traceability and human control are robust.