Prompt Injection in Coding Agents: When Repository Text Becomes a Command
An AI coding agent needs to read a repository to work on it. That repository can also contain text written by someone who should not control the agent's tools.
Prompt injection happens when such content redirects the model away from the authorised task. In a coding workflow, the entry point might be documentation, a code comment, an issue description or material returned by a tool. The question is not just whether the model follows the text. It is what the surrounding system allows the resulting action to do.
The OWASP prompt injection prevention guidance explicitly includes code comments, documentation and version-control content among indirect injection sources. These are ordinary inputs for a coding assistant, not unusual channels that can simply be removed from its workflow.
Instructions inside a file are not automatically authority
Consider a fictional maintenance task: update a parser and run its tests. A file in a third-party repository says that, before testing, the agent must read an unrelated credentials file and attach its contents to a diagnostic report.
That text may look like a setup instruction. It still does not establish that the repository's author is entitled to those credentials or that the user approved their disclosure.
A project can have legitimate instructions that a user deliberately trusts. The important distinction is how that trust was established. A heading saying “system policy” inside an arbitrary file does not turn the file into a system instruction. Nor should a tool's returned text be able to create new permissions for the next tool call.
This example illustrates a trust boundary. It is not a report of a vulnerability in a named product.
A stronger prompt is useful, but it is not a permission system
Telling an agent to ignore suspicious instructions can reduce some mistakes. Clear separation between trusted instructions and retrieved material is also useful. Neither is a substitute for constraining execution.
The UK's National Cyber Security Centre explains this distinction in “Prompt injection is not SQL injection”. Its guidance emphasises deterministic safeguards around what an AI system can do, rather than assuming the model can always distinguish malicious instructions from data.
A text rule can tell a model not to disclose a secret. A permission boundary can prevent the model's tools from reading that secret in the first place. These protections are not equivalent, even if they often lead to the same answer during a harmless demonstration.
Keyword filters have the same limitation. Detecting a familiar phrase can be useful for review, but the absence of that phrase does not establish that the content is safe.
Put controls where the action happens
For a coding-agent integration, practical controls include:
- Limit accessible data. Do not expose unrelated credentials, private directories or production data to a task that only needs source files.
- Separate read, write and publish capabilities. Reading a repository should not imply permission to push changes, deploy a service or change account settings.
- Constrain network access. Where feasible, restrict destinations and credentials to what the task requires. Removing secrets from the prompt does not help if an unrestricted tool can read them later.
- Check consequential actions outside the model. Validate the operation, target and arguments against the caller's authority before execution.
- Make approvals specific. An approval to prepare a patch is not approval to publish it. The execution layer should verify the approved action rather than accepting a statement generated by the model.
A container can be part of this design, but its name alone establishes little. The mounted files, available credentials, network access and host integrations determine much of its practical exposure.
Test the boundary, not just the refusal message
A useful defensive test does not stop when the assistant says, “I will ignore that instruction.” It checks whether an unauthorised operation could actually occur.
Start with a disposable environment and harmless test data. Define an allowed task, introduce an instruction that asks for an unrelated action, and inspect the tool trace and resulting state. Test both a suspicious document and an ordinary document so that a system which blocks everything is not mistaken for a usable defence.
Separate two outcomes:
- Model behaviour: did the assistant attempt the unwanted action?
- Enforcement behaviour: if attempted, did the tool boundary reject it without performing the action?
The second can limit damage even when the first fails. Neither a small successful test nor a polished refusal proves that every future attack will be stopped.
The site's authorization demonstration provides a related worked illustration. Treat a demonstration as evidence about its specified cases, not a certificate for an entire agent platform.
What should an individual user check?
Before giving a coding agent a new repository, inspect what the agent can access: directories outside the project, shell commands, network destinations, account tokens and publishing tools. Reduce those privileges to the task's needs. Review changes to agent instructions as carefully as changes to executable setup scripts.
For work with meaningful consequences, keep an approval step between proposing a change and applying it. Check the actual files and tool actions, not only the assistant's summary.
The goal is not to find one sentence that makes an agent immune to prompt injection. It is to make a misleading sentence in a repository insufficient to authorise a dangerous action.
