Prompt injection is a vulnerability that occurs when user prompts alter a large language model’s behavior or output in unintended ways, according to OWASP, which files the flaw as LLM01 in its Top 10 for LLM Applications.
Application security owns this term. NIST locates the root cause in the architecture. GenAI models combine the data and instruction channels, so attackers can leverage the data channel to affect system operations. A model reading a hostile sentence inside a web page has no reliable way to separate that sentence from its operator’s orders.
Key Takeaways
- OWASP files prompt injection as LLM01, the opening entry in its Top 10 for LLM Applications, and classifies jailbreaking as one form of prompt injection.
- The flaw is architectural, according to NIST. GenAI models combine the data and instruction channels, so the data channel can affect system operations.
- Direct prompt injections occur when a user’s prompt input directly alters the model’s behavior. Indirect prompt injections occur when an LLM accepts input from external sources such as websites or files.
- Efforts should turn to reducing the risk and impact of prompt injection, per NCSC guidance, which challenges claims that prompt injections can be stopped.
- CVE-2025-32711 is an AI command injection in M365 Copilot, per NVD, which records a CVSS 3.1 base score of 7.5 HIGH. It allows an unauthorized attacker to disclose information over a network.
How Does Prompt Injection Work?
A language model reads its operator’s instructions and the outside world’s text through the same door. Many use cases for GenAI models involve models interacting with additional resources, from an internet-connected agent to a retrieval-augmented generation system, according to NIST. Every resource in that chain becomes a place where an instruction can be planted.
Step 1: Instructions and Data Share One Channel
Because GenAI models combine the data and instruction channels, attackers can leverage the data channel to affect system operations by manipulating resources with which the system interacts, per NIST. A conventional application keeps those two streams apart at the parser. A model flattens them into one sequence of tokens and weighs each token by the same rules.
Step 2: The Attacker Plants Text the Model Will Read
A prompt injection vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways, and indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files, according to OWASP. The planted text needs no special syntax. Plain imperative English, placed where the model will read it, does the job.
Step 3: The Model Acts With the Privileges It Holds
The severity and nature of the impact of a successful prompt injection attack can vary greatly, per OWASP. Impact is largely dependent on both the business context the model operates in and the agency with which the model is architected. A chatbot that only writes text produces a wrong or embarrassing answer. An assistant wired to a mailbox, a code repository, or a payments API takes an action instead.
Step 4: The Effect Crosses the Intended Boundary
Indirect prompt injection attacks are enabled by resource control that allows an attacker to indirectly, or remotely, inject system prompts without directly interacting with the application, according to NIST. The result then leaves the session: an email sent, a file summarized into a reply, a secret repeated somewhere the operator never approved.
Two comparisons make the failure concrete. A clerk works through a stack of paperwork and finds a sheet inside it. The sheet tells them to file the case under a different name and mail a copy elsewhere. Nothing in the stack marks which sheet is an instruction and which is evidence, so the note gets carried out.
The second comparison sits closer to the plumbing. A mail-merge template pulls a customer’s name from a spreadsheet and drops it into a letter. Prompt injection is the case where the spreadsheet cell holds a command and the merge engine runs it.
| Stage | What the attacker controls | What the model does | Observable effect |
|---|---|---|---|
| Shared channel | Nothing yet | Reads instructions and data as one token stream | No visible signal |
| Planted text | A page, file, email, or ticket the model will read | Treats the planted sentence as an instruction | Output drifts from the operator’s intent |
| Privileged action | The wording of the instruction | Uses whatever tools and permissions it holds | Data gets read, sent, or changed |
| Boundary crossing | The destination named in the planted text | Returns output or triggers a call | Information leaves the intended session |
Sources: OWASP, NIST
Direct vs Indirect Prompt Injection
Who supplies the hostile text splits the attack into two named classes. Two standards bodies label those classes differently. Direct prompt injections occur when a user’s prompt input directly alters the behavior of the model in unintended or unexpected ways, per OWASP. Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files, whose content alters the model’s behavior when interpreted.
NIST runs a parallel index in its Generative AI Attacks Taxonomy, which assigns the identifier NISTAML.018 to prompt injection and NISTAML.015 to indirect prompt injection, and lists both under availability violations and privacy compromises. Filing one technique under more than one attacker-goal heading is what makes that index more useful than a single severity label.
Indirect prompt injection attacks can result in violations across at least 3 categories of attacker goals, according to NIST: availability violation, integrity violation, and privacy compromise. Unlike direct attacks, indirect prompt injection attacks are mounted by a third party instead of the primary user of a model. In many cases, it is the primary user of the model who is harmed.
| Attribute | Direct prompt injection | Indirect prompt injection |
|---|---|---|
| Who supplies the text | The person prompting the model | A third party, not the primary user |
| Where the text lives | The prompt itself | External sources such as websites or files |
| OWASP framing | A user’s prompt input directly alters the behavior of the model | An LLM accepts input from external sources |
| NIST taxonomy ID | NISTAML.018 | NISTAML.015 |
| Enabling condition | Direct access to the prompt | Resource control over what the model reads |
| Who is often harmed | The operator of the deployment | Often the primary user of the model |
Sources: OWASP, NIST
Prompt Injection vs Jailbreaking
The two labels get used interchangeably, and OWASP treats one as a subset of the other. Jailbreaking is a form of prompt injection where the attacker provides inputs that cause the model to disregard its safety protocols entirely, per OWASP. A jailbreak targets the guardrails. A prompt injection targets whatever the application does next.
| Dimension | Prompt injection | Jailbreaking |
|---|---|---|
| Relationship | The broader vulnerability class | One form of prompt injection |
| Attacker’s goal | Alter the model’s behavior or output in unintended ways | Make the model disregard its safety protocols entirely |
| Usual target | The application built around the model | The model’s own safety protocols |
| What success looks like | Output or actions that serve the planted text | Content the model was configured to refuse |
Source: OWASP
The distinction matters because the two failures carry different blast radii. Guardrail bypass rates are tracked separately in LLM jailbreak attempt data, which measures refusal behavior rather than application compromise.
Why Does Prompt Injection Matter?
Impact scales with permissions. Impact is largely dependent on the business context the model operates in, according to OWASP, and on the agency with which the model is architected. Frequency and scale are a separate question, tracked in prompt injection incident data.
In many indirect cases, it is the primary user of the model who is harmed by the compromise of the integrity, availability, or privacy of the GenAI system, per NIST. The person who typed nothing hostile absorbs the damage, which inverts the usual mental model of an input-validation bug.
Our cybersecurity coverage keeps surfacing the same shape. Blast radius tracks the permissions attached to a system far more closely than it tracks the sophistication of the input. The same pattern shows up across AI-driven attack volume reporting.
The NCSC has raised an alert on what it calls a dangerous misunderstanding of an emergent class of vulnerability in generative artificial intelligence applications. That misunderstanding has a practical cost once models stop answering questions and start taking actions.
Agentic deployment turns a text-output bug into an action bug. The growth of that deployment pattern is visible in autonomous agent adoption data, and every new tool connection widens what a single planted sentence can reach.
Real-World Prompt Injection Cases
Named cases anchor the definition better than hypothetical scenarios do. The examples below span an enterprise assistant, an image-borne variant, and the developer tooling where the pattern keeps recurring.
Microsoft 365 Copilot and CVE-2025-32711
CVE-2025-32711 records an AI command injection in M365 Copilot that allows an unauthorized attacker to disclose information over a network, with a CVSS 3.1 base score of 7.5 HIGH assessed by NIST. The record classifies the weakness as CWE-74, improper neutralization of special elements in output used by a downstream component. It names Microsoft Corporation as the source.
The classification is the part worth reading twice. CWE-74 is the injection family that also covers SQL injection and command injection, which places this failure in a lineage defenders already know.
Instructions Hidden Inside Images
The rise of multimodal AI, which processes multiple data types simultaneously, introduces unique prompt injection risks, according to OWASP. Malicious actors could exploit interactions between modalities, such as hiding instructions in images that accompany benign text. SQ Magazine has reported one such case, GhostCommit, in which the instruction travelled inside an image instead of a prompt.
Image-borne instructions defeat the reflex of reading the text before trusting it. Nothing in the visible prompt looks unusual, because the order lives in a channel a human reviewer never inspects.
Coding Assistants and Enterprise Agents
Developer tooling concentrates the risk, since a coding assistant holds repository access and an enterprise agent holds customer records. SQ Magazine has reported two cases in that shape: GitHub Copilot CamoLeak and Salesforce ForcedLeak. Each turned on what the assistant was permitted to read and send.
The wider defect rate in machine-written code is tracked in security defects in AI-generated code, a separate failure mode that compounds this one.
Mitigations, Trade-offs, and Residual Risk
What Mitigations Achieve
OWASP lists 7 prevention and mitigation strategies for this vulnerability, per OWASP.
- Constrain model behavior.
- Define and validate expected output formats.
- Implement input and output filtering.
- Enforce privilege control and least privilege access.
- Require human approval for high-risk actions.
- Segregate and identify external content.
- Conduct adversarial testing and attack simulations.
Read as a set, those strategies do less filtering than the list implies. Most of them limit what the model is allowed to touch or return, which is where the durable reduction in risk comes from.
Trade-offs and Residual Risk
- Least privilege and human approval narrow what an attacker can reach, at the cost of slower workflows and more approval fatigue.
- Output validation limits the damage a hijacked response can do, and it cannot tell a legitimate instruction from a planted one.
- Adversarial testing surfaces known attack shapes, and it measures only the shapes someone thought to test.
- The NCSC calls on AI system designers, builders and operators to take control of manageable variables, acknowledging that LLM systems are inherently confusable.
Unlike SQL mitigation techniques, which hinge on enforcing a clear separation between data and instructions, prompt injection exploits the inability of large language models to distinguish between the two, per NCSC guidance. That contrast explains why the SQL playbook does not transfer. Parameterized queries work because a database can be told which bytes are data.
Residual risk: NIST states there are no information-theoretic security proofs for the widely used ML algorithms in modern AI systems. Many advances in developing mitigations against adversarial machine learning attacks tend to be empirical and limited in nature, adopted because they appear to work in practice.
Can Prompt Injection Be Prevented?
No, and two sources say so on the record. Given the stochastic influence at the heart of the way models work, it is unclear if there are foolproof methods of prevention for prompt injection, according to OWASP. The NCSC challenges claims that prompt injections can be stopped. It suggests efforts should turn to reducing the risk and impact of prompt injection and driving up resilience across AI supply chains.
The practical reading is a change of question. Teams get further by asking what a model is allowed to touch than by asking how to spot a hostile prompt.
What Does a Prompt Injection Attack Look Like?
It looks like ordinary text sitting somewhere the model will read. Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files, per OWASP. That content alters the behavior of the model in unintended or unexpected ways once the model interprets it. A support ticket, a resume, a README, or a calendar invite all qualify.
M365 Copilot carried exactly that shape: an AI command injection that allows an unauthorized attacker to disclose information over a network, per NVD. Instructions hidden in images that accompany benign text are the multimodal version of the same idea, per OWASP.
Conclusion
OWASP files prompt injection at LLM01 in its Top 10 for LLM Applications. It defines the flaw as user prompts that alter the LLM’s behavior or output in unintended ways. That placement describes how models read, and no single patch changes it. The M365 Copilot entry in the national vulnerability record, scored 7.5 HIGH under CVSS 3.1, shows the class reaching shipping enterprise software.
The useful posture is architectural. The NCSC directs effort toward reducing the risk and impact of prompt injection, and it treats LLM systems as inherently confusable. Teams that scope permissions tightly, segregate external content, and keep a human on high-risk actions carry less exposure than teams still hunting for a filter.
