An AI assistant is asked to summarize an email. The email contains a sentence addressed to the assistant, telling it to ignore the summary task and do something else. That clash between the app’s instructions and the content it reads is the basic idea behind prompt injection.
It matters because modern AI features may read messages, webpages, documents, or tool results—and some can also call tools or access business data. Prompt injection does not mean an attack will always work, but it does mean you should not treat a model’s prompt as a security boundary.
In brief: Prompt injection is an attempt to steer an AI model through instructions in user input or external content. The risk depends on what the surrounding application lets the model see and do. Stronger system design can reduce the likelihood and impact, but prompt wording alone cannot guarantee prevention.
What is prompt injection?
Prompt injection is a way of influencing a large language model’s behavior by placing instructions in content the model processes. Those instructions may conflict with the app developer’s directions or with the user’s intended task. OWASP’s LLM01:2025 Prompt Injection guidance describes inputs that alter a model’s behavior or output in unintended ways, including content that may not be visible to a person but is still parsed by the model.
For example, a document-summarizing assistant is told to produce a neutral summary. A document it reads contains an instruction aimed at the AI to change the task. The model may follow the original task, the embedded instruction, or produce a muddled result. The important point is that natural-language instructions inside the document can influence the response; they are not automatically harmless just because they appear in a document rather than a chat box.
Direct vs. indirect prompt injection
Security guidance commonly separates prompt injection by where the instruction enters the AI system:
| Type | Where the instruction comes from | Simple example |
|---|---|---|
| Direct | The user-controlled prompt or form input | A person asks a support bot to ignore its normal task and return a test phrase instead. |
| Indirect | External content the AI is asked to read, retrieve, or process | An email or webpage includes an instruction aimed at the summarizing assistant. |
Indirect attacks can be harder for an ordinary user to spot because the person using the AI may not have written or even noticed the instruction. It can be in an email, a webpage, a shared document, a résumé, or other material. OWASP notes that instructions do not always need to be human-visible if the model can parse them. NIST’s Adversarial Machine Learning taxonomy also distinguishes direct prompting from indirect prompt injection in its generative-AI attack taxonomy.
This is not only a concern for autonomous agents. A text-only system can produce a misleading summary or assessment. If a connected application can also read private records, send messages, or update a database, the potential impact may be greater. The impact depends on system design and permissions—not simply on whether the AI is called an “agent.”
Is prompt injection the same as jailbreaking?
The terms overlap, and different security sources do not always use them in exactly the same way. OWASP describes jailbreaking as a related form of prompt injection that aims to make a model disregard safety protocols. In everyday discussion, “jailbreak” often refers specifically to bypassing a model’s content restrictions, while prompt injection can also target an application’s task, data access, or tool use. When reading a report, check how that source defines its terms.
Why prompt instructions are not a security boundary
It is tempting to compare prompt injection with SQL injection, but that analogy has limits. The UK National Cyber Security Centre explains that language models do not enforce a reliable security boundary between instructions and data inside a prompt. Its guidance argues that systems should be designed to reduce the likelihood and impact of injection rather than assuming a special phrase or prompt rule will eliminate it. Read the NCSC’s article, “Prompt injection is not SQL injection”, for the detailed comparison.
This does not mean every AI app is immediately exploitable, or that defensive work is pointless. It means that instructions such as “never reveal private information” should not be the only thing standing between a model and private information. The surrounding software needs to enforce access and action rules independently.
What can go wrong?
Depending on the app’s access and safeguards, an injection attempt could affect a response, distort a decision, expose information in context, or influence a connected tool. Possible examples include:
- A summary that includes attacker-chosen wording or leaves out an important caveat.
- An AI-assisted screening or review that is influenced by instructions inside a document.
- A support assistant that produces an answer outside the intended policy.
- A tool-using system that proposes or attempts an action the user did not request.
These are risks, not guaranteed outcomes. OWASP’s 2025 guidance describes possible effects such as sensitive-information disclosure, content manipulation, unauthorized function access, and influence over critical decisions. A 2026 peer-reviewed paper in Neural Computing and Applications examines indirect prompt injection, including a CV-comparison scenario; it is a study of the risk, not evidence that every hiring or review system is compromised. Its abstract and article provide more detail.
How to reduce prompt-injection risk
No single prompt, filter, or model choice should be treated as a complete fix. OWASP and the NCSC emphasize design controls that limit what a successful manipulation could do. For a small business or product team, start with these steps:
1. Give the model less access
Only connect the data and tools the task needs. Keep private records out of context unless they are required, and enforce user permissions in the application rather than asking the model to decide who is allowed to see what. Use least-privilege credentials for connected services. If a summarizer only needs to read one supplied document, it generally should not also have broad mailbox or database access.
2. Put important rules outside the prompt
Use ordinary application logic to check identity, authorization, allowed destinations, amounts, record IDs, and other consequential parameters. A model can suggest an action; deterministic code should enforce whether that action is allowed. Never put passwords, API keys, or other secrets in a system prompt and expect the prompt to keep them secret.
3. Require confirmation for consequential actions
Before an AI-connected system sends a message, changes a record, makes a purchase, or takes another high-impact action, show a person the exact proposed action and its parameters. Approval is useful only if the reviewer can understand what will happen. NodeAI.tech’s n8n lead-triage tutorial illustrates a workflow where a human reviews a proposed spreadsheet update before it is written.
4. Treat external content and model output as untrusted
Separating or labeling external text in a prompt can help communicate its role, but it is not a guarantee that the model will ignore instructions inside it. Validate outputs before passing them to another system. Use strict schemas and allowlists where appropriate, escape or sanitize content before rendering it, and do not turn free-form model text directly into shell commands, SQL, or privileged API actions.
5. Test the whole workflow, not just the prompt
Use synthetic data and a test environment to check what happens when a harmless instruction conflicts with the task. For example, ask a test summarizer to process a dummy document that contains a benign instruction to return a test marker instead of a summary. Check whether the app’s output or tool behavior changes. Do not test with real customer data, production credentials, or actions that could affect real users. Also test what happens if the model refuses, returns malformed output, or the approval step is denied.
Log enough context to investigate unexpected behavior, while respecting privacy and retention rules. Review changes when adding a new document source, connector, or tool: each one can change what the model reads or can do. NCSC cautions against relying on simple deny-lists of familiar attack phrases, since wording can vary.
A quick risk check for a small business
Before connecting an AI assistant to a workflow, answer these questions:
- What can the model read? List user input, documents, emails, websites, and retrieved records.
- What can it influence? Note whether it only drafts text or can also call tools, update data, or message people.
- What would the worst plausible action affect? Consider customer data, money, access, reputation, or a consequential decision.
- What blocks that action outside the model? Verify permissions, validation, and human approval in the surrounding software.
- How will you notice and recover? Decide what to log, who reviews alerts, and how to reverse an incorrect change.
If the model does not need to act, keep it in a drafting or summarizing role. For a broader explanation of agents and their tool use, see our beginner’s guide to AI agents. If you are building an AI workflow that processes articles or other external text, our n8n content-repurposing example can help you think through where human review belongs.
Frequently asked questions
Can prompt injection be hidden in an image or document?
It can be embedded in external content, including text a person may not notice, if the model or application parses it. OWASP also discusses multimodal risks where instructions in an image could affect a model that processes both text and images. Do not assume that content is safe just because it looks ordinary in a viewer.
Does retrieval-augmented generation (RAG) prevent prompt injection?
No. RAG can help an app retrieve relevant material, but it does not by itself create a security boundary between trusted instructions and untrusted retrieved content. OWASP says RAG and fine-tuning do not fully mitigate prompt injection. Apply access controls and validation around the entire workflow.
Can I stop prompt injection with a better system prompt?
A clear system prompt can help guide the model, but it should not be the only protection. Use application-level permissions, limited tools, validation, and review for important actions. Treat prompt-level defenses as one layer, not as a guarantee.
What should I do if an AI tool follows an injected instruction?
Stop or disable the affected action if possible, preserve relevant logs according to your privacy policy, check what data or tools the system could access, and review any actions it took. If sensitive data may have been exposed, follow your organization’s incident-response and notification procedures.