The uncomfortable part of autonomous AI agents is not that they can write bad code. Teams already know that. The harder problem is that agents are being placed in workflows where reading untrusted text can turn into executing commands.

AI coding agent behind a security trust boundary

That is the lesson from Friendly Fire, a proof-of-concept exploit brief published by the AI Now Institute on July 8. Researchers Boyan Milanov and Heidy Khlaaf showed a path to remote code execution against Anthropic Claude Code CLI and OpenAI Codex CLI when those tools are used as defensive security reviewers for an untrusted open-source or third-party library.

The setup matters. The attack is not a mass exploit against every Claude or Codex user. It needs a command-capable agent, an untrusted codebase, and an autonomous approval mode: Claude Code in auto-mode or Codex in auto-review, according to AI Now and The Hacker News. In that workflow, the agent is asked to inspect the repository for security issues. It reads ordinary project text, decides what looks relevant, and may run a local command without stopping for a person.

That is exactly why the finding matters for AI practice. The risky workflow is not exotic. Companies are already moving agents into code review, vulnerability triage, Sentry investigation, patch generation, dependency cleanup and CI assistance. The more useful the agent becomes, the more tools it receives. Shell. Filesystem. Browser. Package manager. Repository access. Sometimes secrets.

At that point the agent is no longer a chatbot. It is privileged automation with a natural-language interface.

What Friendly Fire shows

AI Now’s public brief describes a modified copy of the Python geocoding library geopy. The researchers added several files, including a README prompt, a wrapper script, a decoy source file and a precompiled binary. The public GitHub repository says the binary has been stripped of malicious code for release.

The exact payload is not the useful lesson, and it should not be copied into production guidance. The useful lesson is the control failure: the agent treats repository text as part of the task and can move from “analyze this project” to “run this project-supplied command.”

AI Now says the tested configurations included Claude Code CLI versions 2.1.116, 2.1.196, 2.1.198 and 2.1.199 with Claude Sonnet 4.6, Sonnet 5 and Opus 4.8, plus OpenAI Codex CLI 0.142.4 with GPT-5.5. The researchers frame the issue as a workflow design problem rather than a single vulnerable version range.

The Hacker News summarized the same limitation bluntly: there may be no simple patch to wait for if the weak point is the boundary between untrusted content and tool execution.

That does not mean every agent run is unsafe. It means teams need to treat autonomous modes differently from assisted editing. Asking an agent to inspect your own repository in a local branch is one risk. Asking it to inspect arbitrary third-party code with command execution enabled is another.

Why README is enough

Security teams have spent months worrying about MCP configuration files, hooks, plugins and tool manifests. Those are valid concerns. Friendly Fire is more awkward because it does not need a special agent configuration file. It uses normal repository content.

A README is supposed to influence the reader. It tells developers how to build, test and review the project. That is harmless when the reader is a human who can pause, ask whether a command makes sense, and notice that a binary should not run during review.

An agent is different. It is built to be helpful, to infer the next step, and to complete the assignment. If its policy says some commands are safe enough to run, then repository text can become a path from untrusted data to local execution.

This is the same family of problems as prompt injection through support tickets, issues, logs, web pages and tool output. The input is not “code” in the traditional sense. It is text the agent reads while deciding what to do next.

That is why this class of attack keeps reappearing in different clothes.

This is bigger than one PoC

Friendly Fire follows several related reports. Tenet Security’s Agentjacking research described fake Sentry errors injected through public DSNs and then surfaced through Sentry MCP to coding agents. Tenet reported 2,388 exposed organizations and an 85% success rate in controlled testing. Those figures are from Tenet’s own research and should be read as one vendor’s study, not a universal industry rate.

The Hacker News also connected Friendly Fire with TrustFall and other poisoned-repository or tool-output attacks. Sophos X-Ops published a separate operational signal on July 7: AI coding agents in Windows endpoint telemetry can trigger rules normally associated with attacker behavior, including credential access patterns, PowerShell use, LOLBin-style downloads and persistence-like actions.

These are different reports with different methods. They should not be collapsed into one vulnerability. But they point at the same operating problem: an agent can be benign, attacker-influenced or attacker-run, and the process name alone does not answer which one it is.

For a company deploying agents, that is the shift. The question is no longer “is this model good?” It is “what can this agent do when the input is hostile?”

Why businesses will still use agents

The safe answer is not “ban AI agents.” That sounds clean and usually fails.

Agents are already useful for repetitive engineering work. They can reduce toil, write tests, explain unfamiliar code, prepare pull requests and help teams move faster through low-risk changes. In security work, they can summarize findings, compare dependency versions, draft patches and turn messy alerts into a first-pass investigation.

The risk appears when teams grant autonomy before they design boundaries. A junior engineer does not get production credentials on day one and permission to run random binaries from a package they just downloaded. An agent should not either.

The productivity case for agents is real. So is the security cost of pretending that “AI assistant” means “low privilege.”

The new deployment model: read first, execute later

The safest default for untrusted inputs is simple: reading is allowed, execution is not.

If an agent is reviewing a third-party repository, package, issue, Sentry event, log bundle or external pull request, it should begin in read-only mode. It can inspect files, produce a report, list suspicious commands and propose tests. It should not run project-provided scripts, unknown binaries, package installation commands or network calls without an explicit approval step.

That approval should not be a tiny dialog that says “run command?” while hiding the context. The reviewer needs to see why the agent wants to run it, where the instruction came from, what files or network destinations are involved, and what permissions the environment has.

For high-risk tasks, approval alone is still not enough. Run the agent inside a disposable VM or container. Use throwaway credentials. Block access to browser credential stores, SSH keys, cloud tokens and production repositories. Restrict egress. Log tool calls. Delete the environment after the job.

That is not bureaucracy. That is how privileged automation should work.

What teams should change now

Start by separating trusted and untrusted work. Internal repo cleanup, with branch protections and normal CI, can have a different policy from third-party security review. Do not use one global agent setting for both.

Disable autonomous command approval for untrusted repositories and external telemetry. If a vendor offers an enterprise managed setting to block dangerous or auto modes, use it. Claude Code documentation describes managed settings and permission controls for organizations; those are the kinds of controls security teams should own, not leave to individual developers.

Use dedicated agent identities. The agent should not inherit a developer’s full GitHub, cloud and production access by default. Read-only tokens are better than write tokens. Short-lived tokens are better than persistent ones. No token is better when the job does not need one.

Keep secrets out of the agent’s reach. That includes environment variables, SSH keys, browser cookies, password managers and local cloud credentials. A sandbox that still contains the developer’s real credentials is a nicer room for the attacker, not a real boundary.

Treat package installs, shell scripts, binary execution, browser automation and network access as high-risk actions. They should require human approval in untrusted contexts and should be blocked entirely in some workflows.

Make audit logs useful. A security team needs to see the chain: input source, agent reasoning summary, proposed tool call, approved command, process tree, network destination and file writes. Without that, incident response becomes “the AI did something.”

What vendors need to provide

Vendors cannot solve this only by telling users to be careful. Agents need product-level trust boundaries.

Untrusted content should carry a label through the system: repository text, issue comments, logs, Sentry events, web pages, MCP output. Tool policies should be able to say: content from this source may inform analysis, but it may not authorize execution.

The permission model should be explicit. “Autonomous” is too vague. Can the agent run shell commands? Which commands? Can it install packages? Execute binaries? Open network connections? Read hidden files? Access the browser profile? Use MCP tools? Write outside the workspace?

Enterprise admins need central controls, not a wiki page asking developers to behave. They need managed settings, policy enforcement, audit export, allowlists, deny rules and safe defaults for high-risk workflows such as security review of untrusted code.

MCP and tool ecosystems need the same discipline. A tool result is not a system instruction. A log line is not a remediation plan. A ticket comment is not approval to run a command.

The practical maturity test

AI adoption teams often ask which model to standardize on. Friendly Fire suggests a better maturity test.

Can your organization run an agent on a malicious repository without exposing real secrets? Can it stop the agent from executing project-supplied commands? Can it show who approved an action and why? Can it prevent a Sentry event or GitHub comment from becoming an instruction? Can it revoke agent access without disabling the whole development environment?

If the answer is no, the deployment is not ready for autonomous security work.

Agents will become normal parts of software teams. That part seems likely. But normal does not mean harmless. CI runners are normal, and companies still isolate them. Build systems are normal, and companies still lock down secrets. Agents deserve the same treatment.

The practical rule is boring and useful: do not ask whether the agent is trustworthy. Decide what it is allowed to do when the input is untrusted.