Prompt injection testing: what a tester tries and what a good finding looks like

OWASP: “a Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways”. It adds that “prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model”. It is item LLM01 in the OWASP Top 10 for LLM Applications 2025.

• Direct. OWASP: “direct prompt injections occur when a user’s prompt input directly alters the behavior of the model in unintended or unexpected ways”.
• Indirect. OWASP: “indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files”. Like direct injection, it can be intentional or unintentional.

A tester works through each channel by which text reaches the model, and records what the system does. Typical coverage:

• Every input channel. Chat, API fields, uploaded files, pages the system browses, emails it summarises, records it retrieves, and the output of tools it calls.
• Overriding the instructions. Whether input can change the rules set in the system prompt.
• Reaching what it should not. Whether injected text can make the system reveal its hidden instructions, show another user’s data, or call a tool the user could not use directly.
• What happens to the output. Whether model output is displayed or passed on without checks, for example into a web page or another system.
• Which safeguards hold. Whether limits that sit outside the model, such as permissions and confirmations, stopped the action when the model was fooled.

In our mapping, this work relates to these OWASP items: LLM01 Prompt Injection; LLM07 System Prompt Leakage; LLM02 Sensitive Information Disclosure; LLM06 Excessive Agency; LLM05 Improper Output Handling. Written attack strings are not published on this site.

The NCSC wrote in December 2025: “under the hood of an LLM there’s no distinction made between ‘data’ or ‘instructions’; there is only ever ‘next token’”. Its conclusion: “prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be”.

• NCSC: “prompt injection attacks will remain a residual risk, and cannot be fully mitigated with a product or appliance; it needs to be risk managed through careful design, build, and operation”.
• NCSC: “approach it by seeking to reduce the risk and the impact; if the system’s security cannot tolerate the remaining risk, it may not be a good use case for LLMs”.
• NCSC: “design protections need to focus more on deterministic (non-LLM) safeguards that constrain the actions of the system”.
• NCSC: “one technique to be wary of is any approach similar to ‘deny-listing’” (for example a filter for “ignore previous instructions”), and “beware any that claim they can ‘stop’ prompt injection”.

So ask a tester to show what an injected instruction can reach and whether your safeguards held, and ask the same of any product that says it blocks injection.

• Steps you can repeat: the channel used, the content placed in it, and what the system did, with the date and the model version if known.
• The path to impact: what data, tool or action the injected text reached, and with whose permissions.
• What did and did not stop it: which controls outside the model held, and which did not.
• A change to the design, such as removing a permission or adding a confirmation step, rather than only a rewritten prompt.
• A retest note: what to re-run after the change.

A report that only says “the model was jailbroken” and shows no impact is a weak finding. See what a penetration testing report should contain.

Our prompt-injection canary page carries a harmless, labelled instruction. Point an AI browser, agent or summariser you are allowed to use at it; if the tool follows the page’s text, it treats web content as instructions.