Yes, in principle. A model that reads repository text, issue threads or package metadata can treat instructions hidden there as part of its task. OWASP calls this indirect prompt injection. You cannot filter it away completely, so contain it: narrow scope, deterministic checks on output, and human review of every change.
What indirect injection is
OWASP separates two forms. Direct injection comes from the person prompting the model. Indirect injection arrives through external content the model ingests, such as web pages or files, which contain instructions that change its behavior. The inputs need not be visible to a human, as long as the model parses them.
A fix generator ingests a lot of external content: source files, comments, README text, commit messages, issue threads, advisory descriptions and dependency metadata. Anyone who can write to any of those places can try to write instructions into them.
Where the text can come from
- A comment in a dependency's source or a vendored file.
- A pull request description or issue from an outside contributor.
- A package description or changelog in a registry.
- A string in test data or a configuration file.
Not every one of these reaches every tool, so check which inputs your tool reads. The question to ask a vendor is simple: what text is placed in front of the model, and who controls that text?
What an attacker would want
Plausible goals include getting the fix to add a dependency the attacker controls, weaken a check, widen a permission, or leak data in a pull request description. None of these require the model to be broken. They only require it to follow text it should have treated as data.
Controls that work without trusting the model
OWASP is candid that no foolproof prevention is known, so its mitigations reduce impact. The ones that apply to fix generation:
- Constrain scope. Limit which files and which kinds of change are allowed. A dependency fix has no reason to edit workflow files.
- Validate output deterministically. Check the diff with code, not with another model: allowed paths, allowed packages, size limits.
- Separate untrusted content. Label external text as data and keep it apart from instructions.
- Least privilege. Keep credentials in application code, not in the model's reach.
- Human approval. Require a person to review before merge.
- Adversarial testing. Treat the model as an untrusted user and test it with planted instructions.
A cheap test you can run
Create a throwaway repository. Add a comment that says to also add a named package to the manifest. Run your fix process on a finding in that file and read the diff. If the package appears, your scope and output checks have a gap. Repeat with text in a README and in an issue.
What reviewers should look for
- Added dependencies that the vulnerability did not call for.
- Changes outside the directory of the finding.
- New network calls, scripts or install hooks.
- A pull request description that tells the reviewer to skip a step.
The last one is a tell. Text asking for less scrutiny deserves more.
For related work see prompt injection risks in AI code review bots.
Safeguard offers autonomous remediation with fix PRs, off by default with every category on Manual, so a person reviews any change before it lands.
Quick check
Can a filter on the input stop this?
Not reliably. Filters help, but OWASP says no foolproof prevention is known. Rely on scope limits and human review.
Is private code safe from this?
Not automatically. Dependencies, issues and contributor text can still carry instructions into the model's input.
Sources
Last reviewed: 19 October 2026.
