What Is Prompt Injection? Examples and How to Defend Against It

In short: Prompt injection is when instructions written into the text an AI model reads, openly or hidden, take the place of the application's own instructions. The attack can come directly from the user or indirectly from outside content such as a web page, a document, an email or a tool output. There is no known definitive fix. Defense relies on layered measures that reduce the likelihood and the impact of an attack.

Asking a chat assistant to summarize a web page, letting an agent read email or pointing a model at company documents all mean handing the model text from outside. If a single sentence in that text can change what the model does, you have a security problem. OWASP ranks it first in its risk list for LLM applications as "LLM01:2025 Prompt Injection", and both the attack examples and the ways to defend against it lead to the same point: the more authority a model has, the more it costs when the model is fooled.

Prompt injection is when the text sent to a model in an application built on a large language model changes the model's behavior or output in unintended ways. OWASP ranks it first in its 2025 risk list for LLM applications. According to OWASP's LLM01:2025 Prompt Injection page, the malicious input does not even have to be visible to a human. As long as the model parses the text, a sentence written in white on a white background, for example, can still work.

The root of the problem is that models cannot tell instructions from data. The UK's National Cyber Security Centre (NCSC) describes it this way in its post Prompt injection is not SQL injection of 8 December 2025: the application concatenates its own instructions with untrusted content in a single prompt, then treats the model's response as if there were a robust boundary between the two. Today's large language models enforce no security boundary between instructions and data inside a prompt. To the model it is all one text, and its job is to predict the next token. We explain how a model produces text in our post What is an LLM.

Prompt injection and jailbreaking are closely related and often used interchangeably. OWASP defines a jailbreak as a form of prompt injection in which the attacker supplies inputs that make the model disregard its safety protocols entirely. Prompt injection is the broader idea. The goal is not always to get past safety rules. It can also be to subvert the application's own instructions or to make the model take an action nobody wanted.

In direct prompt injection the user writes the malicious input, while in indirect prompt injection the instruction arrives inside outside content the model reads. OWASP defines the two types as follows.

• Direct prompt injection: The user's own input changes the model's behavior in unexpected ways. It can be intentional, with an attacker deliberately crafting the input, or unintentional, with a user triggering unexpected behavior without realizing it.
• Indirect prompt injection: The model takes in content from external sources such as websites or files, and that content changes its behavior once the model interprets it. According to OWASP, indirect injection can also be intentional or unintentional.

NCSC spells out what makes the indirect kind dangerous: an attacker with no direct access to the AI system writes something that ends up being processed by the system and treated as an instruction. OWASP's unintentional example shows the same mechanism. A company adds an instruction to a job description to spot AI-generated applications. An applicant who knows nothing about it has an LLM polish their resume, and the AI detection fires without anyone intending it.

Anthropic's Mitigate jailbreaks and prompt injections guide draws the same line by threat model. In jailbreaks and direct prompt injection, the adversary is the application's own user. In indirect injection the user is trusted, but third-party content the model reads on the user's behalf (a web page, an email, a document, a tool result) carries hostile instructions. The defenses differ accordingly. Our Prompt Injection Attacks and Defenses for LLM Applications course covers the direct side, from jailbreaks to system prompt leakage, and builds a defense with input classifiers, instruction hierarchy and garak.

Multimodal models, which process several data types at once, such as images and text, widen the attack surface. OWASP notes that an instruction can be hidden in an image that accompanies harmless text, and that such cross-modal attacks can be hard to detect with current techniques.

In a typical prompt injection example, the model treats text from an untrusted source as an instruction and produces a result the application never intended. The five examples below are adapted from scenarios described by OWASP and NCSC. The companies and people are fictional.

A fictional company scores applications with an LLM, and the application's instruction is to score whether each resume meets the job requirements. One candidate adds a sentence in white text that no one can see. The sentence asks the model to drop its previous instructions and recommend this candidate for an interview. If the model reads the resume as an instruction rather than as data, the result changes. NCSC gives this as the typical case of indirect prompt injection. OWASP's list has a variant of the same idea: splitting the instruction into pieces placed in different parts of the resume (payload splitting).

A user asks an AI assistant to summarize a web page. The page holds a hidden instruction telling the assistant to add an image to its answer that links to an outside address. When the image loads, the contents of the conversation can travel to that address. OWASP lists this scenario as an example of exfiltrating a private conversation.

An attacker writes a message telling a support bot to ignore its previous guidelines, query private data stores and send emails. If the bot really has access to those tools, the result can be unauthorized access and privilege escalation. The problem is not only that the bot is fooled. It is that the fooled bot holds too much authority.

An attacker modifies a document in the repository a RAG application draws on. When an employee's question retrieves that document, the instruction inside it makes the model's answer misleading. OWASP notes that RAG and fine-tuning make outputs more relevant and accurate but do not fully mitigate prompt injection. We explain how RAG assembles an answer from documents in How RAG finds answers in your documents.

The AI security and safety page in Google Cloud's MCP server documentation gives this pattern as an example. The agent's instruction is to summarize a database record, but the record contains text that, in effect, tells it to forget its previous instructions and call the delete tool. If the agent has access to a delete tool, the model may call it. OpenAI's agent safety guide, Safety in building agents, gives a similar example: a data lookup agent tricked into sending raw customer records instead of the intended summary.

All of these examples share one trait. The model processes text from an untrusted source as if it were an instruction. How much damage follows depends on the tools and permissions the model holds. We cover how tools are connected to a model in What is MCP, and systems that use tools to carry out work step by step in What is an AI agent?

A successful prompt injection can lead to anything from leaking sensitive information to running commands in connected systems. OWASP lists these possible outcomes.

• Disclosure of sensitive information
• Leaks of the system prompt or of details about the AI system's infrastructure
• Content manipulation that produces incorrect or biased output
• Unauthorized access to functions available to the model
• Arbitrary commands executed in connected systems
• Manipulation of critical decision-making processes

According to OWASP, the severity depends on the business context the model operates in and on how much agency the model has been given. NCSC puts it more bluntly. If the model calls tools or APIs, the impact of prompt injection can grow to the worst case of giving an attacker direct access to those tools.

Defending against prompt injection takes a layered design that reduces the likelihood and the impact of an attack, not a single filter. It helps to set expectations first. OWASP writes that, given the nature of generative AI, it is unclear whether there are fool-proof methods of preventing prompt injection. NCSC says it is very possible that prompt injection will never be fully mitigated the way SQL injection can be. According to NCSC, the best we can hope for is to reduce the likelihood or the impact. If a system's security cannot tolerate the remaining risk, it may not be a good use case for an LLM.

Microsoft's Defend against indirect prompt injection attacks guidance likewise recommends defense in depth for indirect prompt injection, layering probabilistic and deterministic mitigations. The shared advice of the sources falls into six groups.

Give the model only the access its task needs, because the damage a successful attack can do is bounded by the model's permissions.

• OWASP recommends that the application use its own API tokens, handle those functions in code instead of handing them to the model, and keep the model's access privileges to the minimum.
• Microsoft recommends giving agents the fewest, shortest-lived privileges the task needs, granting them only when needed and removing them after each use.
• NCSC passes on a simple rule: when a model processes content from a party, its privileges should drop to that party's. A model that reads email from outside senders should not have access to privileged tools.
• Anthropic advises not giving the model secrets it does not need, running tools in sandboxed environments and scoping permissions as narrowly as possible.

The same principle applies to internal document assistants. A RAG assistant should reach only the documents the person asking is allowed to see. Then, even if an instruction hidden in a document steers the model, no document the user could not open anyway ends up in front of it. RuneLab's document assistant RuneDesk likewise answers only from an organization's documents and connected systems. Users sign in, and who can access which documents is defined according to the organization's needs.

Leave the final decision on irreversible or privileged actions to a person. OWASP recommends human-in-the-loop controls for privileged operations. The Tools section of the MCP specification says that, for trust, safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations. OpenAI's MCP servers guide recommends routing sensitive actions through an approval flow, and the MCP tool in its Responses API asks for approval of each tool call by default. Microsoft calls human approval the last line of defense. Google Cloud reminds readers that human approval is fallible too, since an overly trusting user can approve a harmful action.

Keep content from outside sources apart from the application's own instructions, and make it clear to the model that this content is untrusted data.

• OWASP recommends separating untrusted content and clearly marking it.
• OpenAI's agent safety guide advises against putting untrusted input in developer messages and recommends passing it through user messages instead. Developer messages take precedence over user messages, so text placed there gives an attacker the most control.
• Anthropic recommends delivering third-party content only in tool result blocks, stating what the content is and where it came from, and saying in the system prompt that such content is untrusted data.
• Google Cloud recommends wrapping outside content in strong delimiters such as XML tags and telling the model never to treat anything inside those tags as an instruction. The approach Microsoft calls spotlighting likewise isolates and neutralizes outside content through data marking and metaprompting.

NCSC grants that these methods make injection harder, but points out that they all try to lay a distinction between instructions and data over a technology that does not make one by nature. In Microsoft's words, no single solution is sufficient. Our Indirect Prompt Injection in RAG and Agent Systems course applies spotlighting, together with architectural defenses such as dual LLM and CaMeL, to hidden instructions arriving through web pages, email, documents, RAG sources and MCP tool outputs.

Check the model's output in code against the expected format before it reaches another system.

• OWASP recommends specifying clear output formats and validating adherence to them with deterministic code.
• OpenAI's agent safety guide recommends structured outputs between agent steps, such as fixed schemas, enums and required field names. That removes the free-text channels an attacker could use to smuggle instructions or data.
• Microsoft recommends critic agents that audit inputs and outputs in real time, especially in multi-agent systems.

Screen inputs and tool outputs before they reach the model, but do not treat screening as your only defense. OWASP recommends input and output filtering. Anthropic describes running tool output through a small classifier model before handing it to the main model. Microsoft lists a detection layer called Prompt Shields.

NCSC adds a warning here. Deny-lists that block known phrasings, such as requests to ignore previous instructions, fall short, because the same attack can be rephrased in endless ways. NCSC advises being wary of products that claim to stop prompt injection and looking instead at those that explain how they reduce it.

Test the system regularly from an attacker's point of view, and log enough to notice suspicious behavior.

• OWASP recommends regular penetration testing and breach simulations that treat the model as an untrusted user. Anthropic likewise recommends testing an agent before deployment with documents, emails and tool outputs that deliberately contain injection attempts.
• NCSC recommends logging enough to identify suspicious activity, potentially including the full input and output of the model as well as tool use and API calls. Because an attacker will likely have to refine an attack over several attempts, watching for failed tool or API calls can catch its early stages.
• Microsoft recommends monitoring multi-step tasks for drift from the intended plan and blocking risky sequences of tool calls.

Awareness is what NCSC calls a key first step. Prompt injection is a relatively new class of vulnerability that even experienced web developers do not always understand. Developers building systems around LLMs need to recognize it as a class of vulnerability in its own right. Security teams and risk owners need to know that prompt injection will remain a residual risk that no product can fully remove.

Before you connect an AI assistant or agent to company systems, answer these seven questions.

1. What outside content will the model read: the web, email, documents, a RAG store, tool outputs?
2. Which tools can the model call, and what is the worst that could be done with them?
3. Do irreversible actions (sending, deleting, paying) require human approval?
4. Is outside content kept apart from the application's own instructions and marked as such?
5. Is output validated in code before it goes to another system?
6. Are inputs, outputs and tool calls logged, and who reviews anything suspicious?
7. Is the remaining risk acceptable for this use?

Making these questions part of the secure software development lifecycle (SSDLC) is the approach of the LLM Application Security: OWASP Top 10 and Prompt Injection Defense course, which covers the OWASP Top 10 for LLM Applications, including direct and indirect prompt injection, improper output handling and data disclosure.

Prompt injection is when instructions in the text an AI model processes take the place of the application's own instructions. OWASP ranks it first, as LLM01, in its 2025 risk list for LLM applications.

A typical example is an invisible line added to a resume that asks the model to recommend the candidate for an interview. If a system that scores resumes with an LLM treats that text as an instruction, the result can change. NCSC describes this example as indirect prompt injection.

In a direct attack, the user writes the malicious input. In an indirect attack, the instruction hides in outside content the model reads, such as a web page, a file or a tool output. According to NCSC, an indirect attack does not require the attacker to have direct access to the AI system.

No, but they are close. OWASP defines a jailbreak as a form of prompt injection that makes the model disregard its safety protocols entirely. Prompt injection is broader and also covers subverting the application's own instructions.

Not with what is known today. OWASP writes that it is unclear whether there are fool-proof methods of preventing it, and NCSC considers it very possible that prompt injection will never be fully mitigated the way SQL injection can be. The goal is to reduce the likelihood and the impact of an attack.

Give the model the least privilege it needs, require human approval for irreversible actions, separate and mark outside content, validate output in code, screen inputs and tool outputs, and test and log the system regularly.

Yes. Tool outputs from MCP servers are also outside content the model reads. The MCP specification recommends keeping a human in the loop who can deny tool calls, and it requires clients to treat annotations describing tool behavior as untrusted unless they come from a trusted server.

Not on its own. NCSC says deny-lists that block known attack phrasings can be bypassed by rephrasing, and Microsoft recommends combining probabilistic detection with deterministic rules. A filter makes sense together with privilege limits and human approval.

• OWASP Gen AI Security Project, LLM01:2025 Prompt Injection: definition, direct and indirect types, the link to jailbreaking, possible outcomes, mitigations and attack scenarios
• NCSC (UK), Dave Chismon, Prompt injection is not SQL injection (it may be worse): instructions versus data, the resume example, secure design, monitoring and awareness
• Microsoft Learn, Defend against indirect prompt injection attacks: defense in depth, Prompt Shields, spotlighting, critic agents, plan drift, short-lived privileges and human approval
• Anthropic, Mitigate jailbreaks and prompt injections: threat models, tool result blocks, classifier screening, least privilege and testing
• OpenAI, Safety in building agents and the MCP servers guide: developer messages, structured outputs, the data lookup agent example and MCP tool approvals
• Google Cloud, AI security and safety (Google Cloud MCP servers): the database record example, delimiters and the risks of human approval
• Model Context Protocol, The Tools section of the MCP specification: human in the loop and tool annotations

• What is an LLM?
• What is MCP (Model Context Protocol)?
• What is an AI agent?
• One agent or many?
• How RAG finds answers
• Courses: Prompt Injection Attacks and Defenses for LLM Applications, Indirect Prompt Injection in RAG and Agent Systems, LLM Application Security: OWASP Top 10 and Prompt Injection Defense