Yes. A coding agent reads documentation as input, and OWASP lists indirect prompt injection, where content from external sources changes the model's behavior, as a core LLM risk. Documentation is untrusted data. The defense is limiting what the agent can do after it reads, not trying to filter every sentence.
This is an explainer for engineers who let an assistant read dependency docs, issues and READMEs. It stays defensive: no payload examples, just the mechanism and the controls.
How does text in a README become an instruction?
A language model does not separate "data to summarize" from "instructions to follow" the way a parser separates code from input. OWASP's LLM01 entry says prompt injections can affect the model even when the content is imperceptible to humans, as long as the model parses it. In OWASP's words, indirect injections occur when an LLM accepts input from external sources such as websites or files.
For a coding agent, those sources include READMEs, changelogs, package descriptions, issue threads, code comments and wiki pages. A human sees a rendered page. The model sees the raw text, including parts the renderer hides. That gap is why a doc that looks harmless to you can still contain text aimed at the assistant.
What can it make an agent do?
Only what the agent is allowed to do. OWASP's LLM06 entry on excessive agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. A read-only summarizer that is manipulated produces a bad summary. An agent with shell access, credentials and auto-approval produces an incident.
OWASP's own examples show the range: manipulated summaries, leaked conversation content through a rendered link, and in a RAG case, a modified repository document that changes answers. The impact scales with the tools attached.
Which habits reduce the risk?
OWASP's mitigation list for LLM01 maps cleanly to a developer setup.
- Constrain permissions. Give the agent the least access it needs. OWASP says to restrict privileges to the minimum necessary and to handle extensible functions in code rather than handing them to the model.
- Require approval for high-risk actions. Running a command, writing outside the repo, sending network requests and touching secrets should prompt a human.
- Segregate untrusted content. Treat anything fetched from a package or website as data, never as instructions, and keep it apart from your own prompts where your tooling allows.
- Validate outputs with code. Do not let model output flow straight into a shell, a package install or a commit.
- Test the setup adversarially. OWASP suggests treating the model as an untrusted user when testing trust boundaries.
The Safeguard CLI shows this pattern in its docs. Its interactive terminal has three approval modes, ask, auto and yolo, chosen with a permissions command, and the non-interactive exec command defaults to a strict mode where anything the policy file has not pre-approved is denied. Whichever agent you use, pick the strictest mode your workflow tolerates for any session that reads outside text.
What should you review differently?
Review documentation changes in your own repository with the same care as code. A pull request that only edits a README can still change what an agent does the next time it reads it. For dependencies, remember that the text in a package's README is controlled by the package publisher. A newly published or newly transferred package deserves more suspicion than one you have used for years.
Also look at where agents read from. A rule file or an agent instruction file in a repository is an instruction channel by design. Protect it with code owners and review, and keep secrets out of it.
What are the limits of these defenses?
OWASP states that it is unclear whether fool-proof prevention exists, given how models work, and that retrieval and fine-tuning do not fully mitigate the problem. So plan for a manipulated model. Assume it will sometimes follow text it should not, and make sure that does not reach credentials or production.
What to do
- List every source your coding agent reads, including MCP tools and fetched URLs.
- Remove tools and permissions the agent does not need for that task.
- Turn on approval prompts for commands, network access and file writes outside the project.
- Keep credentials out of the agent's environment where you can.
- Review README, rules and instruction file changes in pull requests.
- Log what the agent did, so you can trace odd behavior to the document it read.
Quick check
Is prompt injection through docs only a risk for autonomous agents?
No. Any assistant that reads outside text can be steered. The impact is much larger when it can run commands or send data without approval.
Can input filtering stop it?
It helps, but OWASP says fool-proof prevention is unclear. Limit privileges and require approval, so a successful injection has little to act on.
Sources
- OWASP LLM01:2025 Prompt Injection
- OWASP LLM06:2025 Excessive Agency
- Safeguard interactive terminal
- Safeguard CLI usage
Last reviewed: 18 October 2026.
