Prompt injection happens when instructions inside content being read by a model try to redirect what it does. In a coding workflow, that content might be a repository file, issue description, pull request, web page, dependency documentation, or command output. The risk depends on what the agent can access and do, so a good defense limits permissions and treats project content as data to inspect rather than authority to obey.
Where untrusted instructions can appear
An agent may read more than the prompt you typed. It can inspect project instructions, source comments, tests, package scripts, issue text, documentation, and tool output. Some of that content is maintained by your team. Some may come from a contributor, dependency, website, or generated file that you have not reviewed.
A malicious instruction could ask the agent to reveal secrets, run an unexpected command, edit outside the task, or send data to a remote service. The wording may look like a normal setup note. The important question is not whether the text sounds convincing. It is whether the requested action matches the task and whether the agent has permission to do it.
Reduce what a manipulated agent could do
No prompt rule can guarantee that a model will ignore every injected instruction. Reduce the impact by giving the agent only the files, tools, and credentials the task needs. Avoid exposing production keys, personal tokens, or unrelated home directory files to a routine coding session.
Use a disposable branch or isolated workspace for untrusted repositories. Require confirmation for destructive commands, deployment, external messages, credential access, and broad network actions. If the task does not need the network, disable it at the environment boundary rather than relying on the agent to remember not to connect.
- Review new instruction files before trusting them.
- Treat repository text and issue comments as data, not higher priority instructions.
- Keep secrets outside the agent environment whenever possible.
- Inspect commands and diffs before accepting high impact actions.
Review the agent’s changes as if a person proposed them
Look for edits outside the requested files, new scripts, network calls, changed dependency hooks, credential reads, or edits to the agent’s own rules. Run tests from a clean state and check the exact commands that were executed. If the agent claims it did not access something, verify that claim against the available logs and environment.
For projects that process outside contributions, review the CI workflow separately. An agent that reads a pull request can be exposed to the same untrusted text as an agent opened locally. Keep read only checks separate from jobs that hold secrets or write permissions.
Build layered safeguards
Use project instructions to clarify the task boundary, but do not treat them as a security sandbox. Combine them with operating system permissions, isolated workspaces, limited credentials, network controls, command approvals, and human review. The safest configuration is the least powerful one that can still complete the work.
OWASP describes prompt injection and its limits. Read the current security guidance for the agent you use because permission names and isolation behavior differ between products. If you maintain a shared team setup, record which actions require approval and who owns the credentials.