Table of Contents
Prompt Injection Explained: OWASP LLM01 Risks, Examples and Defenses
Generative AI applications increasingly do much more than answer questions.
Modern AI systems can search documents, summarize email, retrieve information from knowledge bases, interact with APIs, use external tools, generate code, access business systems, and automate operational tasks.
Those capabilities make AI applications more useful—but they also create new security boundaries.
One of the most important risks is prompt injection.
OWASP currently lists Prompt Injection as LLM01:2025, the first risk in its Top 10 for LLM and Generative AI applications. OWASP defines prompt injection as a vulnerability in which inputs change an LLM’s behavior or output in unintended ways. The malicious content does not necessarily need to be obvious or even readable to a human if the model processes it.
Prompt injection is therefore not simply a problem involving users typing “ignore previous instructions.”
It can originate from:
- chat messages;
- webpages;
- uploaded documents;
- emails;
- retrieved knowledge-base content;
- vector databases;
- tool responses;
- third-party data feeds;
- multimodal content.
The risk becomes much more serious when an AI system can access confidential data or perform actions on behalf of a user.
What Is Prompt Injection?
Prompt injection occurs when attacker-controlled content influences an AI application to behave differently from the way its developer or operator intended.
Consider a simplified system instruction:
Summarize this document and do not reveal confidential information.
An attacker-controlled document might contain text designed to influence the model into ignoring or competing with those instructions.
The key security problem is that LLM applications often process trusted instructions and untrusted content using the same natural-language interface.
Traditional applications normally maintain clearer separation between code and data.
LLMs are different.
The model has to infer which instructions are authoritative and which text should merely be treated as content.
That ambiguity creates the opportunity for prompt injection.
OWASP also notes that techniques such as Retrieval-Augmented Generation (RAG) and fine-tuning do not fully eliminate prompt-injection vulnerabilities.
Direct vs Indirect Prompt Injection
There are two broad categories.
Direct Prompt Injection
Direct prompt injection occurs when a malicious user places the adversarial instruction directly into the application’s input.
For example, an attacker may attempt to make the AI:
- ignore application rules;
- reveal restricted information;
- change its assigned task;
- expose system instructions;
- invoke tools incorrectly;
- perform actions outside the intended workflow.
Direct injection is the most visible form because the attacker interacts directly with the AI interface.
Indirect Prompt Injection
Indirect prompt injection is potentially more difficult to detect.
Instead of sending the malicious instruction directly, the attacker places it inside information that the AI later processes.
Examples include:
- a webpage;
- a PDF;
- an email;
- a shared document;
- a support ticket;
- a database record;
- retrieved RAG content.
Imagine an AI assistant designed to summarize webpages.
A malicious webpage could contain text intended not for the human reader but for the AI system processing the page.
If the application fails to maintain strong trust boundaries, the model may treat those instructions as meaningful guidance.
This makes external data itself part of the AI attack surface.
Why Prompt Injection Is Difficult to Prevent
Prompt injection differs from many conventional injection vulnerabilities.
With SQL injection, for example, developers can use parameterized queries to separate user-controlled data from executable SQL instructions.
With LLMs, both trusted instructions and untrusted content may be expressed as ordinary language.
This means there is no simple equivalent of:
“Everything inside these quotation marks is always data and can never affect behavior.”
That is why prompt-injection security needs to be addressed at the application architecture level, not merely by writing stronger system prompts.
A secure design should assume that the model may occasionally interpret hostile content incorrectly.
The surrounding system should limit what that mistake can accomplish.
Why Prompt Injection Matters More in AI Agents
A text-only chatbot with no sensitive data or external tools has a very different risk profile from an autonomous AI agent.
An agent may be able to:
- read company documents;
- query databases;
- send emails;
- modify records;
- create tickets;
- trigger workflows;
- call APIs;
- access cloud applications.
OWASP describes Excessive Agency as a separate LLM risk that becomes dangerous when a model has unnecessary functionality, permissions, or autonomy. Prompt injection can be one of the triggers that causes an over-privileged agent to perform harmful actions.
This leads to an important security principle:
The impact of prompt injection depends heavily on what the model is allowed to do.
Cybersecurity Time Prompt Injection Risk Matrix
A practical way to assess prompt-injection risk is to evaluate four questions:
- What can the AI read?
- What can it do?
- Who controls the input?
- How much independent approval exists?
| AI application | Data access | Tool access | Typical risk |
|---|---|---|---|
| Public text chatbot | Public information | None | Lower |
| Internal RAG assistant | Internal documents | Read-only | Medium |
| Enterprise AI copilot | Email/files/internal data | Limited tools | High |
| AI agent | Sensitive business data | Write/action tools | Critical |
| Privileged autonomous agent | Broad confidential data | Administrative actions | Critical |
Cybersecurity Time assessment
Prompt-injection severity should not be measured only by whether the model produces an unexpected answer.
The real security question is:
Can manipulated model behavior cross a security boundary?
An unusual chatbot response may be inconvenient.
An injected instruction that causes a privileged AI agent to send confidential information or modify production systems is a much more serious incident.
Organizations building production AI should also review broader secure-development controls in the Secure AI System Development Checklist.
How Prompt Injection Interacts With the OWASP LLM Top 10
OWASP’s current 2025 Top 10 contains ten separate GenAI risks. Prompt injection is the first, but it can interact with several others.
1. LLM01 — Prompt Injection
This is the core issue discussed in this guide.
Test whether user-controlled or externally retrieved content can:
- change model behavior;
- override intended instructions;
- alter tool use;
- redirect workflows;
- expose information;
- influence decisions.
2. LLM02 — Sensitive Information Disclosure
Prompt injection may attempt to make a model disclose information it can access.
That information could include:
- private documents;
- personal data;
- financial information;
- business records;
- hidden context;
- secrets;
- internal instructions.
Sensitive information should therefore be protected by application-level authorization, not merely by telling the model not to reveal it.
3. LLM03 — Supply Chain
AI systems increasingly rely on:
- third-party models;
- APIs;
- plugins;
- frameworks;
- vector databases;
- external data feeds;
- tool integrations.
A compromised component or poorly governed external service can broaden the attack surface.
Organizations should evaluate these dependencies alongside their wider Third-Party Risk Assessment Checklist and Vendor Security Questionnaire.
4. LLM04 — Data and Model Poisoning
Prompt injection and poisoning are different problems, but they can overlap.
If attackers can influence:
- training data;
- fine-tuning data;
- embeddings;
- RAG documents;
- knowledge-base content,
they may create persistent or repeatable manipulation.
This is particularly important in systems that automatically ingest third-party content.
5. LLM05 — Improper Output Handling
Even when prompt injection affects only the model output, downstream systems can make the impact worse.
OWASP warns that insufficient validation of LLM output can contribute to issues such as XSS, SSRF, privilege escalation, and potentially remote code execution when model-generated content is passed into sensitive components.
For example:
Prompt injection → malicious model output → downstream system executes it
is much more dangerous than:
Prompt injection → incorrect text displayed to a user.
Always treat model output as potentially untrusted.
6. LLM06 — Excessive Agency
Prompt injection becomes particularly dangerous when an LLM has excessive permissions.
OWASP identifies excessive functionality, excessive permissions, and excessive autonomy as major contributors to this risk.
An assistant that only reads documents has less potential impact than an agent that can:
- delete documents;
- send external messages;
- modify financial records;
- change security configurations.
Apply least privilege to AI tools just as you would to human users.
7. LLM07 — System Prompt Leakage
Attackers may try to learn:
- hidden instructions;
- internal application rules;
- tool descriptions;
- workflow structure.
OWASP treats system-prompt leakage as a separate 2025 risk.
System prompts should not be used to store secrets or replace real security controls.
If exposing a hidden prompt would compromise the application, the architecture is already too dependent on prompt secrecy.
8. LLM08 — Vector and Embedding Weaknesses
RAG applications introduce additional trust boundaries.
An attacker may attempt to manipulate:
- retrieved content;
- vector stores;
- document metadata;
- search ranking;
- embedding-based retrieval.
Security teams should test not only the model but also the retrieval system feeding information into it.
9. LLM09 — Misinformation
Prompt injection may influence an AI system into returning incorrect or misleading information.
That becomes especially serious when AI output is used for:
- compliance decisions;
- cybersecurity recommendations;
- medical or financial workflows;
- executive summaries;
- automated approvals.
Incorrect information can have operational consequences even when no technical exploit occurs.
10. LLM10 — Unbounded Consumption
Attackers may also abuse an AI system’s resources.
Examples include:
- extremely long prompts;
- repeated tool calls;
- recursive agent loops;
- excessive API usage;
- resource-intensive workflows.
In agentic systems, this can become a cost and availability problem sometimes described as denial of wallet.
Common Prompt Injection Attack Paths
Prompt injection testing should cover the full AI workflow.
User input
The attacker controls the prompt directly.
Uploaded files
A malicious PDF, document, or spreadsheet contains instructions intended for the model.
Web retrieval
The AI searches or summarizes attacker-controlled pages.
Email processing
A message contains adversarial content read by an AI assistant.
RAG knowledge bases
Malicious or compromised documents enter retrieval results.
Tool responses
An external tool or service returns content that influences subsequent model behavior.
Memory
Manipulated information persists across conversations or agent steps.
Multimodal input
Instructions may be embedded in images or other content processed by the AI system.
A robust test should examine all of these surfaces rather than only the chat box.
How to Test Prompt Injection
NIST’s Generative AI Profile recommends structured risk management across the AI lifecycle and emphasizes evaluation, testing, monitoring, and governance rather than relying on isolated checks.
A practical assessment should include the following.
Test direct injection
Try conflicting instructions and attempts to change task boundaries.
The purpose is not merely to see whether the model can be persuaded to say unusual things.
Determine whether security controls outside the model still hold.
Test indirect injection
Place adversarial instructions inside content the application legitimately processes.
Test:
- webpages;
- PDFs;
- documents;
- emails;
- retrieved knowledge.
Test tool boundaries
If the application can use tools, verify that malicious instructions cannot cause unauthorized:
- data access;
- file modification;
- messaging;
- account changes;
- API actions.
Test authorization independently
The model should never be the sole authority deciding whether a user is allowed to access something.
Authorization decisions should be enforced by the surrounding application and downstream systems.
Test failure conditions
Ask:
What is the worst thing that can happen if the model follows the malicious instruction?
That question often reveals architecture problems faster than trying thousands of prompt variations.
10 Practical Defenses Against Prompt Injection
No single control solves prompt injection.
OWASP recommends layered mitigation, and the safest architecture assumes that some adversarial inputs will occasionally influence the model.
1. Treat External Content as Untrusted
Anything coming from:
- users;
- websites;
- files;
- email;
- third-party systems;
- retrieval stores
should be considered potentially hostile.
Do not assume retrieved content is safe merely because it comes from a document system.
2. Separate Trusted Instructions and Untrusted Data
Structure prompts and application logic so that:
- system policy;
- application instructions;
- user input;
- retrieved content
are clearly separated.
This does not guarantee prevention, but it improves control and auditability.
3. Enforce Authorization Outside the Model
Never rely on:
“The model has been instructed not to reveal confidential files.”
Instead:
Only retrieve files the authenticated user is actually authorized to access.
Security policy should be enforced by conventional authorization logic.
4. Apply Least Privilege
AI tools should receive only the capabilities required.
If an assistant needs to read documents, do not automatically provide permission to:
- modify them;
- delete them;
- share them externally.
OWASP specifically recommends limiting functionality, permissions, and autonomy for agent systems.
5. Require Human Approval for Sensitive Actions
Add confirmation for actions involving:
- money;
- privileged account changes;
- deleting data;
- sending external messages;
- security configuration;
- legal or compliance decisions.
High-impact AI actions should not execute solely because the model generated them.
6. Validate Tool Calls
Treat model-generated tool arguments like any other untrusted input.
Validate:
- command parameters;
- file paths;
- recipients;
- URLs;
- database queries;
- permissions;
- destination systems.
7. Validate Model Output
Do not pass raw model output directly into:
- shells;
- SQL execution;
- HTML rendering;
- interpreters;
- high-privilege APIs.
OWASP’s Improper Output Handling guidance highlights the security consequences of trusting model-generated output without sanitization or validation.
8. Minimize Sensitive Context
Do not provide the model with secrets it does not need.
Ask:
- Does it require the entire document?
- Can fields be redacted?
- Can access be scoped by role?
- Should credentials ever be present in the context?
Reducing accessible data limits the impact of successful manipulation.
9. Log and Monitor AI Actions
Monitor:
- tool calls;
- rejected operations;
- authorization failures;
- unusual retrieval behavior;
- sensitive-data requests;
- anomalous usage;
- repeated policy violations.
Detection metrics such as Mean Time to Detect remain relevant to AI-enabled systems as well.
10. Design for Failure
Assume that an attacker may eventually influence the model.
Then design the application so that:
model mistake ≠ security breach.
The model should not independently possess enough authority to turn one incorrect decision into:
- data theft;
- system modification;
- financial loss;
- account compromise.
Prompt Injection and RAG
Retrieval-Augmented Generation improves AI responses by adding information retrieved from external sources.
A typical workflow is:
- receive the user request;
- search a knowledge base;
- retrieve relevant content;
- add that content to the model context;
- generate an answer.
The security concern is obvious:
What if the retrieved content is malicious?
A compromised RAG document may contain instructions designed to influence the model.
Organizations should therefore evaluate:
- document provenance;
- user authorization;
- source trust;
- ingestion controls;
- retrieval permissions;
- document sanitization;
- output validation.
OWASP explicitly notes that RAG does not fully mitigate prompt injection.
Prompt Injection and AI Agents
Agentic systems raise the risk further because the model may decide which actions to perform.
For example, an agent may:
- search a customer database;
- open documents;
- send a message;
- modify a ticket;
- call an external service.
The more tools available, the more potential impact an attacker can create.
A useful rule is:
Do not give an AI agent a permission merely because it might someday be useful.
Grant only what its defined task requires.
This follows OWASP’s Excessive Agency guidance.
Prompt Injection Security Checklist
Inputs
- Are user prompts considered untrusted?
- Can the system process webpages?
- Can it read external documents?
- Can email content enter model context?
- Can multimodal data carry instructions?
Data Access
- Can the model access confidential information?
- Is data scoped to each authenticated user?
- Are sensitive records filtered before retrieval?
- Are secrets excluded unless strictly required?
Tools
- What actions can the model perform?
- Are permissions minimized?
- Are destructive actions restricted?
- Are tool arguments validated?
Automation
- Can actions occur without approval?
- Are high-risk workflows human-gated?
- Can an agent communicate with external systems?
Monitoring
- Are tool calls logged?
- Can suspicious behavior trigger alerts?
- Are authorization failures visible?
- Can administrators revoke an agent or integration quickly?
Frequently Asked Questions
Is prompt injection the same as jailbreaking?
Not exactly.
Jailbreaking generally refers to attempts to bypass behavioral or safety restrictions.
Prompt injection is broader and concerns manipulation of an LLM application’s instructions or behavior, including through indirect external inputs.
OWASP recognizes that the terms overlap but treats prompt injection as an application-security vulnerability.
Is prompt injection the same as SQL injection?
No.
SQL injection exploits improperly constructed database queries.
Prompt injection manipulates how an AI model interprets instructions and untrusted content.
The underlying technologies and defenses are different.
Can prompt injection be completely prevented?
There is currently no single universal defense that guarantees elimination of prompt injection.
OWASP specifically notes that RAG and fine-tuning do not fully solve the problem.
Layered controls are therefore more practical than relying on a single filter.
Does input filtering solve prompt injection?
Filtering helps but should not be the only defense.
Attackers can use:
- indirect instructions;
- obfuscation;
- context manipulation;
- new attack patterns.
The safest architecture assumes that some malicious content will reach the model.
Is prompt injection only a chatbot problem?
No.
Any AI application that processes untrusted information can be affected.
The risk increases significantly when the system can access sensitive data or perform actions.
Why is Prompt Injection LLM01:2025?
OWASP currently places Prompt Injection first in its 2025 LLM Top 10 because it represents a broad application-security risk affecting how models process instructions and untrusted input.
Final Takeaway
Prompt injection is not simply a clever prompt that causes an AI chatbot to behave strangely.
It is a trust-boundary and application-security problem.
The most dangerous combination is:
untrusted content + sensitive data + powerful tools + autonomous action.
Organizations deploying AI should therefore focus on:
- strong application authorization;
- least privilege;
- controlled retrieval;
- output validation;
- tool-call validation;
- human approval for sensitive operations;
- logging and monitoring;
- adversarial testing;
- limiting sensitive context.
The goal is not to create a system where a model can never make a mistake.
The goal is to create a system where:
a model mistake cannot easily become a security incident.
Primary Sources
Use these authoritative external links at the bottom of the WordPress article:
- OWASP LLM01:2025 — Prompt Injection
- OWASP 2025 Top 10 for LLM and GenAI Applications
- OWASP LLM05:2025 — Improper Output Handling
- OWASP LLM06:2025 — Excessive Agency
- OWASP LLM07:2025 — System Prompt Leakage
- NIST AI RMF Generative AI Profile — NIST AI 600-1
NIST describes AI 600-1 as a cross-sector companion to the AI Risk Management Framework intended to help organizations manage trustworthiness considerations across generative-AI design, development, use and evaluation.
