Prompt injection reaches a coding agent through anything it reads that someone outside your trust boundary could write: issue text, pull request descriptions, comments, documentation in dependencies, fetched web pages, and tool server results. Map those inputs, then limit what the agent can do after reading them.
Definition
OWASP defines indirect prompt injection as instructions arriving when a model accepts input from external sources such as websites or files. It also notes that injected content does not have to be visible to humans, only parseable by the model. In a coding setting, that means text hidden in markup, comments, or metadata.
The input map
| Input | Who can write it | Example risk |
|---|---|---|
| Issues and comments | Anyone with an account, for public repositories | Instruction asking the agent to change files or reveal data |
| Pull request text | Contributors, including forks | Same, plus text in the diff |
| README and docs of dependencies | Package authors | Instructions hidden in documentation the agent reads while researching |
| Web pages the agent fetches | Anyone | Page content that tries to redirect the task |
| Tool server results | The tool owner, or whoever fills its data | Returned records carrying instructions |
| Project rule files | Anyone who can commit | A changed rules file that alters agent behavior |
What to do about each entry
- Separate untrusted content from instructions. OWASP advises denoting untrusted content clearly to limit its influence. Where your tool supports it, use the setting; where it does not, do not rely on it.
- Cut the actions that follow. Injection is harmful when the agent can do something damaging next. Remove network egress, restrict file writes, and require approval for commands. That is the real defence, because filtering text will not catch everything.
- Review rule files like code. Put CODEOWNERS on them so a change needs an owner's approval.
- Keep public issue text away from privileged agents. An agent with write access should not auto process issues from strangers.
- Check tool results. Prefer narrow tools that return structured fields over tools that return free text.
The combination to avoid
Three things together make the worst case: untrusted input, access to private data, and the ability to send data out or take actions. Remove at least one. Most teams find the outbound path is the easiest to close. See the rule of two for agents.
Test it
OWASP recommends adversarial testing and treating the model as an untrusted user. A simple test: plant a harmless instruction in a test issue, such as asking the agent to add a marker line to a file, and see whether it complies. If it does, your boundaries need work. More in testing coding agent guardrails.
Safeguard offers an MCP Guardrail for tool access, policies, and pull request gates that sit after the agent acts, so a harmful change still meets a check.
Quick check
Can a filter stop prompt injection?
Filters help but are not reliable alone. OWASP lists them beside least privilege and human approval, not instead of them.
Are private repositories safe from this?
Safer, not safe. Dependencies, fetched pages and tool results still bring outside text into the agent's context.
Sources
Last reviewed: 19 October 2026.
