What prompt injection testing actually finds

The OWASP Top 10 for Large Language Model Applications, 2025 revision, defines a prompt injection vulnerability as one where user prompts alter the model's behaviour or output in unintended ways. The input can be intentional or unintentional. Direct prompt injections occur when a user's prompt input directly alters the behaviour of the model. Indirect prompt injections occur when the model accepts input from external sources such as websites or files. Data inside that external content alters the model's behaviour when the model interprets it.

OWASP adds that these inputs can affect the model even where they are imperceptible to humans. An injection does not need to be human-visible or readable as long as the content is parsed by the model. Testing the indirect path therefore has to cover content a person reading the same document would never see.

MITRE ATLAS catalogues the technique as AML.T0051, under the Execution tactic, AML.TA0005, with three sub-techniques. Direct, AML.T0051.000, covers an adversary injecting prompts as a user of the model, to gain a foothold in the system or to misuse the model itself. Indirect, AML.T0051.001, covers prompts injected through a separate data channel the model or agent ingests, such as text or multimedia pulled from documents, emails, databases or websites. The instructions come from adversary-controlled content rather than the legitimate user, and are frequently hidden or obfuscated, for example as invisible text. Triggered, AML.T0051.002, added to ATLAS in November 2025, covers a prompt injection fired by a user action or an event inside the victim's environment, aimed at agents. The malicious content may already be sitting in that environment before anything triggers it.

ATLAS also records what makes indirect injection serious once it lands against an agent. An adversary can use it to hijack the agent or model, gain a foothold in the target system, or act against an unwitting user of that system. The attack inherits whatever privileges the AI system holds. The vulnerable step sits behind the chat interface, in whatever fetches external content on the system's behalf: a document parser, a web retrieval call, an email connector. What decides the outcome is whether that fetch marks its output as data or lets it re-enter the prompt as an instruction.

For a chatbot answering from a knowledge base, a reproduced finding names the retrieved document or field that carried the instruction. It also names the response the system gave once it followed that instruction instead of answering the user. It also records how many of the repeated attempts against that technique landed. A prompt injection that fails once can succeed on a later attempt with the same input.

For an agent with access to internal tools, the finding names the tool call the injected instruction triggered and what that tool was scoped to do. It also records whether the call executed with the permissions of the user who opened the conversation or with a wider set the agent itself held.

OWASP states that the severity and nature of the impact of a successful prompt injection attack can vary greatly. Both depend on the business context the model operates in and the agency with which the model is architected. An injection that makes a marketing chatbot answer an off-topic question changes one answer. The same technique against an agent with write access to a ticketing system can close or reassign a case it should never have touched. The write-up has to state that business context, because the technique on its own does not establish severity.

OWASP files what happens after generation as its own risk, LLM05 Improper Output Handling. It covers insufficient validation, sanitisation and handling of the outputs generated by large language models before those outputs are passed downstream to other components and systems. Generated content can be controlled by prompt input, so OWASP describes the behaviour as similar to giving users indirect access to additional functionality. OWASP records that successful exploitation can result in cross-site scripting and cross-site request forgery in web browsers, and server-side request forgery, privilege escalation or remote code execution on backend systems.

An injection test is already measuring two of the conditions OWASP lists as increasing the impact of this vulnerability. One is the application granting the model privileges beyond what is intended for end users, which enables escalation of privileges or remote code execution. The other is the application being vulnerable to indirect prompt injection, which could allow an attacker to gain privileged access to a target user's environment. The common examples OWASP lists under the risk are ordinary application vulnerabilities produced by generated text.

Reach is the technical half of the OWASP severity test: what the system can do once it accepts an instruction. OWASP's mitigation list for prompt injection is built around narrowing that reach, and most of the measures on it limit what an injected instruction can get at. Constrain model behaviour with specific instructions about the model's role, capabilities and limitations in the system prompt. Define expected output formats and validate adherence with deterministic code. Enforce privilege control and least privilege access. Give the application its own API tokens for extensible functionality and handle those functions in code rather than providing them to the model. Require human approval for high-risk actions. Separate and clearly denote untrusted content to limit its influence on user prompts.

Testing reads severity the same way. OWASP's own list of what prompt injection can lead to runs from disclosure of sensitive information and content manipulation through to unauthorised access to functions available to the model. It extends to execution of arbitrary commands in connected systems and manipulation of critical decision-making processes. Those outcomes sit far apart in severity while sharing an entry point, so a scope states up front what the system can reach. That statement is what each finding is then weighed against.

Getting a system prompt or a content filter to fail once, during a single testing session, is a guardrail bypass. It shows the control can be got around. It does not show the underlying path is closed. OWASP defines both terms: prompt injection manipulates model responses through specific inputs to alter behaviour, which can include bypassing safety measures. Jailbreaking is a form of prompt injection where the attacker provides inputs that cause the model to disregard its safety protocols entirely.

Prompt injection vulnerabilities are possible due to the nature of generative AI. Given the stochastic influence at the heart of the way models work, OWASP states it is unclear whether there are fool-proof methods of prevention. The measures it lists mitigate the impact of prompt injections rather than removing the class. One of those measures is adversarial testing. Perform regular penetration testing and breach simulations, treating the model as an untrusted user, to test the effectiveness of trust boundaries and access controls.

Closing a finding therefore needs a re-test against the original technique, run across repeated attempts instead of a single pass, and run against the fix as deployed. A filter added to block the specific payload written up in the report leaves the path open for the next one.

Start with what the system can reach, before testing a single payload. List every tool, database query, email send or write action an agent or a retrieval pipeline can trigger, and what authenticates each one. That list sets the ceiling on severity for every finding that follows.

Separate the two entry points and test them differently. Direct injection is tested against the input box, the API, anything a user types. Indirect injection is tested against every place the system pulls in outside content: a document upload, a web fetch, an email connector, a support ticket field. Include content a reader would never see, since an injected instruction only has to be parsed by the model.

Trace the output path as well. Follow the model's response between generation and wherever it lands: a browser, a shell, a query, a file path, a downstream system. Confirm each of those points treats the response as untrusted text until it has been checked for its destination.

AI penetration testing scopes this work against the OWASP Top 10 for Large Language Model Applications. That covers prompt injection direct and indirect, jailbreak and guardrail bypass, insecure output handling, data leakage through retrieval, and tool and agent permission abuse. A tester reproduces every finding before it is written up, with repeated attempts recorded against each technique. A re-test of agreed fixes, limited to the findings in the original report, can be included in the fixed scope.