Yes, in principle. Advisories, issue comments, commit messages and scanner output include text written by outsiders. A model that reads them cannot reliably separate data from instructions, so planted text may steer it. Limit what the model can do, mark the text as untrusted, and keep a person on decisions.
Why this applies to security work
The NCSC explains that current models "simply do not enforce a security boundary between instructions and data". An attacker who cannot touch your system directly can plant instructions in content it later processes. Its example is hidden text in a CV. For a security team the equivalent content is anything an outsider can write that ends up in a prompt.
Where outsider text enters a triage prompt
- Public issue and pull request descriptions
- Commit messages and code comments in dependencies
- README files and changelogs of packages you are reviewing
- Advisory text from sources that accept community submissions
- Log lines containing attacker controlled strings, such as user agents
- Scanner output that echoes file contents
None of this means the text is malicious. It means you cannot assume it is harmless.
What a planted instruction might try
It could tell the model to mark a finding as a false positive, to ignore a package, to include a link in its summary, or to call a tool it should not. The risk grows with the model's privileges.
Controls that help
NCSC recommends deterministic, non-LLM controls to limit what a system can do, and quotes the principle that when a model processes information from a party, its privileges drop to that of that party. Concretely:
- Give the triage model read-only access. No ability to close tickets, change policy or push code.
- Separate reading from acting. One step summarizes, a person or a fixed rule acts.
- Wrap untrusted text in clear delimiters and tell the model it is data. NCSC notes this reduces success rates but does not remove the risk.
- Do not rely on blocking phrases such as "ignore previous instructions". Attackers can rephrase.
- Log inputs, outputs and tool calls, and review failed calls.
- Require approval before any action that changes state.
What not to expect
No filter makes this go away. NCSC says prompt injection may never be totally mitigated and urges teams to be wary of products claiming to stop it. Design so that a successful injection has little to damage. If the residual risk is too high for a task, the NCSC suggests a model may be the wrong tool for it.
A quick design test
Ask: if an attacker controlled every word the model reads, what is the worst thing it could make happen? If the answer is "send an email" or "close a critical ticket", reduce its permissions until the answer is "write a misleading paragraph that a person reads". Related reading: prompt injection in SOC AI assistants, logs are untrusted input.
Where Safeguard fits
Safeguard's policies, gates and guardrails are deterministic rules, so a decision to block a build does not depend on a model following instructions. Its MCP Guardrail applies the same idea to agent tool use. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Is read-only access enough to be safe?
It limits damage but does not remove all risk, since a model can still output a misleading summary or leak data through links. Keep a person reviewing the result.
Should I add a rule telling the model to ignore instructions in advisories?
It can help a little, but it is not a control you can depend on. Use permissions and approvals for real protection.
Sources
- NCSC, Prompt injection is not SQL injection: https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
Last reviewed: 19 October 2026.
