By Sarah Reid, Securetron. I work at Securetron, and this article explains research into a prompt-injection technique affecting AI coding agents — and the controls that help stop it.
AGENTS.md was meant to make coding agents more useful. Put project instructions in one file, and the agent follows them: how to build, how to test, where the code lives, and which commands are safe. That convenience is exactly what makes the file interesting to an attacker. If an agent treats AGENTS.md as trusted instructions, then whoever controls that file can steer the agent.
That is the core finding in research reported by Forever Security. In its testing against Codex, the reported success rate was over 90%. That number deserves careful reading: it describes success in the researchers' test setup, not a measured rate of compromise in the wild. It is still a warning worth taking seriously, because the failure mode is not a bug in one model. It is a trust problem in how agents consume context.
How the hijack works
A coding agent does not usually ask whether AGENTS.md should be trusted. It reads the file as part of its working context, then acts on it. A malicious or tampered AGENTS.md can therefore do what a normal instruction file does, only with a different goal:
- The agent opens a repository and loads AGENTS.md automatically.
- The file contains instructions that look like ordinary project guidance — run a setup step, use a particular tool, or follow a workflow.
- The agent follows the instructions, including tool calls, shell commands, or requests that a careful human reviewer would question.
- If the agent has access to credentials, source code, or network egress, the consequences go beyond a bad code change.
The research describes this using function coloring and MALFEX techniques. In plain terms, the attack is about making malicious instructions blend in with legitimate agent behavior: the file steers the agent toward attacker-chosen functions and actions while looking like a normal part of the project. Do not treat that as a reason to reproduce payloads. The defensive lesson is simpler — context files are code, and they need the same review as code.
The Claude Code token-replay risk: ANTHROPIC_BASE_URL
A second, related risk concerns where the agent sends its API traffic. Claude Code uses ANTHROPIC_BASE_URL to determine the API endpoint it talks to. If that value is changed — for example, by an instruction, a configuration change, or an environment change the agent is persuaded to accept — API requests, including the credentials or tokens that authenticate them, can be directed to an endpoint the attacker controls.
That is the token-replay concern in practical terms: a token sent to the wrong endpoint can be captured and replayed. The fix is not to memorize one variable name. It is to treat endpoint configuration as a security boundary. Teams should:
- Verify ANTHROPIC_BASE_URL (and equivalent endpoint settings for other tools) in a trusted configuration, not in instructions supplied by a repository you have just cloned.
- Refuse agent-proposed changes to API endpoints, proxy settings, and credential handling without human review.
- Use short-lived, least-privilege credentials for agent work, and be able to revoke them quickly.
- Monitor for unexpected API endpoints and unusual token use, rather than discovering a redirect after the fact.
If an agent asks to change where it sends traffic, that is a stop-and-review moment, not a routine setup step.
An important caveat: the delivery route was not confirmed
Be precise about what this research does and does not show. The technique was demonstrated, and the reported Codex success rate was over 90% in testing. The delivery route — how a malicious AGENTS.md would reliably reach a victim's agent in a real attack — was not confirmed.
That caveat matters. It means this should not be described as a confirmed in-the-wild campaign, and teams should not assume every cloned repository is already compromised. It also does not make the issue theoretical. A demonstrated way to steer a trusted agent, combined with an unconfirmed but plausible delivery path through shared repositories, forks, and copied project templates, is enough to justify controls now. The right response is proportionate defense, not panic.
Practical defenses that actually help
Start by changing how AGENTS.md is treated in your workflow:
1. Review AGENTS.md like code. Require pull-request review for AGENTS.md and other agent instruction files. Use CODEOWNERS or an equivalent approval rule so a single contributor cannot silently change what agents are told to do. Check diffs, not just the final file.
2. Do not run an agent in an untrusted checkout with full privileges. Before running a coding agent on a repository you did not author, inspect AGENTS.md, configuration files, and setup scripts. If you do not need the file, remove or quarantine it for that run, or run in a disposable environment.
3. Require human approval for consequential actions. Shell execution, network requests, package installation, credential access, and changes outside the working tree should require explicit approval. An agent that can act without friction is an agent that can be steered without friction.
4. Apply least privilege and network controls. Give agents the minimum repository, filesystem, and secret access they need. Block or allowlist network egress where possible, and do not let an agent session hold production credentials or long-lived tokens.
5. Separate build, test, and secret-handling contexts. Do not let the same agent session that reads untrusted instructions also read secrets from the environment. Where possible, run untrusted work without secrets mounted, and inject credentials only in a controlled, reviewed step.
6. Log and audit agent actions. Keep a record of tool calls, commands, and endpoint changes. If an agent follows a suspicious instruction, you need to know what it did, what it accessed, and which credentials were in scope at the time.
7. Pin and verify your tool configuration. Endpoint URLs, model settings, and plugin or MCP server configurations should come from trusted, version-controlled configuration — reviewed separately from repository content. Alert on changes.
These controls do not require trusting a single vendor. They follow from one principle: untrusted text should not become trusted action without a human or a policy check in between.
Disclosure: Securetron AI-FW
Disclosure: I am Sarah Reid, with Securetron. The section below describes a Securetron product. It is included so readers can evaluate a vendor control in context, not as an independent endorsement.
Securetron AI-FW is Securetron's AI firewall offering, intended to help teams inspect and control traffic and actions from AI agents. The Community Edition is proprietary software that is free to use, for up to 10 billion tokens per month. It is not open source, and this article does not claim otherwise.
Whether you use AI-FW or another control, the evaluation questions are the same: does it see agent tool calls and API traffic, can it block or require approval for high-risk actions, does it log what happened, and can it enforce endpoint and credential policies without depending on the instructions in the repository itself? A control that only reads the same AGENTS.md file the agent reads will not solve the trust problem described here.
Bottom line
AGENTS.md is not just documentation. For a coding agent, it is instructions, and instructions are an attack surface. The Forever Security research — over 90% reported success against Codex in testing, function-coloring and MALFEX techniques, and the ANTHROPIC_BASE_URL token-replay risk for Claude Code — shows how far that trust can be stretched. The unconfirmed delivery route is a reason to be accurate, not a reason to wait.
Review the file. Limit the agent. Approve the consequential action. Verify the endpoint. If you do those four things consistently, a hijacked instruction file becomes a suspicious diff to reject, not a silent takeover.
Sarah Reid is with Securetron.
Top comments (0)