Guide
How do I protect coding agents from prompt injection hidden in repos, issues and docs?
Updated
Short answer
You can't filter every injected instruction out of what a coding agent reads. Check what the agent then tries to do instead. If an install, file write or network call doesn't match the session's intent, stop it before it runs. Back that up with a clean working directory, vetted MCP servers and scoped credentials: treat everything the agent reads as untrusted, and enforce at the point where it acts.
Where the injected text comes from#
A coding agent reads a lot of text it didn't write, and it can't reliably tell data from instructions. OWASP says indirect prompt injection happens when an LLM "accepts input from external sources, such as websites or files." It also says "it is unclear if there are fool-proof methods of prevention."
For a coding agent, those external sources are concrete:
- READMEs, code comments and docs in a cloned repo
- Issue and pull request text the agent is asked to work on
- Instruction files in the working directory (AGENTS.md, CLAUDE.md)
- MCP tool output, which goes straight into the model's context
- Web pages the agent fetches
The Downloads folder case#
In late October, researchers reported planting malicious instructions in a Downloads folder. When Codex was opened in that folder, it "first changed its own settings and then installed the package named in the file."
The researchers say Codex ran the malware in more than 90% of attempts. Claude Code followed through on their attack about 50% of the time. Those are one research team's results, not a benchmark.
What a security lead should notice: there was no exploit in the usual sense. The agent did what agents do with instructions sitting in their folder.
Why content filters leak#
A content filter has to guess intent from the text the agent reads. Attackers can rewrite the text as many times as they like, and the filter has to catch every version. So a plan that depends on catching all injected text fails the first time one gets through.
Filters still help as one layer, but you can't depend on them. Telling the model to ignore instructions it finds in files has the same problem. You can't trust agents to police themselves when the model being manipulated is the same model making the call.
What the built-in controls do and don't stop#
Turn the vendor controls on. They catch real problems. Each one also has a known limit.
| Control | What it does | Where it stops |
|---|---|---|
| Permission prompts | Ask a human before an action runs | Users approve 93% of prompts, and humans caught 13.6% of dangerous commands in Anthropic's 1,053-tester study |
| Deny rules | Block commands you've named | Claude Code's docs say a deny rule matches the command "as written" |
| Sandbox | Isolates what the agent runs | Protects only up to the boundaries you set |
| MCP allowlist | Limits which tool servers can connect | An approved server's output still goes into context |
Anthropic's own security page puts it plainly: "no system is completely immune to all attacks." Plan on that, and layer your controls.
MCP server hygiene#
OWASP describes MCP tool poisoning as an indirect prompt injection attack on agents that connect to external tool servers. Its mitigations:
- Allowlist only vetted, approved servers
- Enforce restrictions server-side, not in a system prompt
- Isolate high-privilege tools from external servers
- Confirm sensitive actions outside the LLM context
In practice, keep one centrally managed list of approved MCP servers and review each server's tool descriptions before you approve it. That last OWASP point matters most. Your confirmation step has to sit somewhere the injected text can't reach.
Check the action, not the text#
You can't trust what the agent reads, but you can enforce what it does. Injections tend to end the same way: the agent installs something, writes a file or makes a network call that the task you gave it never needed.
So put the check at the moment of action, and ask one question: does this action match what the session is supposed to be doing? A session fixing a failing test has no reason to install an unknown package, change the agent's own settings or send a token to a new host.
Where Harden fits#
Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. No command, file edit or push runs until AIF has checked it against the session's intent. Decisions are made locally in about 28 ms, and nothing leaves the machine.
Because AIF checks the pending action, it doesn't need to recognize the injected text. If a planted file says "install this package" and the task was a test fix, the install doesn't match the task, so it's flagged in watch-only mode and blocked once you enforce. When AIF blocks an action, the agent gets the reason and can retry a safe way. If the check can't run, the action doesn't run.
AIF starts watch-only, so you see what your agents attempt before you enforce anything. You push one policy to every agent through the MDM you already run. For the wider set of controls, see how to secure AI coding agents.
It's a layer, not a perimeter. It doesn't replace least privilege, scoped credentials or egress policy, and exfiltration spread across several separate calls is still the hard case.
A checklist for this week#
- Don't start a coding agent in Downloads or any other folder you don't control
- Read any AGENTS.md or CLAUDE.md you didn't write, including in freshly cloned repos
- Diff agent settings files for changes nobody made
- Allowlist MCP servers centrally and review their tool descriptions
- Scope credentials so a hijacked session can't reach much
- Check each action against the task at the pre-execution hook, starting in watch-only
- If you find a planted instruction file, rotate the agent's credentials and treat the machine as compromised
FAQ
Related questions
Can a filter catch prompt injection in a repo?
It can catch some injected text, but not all of it. OWASP says it's unclear whether fool-proof prevention exists. Use filters as one layer and enforce on the actions the agent takes.
Are instruction files like AGENTS.md and CLAUDE.md safe to trust?
Only the ones you wrote or reviewed. Agents act on instructions in their working folder, so read any file from a download, a cloned repo or an unknown source before an agent opens that folder.
Do sandboxes and permission prompts solve this?
They help, and you should turn them on. But people approve most prompts out of habit, deny rules only match commands as written, and a sandbox only protects up to the boundaries you set. Checking each action against the session's intent at the pre-execution hook closes the gap they leave.
How does Harden start without disrupting developers?
It starts watch-only and logs what agents attempt without blocking anything. Your security team sees real behavior first, then turns on enforcement. Full Enterprise access is free for 60 days, with unlimited developers and custom policies. Start free at harden.run.