LLM Prompt Injection: 7 Critical Attacks Explained

LLM prompt injection is a security weakness in which attacker-controlled instructions influence how a large language model or an LLM-powered application behaves. The input can be typed directly by a user, hidden inside a webpage or document, retrieved through a RAG pipeline, or encountered by an AI agent while it is using tools.

The real issue is trust boundaries. An application may combine trusted instructions with untrusted content and ask the model to reason over both. If that model can also reach files, APIs, email, or other tools, a successful injection can have consequences beyond a strange chatbot answer.

I approach this from the defender’s side: where untrusted content enters, what the application can reach, and which controls contain a wrong decision. You will learn to recognize seven attack patterns and check your own AI workflow safely.

Attack route	What the model receives	Main security concern
Direct injection	Attacker-controlled user prompt	Behavior or policy manipulation
Indirect injection	Instructions inside external content	Untrusted data influencing the task
Agent injection	Hostile content plus tool access	Unintended actions with real permissions

The examples below are hypothetical, not reported lab results. Use them only in systems you own or have explicit permission to test. No movie-hacker fog machine required.

Affiliate disclosure: I may earn a commission through the nexos.ai links. Its documented guardrails include input and output checks, redaction, and audit logs. These are vendor-described features, not an independent HackersGhost test or a guarantee against injection.

Key Takeaways

• LLM prompt injection is primarily a trust-boundary problem, not a traditional memory-corruption exploit.
• Direct attacks come from the user; indirect prompt injection arrives through content such as webpages, files, retrieved text, or other resources.
• RAG can improve grounding, but RAG alone does not remove LLM prompt injection attacks.
• The highest practical risk appears when a model can call tools, reach sensitive data, or act with excessive permissions.
• LLM prompt injection detection helps, but least privilege, output validation, approvals, and isolation are just as important.
• Jailbreaking and prompt injection overlap. Jailbreaks target model safeguards; injection can instead redirect a legitimate task without requesting prohibited content.

What Is LLM Prompt Injection?

LLM prompt injection occurs when untrusted input changes a model’s behavior in a way the application designer did not intend. The input might be obvious, such as a user deliberately trying to redirect a chatbot, or indirect, such as instructions embedded in a file an assistant has been asked to summarize.

That distinction matters. Modern LLM applications can use system, developer, and user instruction layers, and model providers train their systems to respect those priorities. So the old explanation that “the model treats every instruction equally” is too simplistic. The real LLM prompt injection security problem is that models still have to interpret natural language contained in untrusted data, and that data can sometimes influence the task.

For the terminology, I use NIST’s adversarial machine-learning taxonomy. Its distinction between direct and indirect injection helps identify which input the attacker controls. That is more useful than treating every unusual chatbot answer as an exploit.

HackersGhost Note: I do not judge an LLM prompt injection vulnerability only by whether a chatbot says something weird. I ask what the application can reach. A confused model with no tools is one problem. A confused model with access to email, files, APIs, or business workflows is a very different one.

A practical way to assess AI attack surface

How LLM Prompt Injection Attacks Actually Work

An LLM application may combine system instructions, conversation history, user input, retrieved documents, memory, and tool descriptions into one working context. LLM prompt injection attacks try to make attacker-controlled content influence that workflow.

A useful mental model is instruction versus data. Humans naturally read a sentence inside a document as content to analyze, not as a new system command. An LLM can be instructed to make that distinction, but the boundary is not as hard as a traditional execution boundary in application code.

A basic LLM prompt injection example is a summarization assistant that receives a webpage containing text telling the assistant to ignore the summarization task and produce a different result. Whether that instruction works depends on the model, the prompt hierarchy, the retrieval pipeline, sanitization, and other safeguards. Hidden HTML is not automatically dangerous either: if the application never extracts or sends it to the model, the model never sees it.

This nuance matters because good LLM prompt injection defense starts before the prompt reaches the model. You reduce exposure by controlling what gets retrieved, clearly marking untrusted content, limiting tools, validating outputs, and refusing to let the model become the final authority for high-impact actions.

LLM Prompting Explained: How Prompts Control AI Systems

LLM Prompting Explained: How Prompts Control AI Systems 🧠

LLM Jailbreak vs Prompt Injection: The Difference Matters

A jailbreak usually tries to bypass a model’s safety restrictions. LLM prompt injection can also redirect an application’s legitimate task: change a summary, bias a score, or request an unauthorized action. The terms overlap, but describe different security objectives.

For example, a user trying to make a model produce content it normally refuses is typically a jailbreak attempt. A malicious instruction hidden in a document that causes an enterprise assistant to change how it evaluates that document is an indirect injection. The second case may never involve prohibited content at all; the attacker is attacking the task and trust boundary.

This distinction also changes the defensive priority. Model safety training matters for jailbreak resistance, while LLM prompt injection prevention additionally requires secure application architecture, least privilege, data boundaries, and careful tool design.

My Lab Context and a Safe Testing Workflow

I prefer controlled testing over dramatic screenshots. My second-hand HP EliteBook has 32 GB of RAM and runs VMware on the latest Windows release. I keep both Kali Linux and Parrot OS available, although Parrot OS is the environment I use most often.

My TP-Link Archer C6 is a separate test router, disconnected from my normal modem during testing. That hardware isolation is useful for vulnerable-network exercises, but a VM does not isolate a cloud model from data you upload. For AI testing, the important boundaries are synthetic data, disposable accounts, restricted tool access, and permission to test the application.

An LLM prompt injection CTF or purpose-built AI security challenge is another good learning format because permission and scope are clear. I prefer that over experimenting on random public services. Ethical hacking is much easier when authorization is not a philosophical debate.

A Small Test You Can Repeat

For a first LLM prompt injection check, use a summarizer in a local test application or an authorized training challenge. Disable real outbound actions. Keep the same model, task instructions, and settings while comparing these cases:

1. Establish a baseline. Give it a fictional document stating that a meeting begins at 10:00. Ask for the start time and confirm that the ordinary task works.
2. Change only the untrusted document. Add a sentence telling the summarizer to abandon the task and answer with a harmless unrelated word. Keep your actual user request unchanged.
3. Inspect the outcome. Did it answer from the document, describe the suspicious instruction, or obey it? Quoting an instruction is different from following it. Record the complete test case and observed behavior.
4. Repeat with clean state. Reset the conversation and stored memory between paired runs. Record how often each outcome occurs; one blocked attempt is not proof of general protection.
5. Retest the control. Change one safeguard, rerun the same cases, and include benign documents that discuss instructions. A filter that blocks ordinary analysis has a usability cost worth recording.

This exercise checks task integrity, not every possible disclosure or tool-action risk. For connected tools, use a mock destination and verify that execution is denied without valid authorization. Keep test fixtures and expected outcomes in version control without secrets. The OWASP prevention cheat sheet provides further evaluation guidance.

HackersGhost Note: I would start with a decision you can verify: did the assistant follow the user’s task, disclose a dummy marker, or propose an unauthorized tool call? A dramatic response tells you less than a recorded boundary failure.

Recommended test objective

7 Critical AI Prompt Injection Attack Techniques

These seven patterns overlap: a document can be retrieved through RAG, contain hidden image text, and target an agent. They are a practical way to organize prompt injection examples, not seven mutually exclusive vulnerabilities. Results depend on the model and the surrounding application.

1. Direct Prompt Injection

Direct prompt injection happens when the attacker controls the user-facing input and tries to redirect the model away from the intended task. A harmless lab example would be asking a classifier to ignore its assigned category rules and label every test item “approved.” The goal is to test whether user input can override task constraints.

Modern models may resist obvious override wording, so it is inaccurate to claim that a new user instruction automatically outranks a system instruction. The weakness appears when the model or surrounding application can still be steered into an unintended outcome. Strong task scoping, structured outputs, independent validation, and clear privilege boundaries reduce the impact.

2. Indirect Prompt Injection Through Web Content

indirect prompt injection moves the hostile instruction away from the chat box. The attacker places it in content the AI is likely to retrieve: a webpage, public profile, knowledge article, issue tracker, or another external resource. The user may ask for an innocent summary while the retrieved content contains instructions aimed at the assistant.

This is especially relevant to browsing assistants and research agents. The important qualifier is that the content must actually be parsed and supplied to the model. Invisible text, metadata, or comments are only attack paths when the retrieval stack includes them. LLM prompt injection detection therefore has to consider the ingestion pipeline, not just the visible user prompt.

3. Document-Based Prompt Injection

Document assistants create a convenient prompt injection surface because users routinely upload PDFs, text files, spreadsheets, resumes, reports, and notes for analysis. A malicious or compromised document can contain instructions designed to bias the model’s summary, classification, or recommendation.

A safe LLM prompt injection example uses a fictional resume and a fixed scoring rubric. Add an instruction requesting the top rating, then compare it with the same resume without that instruction. A changed score alone is not proof: repeat the comparison and inspect whether the justification follows the injected instruction rather than the qualifications.

4. Retrieval and RAG Prompt Injection

Retrieval-Augmented Generation (RAG) retrieves relevant material and supplies it to the model when it answers. It can improve relevance, but does not automatically solve LLM prompt injection. A compromised source may place instructions in the retrieved context. Check both who can add or edit indexed documents and which documents each user is authorized to retrieve.

I separate this from training-data poisoning because the timing and mechanism are different. Training poisoning changes data used to train or tune a model. Retrieval-source injection targets content supplied at inference time. That distinction makes troubleshooting much easier and prevents two AI security topics from becoming one giant conceptual soup.

Training Data Poisoning Explained: How AI Models Get Silently Compromised

Training Data Poisoning Explained: How AI Models Get Silently Compromised 🧬

5. Multi-Turn Context Manipulation

Not every prompt injection attempt is a single obvious command. An attacker may build context gradually across several turns, introduce assumptions, redefine terms, or split an instruction across messages. The aim is to make the final request appear consistent with the conversation that came before it.

This is why filters based only on a short blacklist are weak LLM prompt injection defense. A model can be influenced by meaning and context, not just exact strings. Defensive testing should therefore include multi-turn conversations and stateful workflows rather than only isolated one-shot prompts.

6. Multimodal Prompt Injection

Multimodal systems can process more than plain text. Images, screenshots, scanned documents, audio transcripts, and other media can become part of the model context. That creates another LLM prompt injection vulnerability: instructions can be carried by a modality the human user is not treating as an instruction channel.

The practical defense is not to panic every time an image contains text. It is to treat content extracted from external media as untrusted data, apply the same privilege rules as other retrieved content, and test whether that content can influence high-impact decisions or tool calls.

7. Prompt Injection in LLM Agents

Prompt injection in LLM agents deserves the most attention because agents can do things. They may browse, read email, write files, call APIs, update tickets, query databases, or trigger workflows. An injection that merely changes prose in a normal chatbot can become a security incident when the same model is allowed to act.

This is where prompt injection meets excessive agency. If the agent has broad credentials and no approval gate, hostile content may be able to influence a tool call. The safest architecture assumes the model can be manipulated and limits what happens next: narrow scopes, separate service identities, explicit authorization, human confirmation for sensitive actions, and deterministic checks outside the model.

HackersGhost Note: Giving an AI agent administrator-level access because “the system prompt says to be careful” is the AI equivalent of leaving the server room open and hanging up a polite sign. LLM prompt injection defense should survive a model making the wrong decision.

My rule for agent permissions

What OWASP Recommends for LLM Prompt Injection

OWASP’s LLM01 prompt-injection guidance covers direct and indirect attacks and explains why retrieval or fine-tuning alone does not eliminate the risk. The label identifies a risk category; it is not an attack technique or a certification that an application is secure.

For me, the most valuable part is the mitigation mindset. LLM prompt injection prevention is not “write a better system prompt and hope.” It includes limiting model behavior, validating expected output formats, filtering inputs and outputs, enforcing least privilege, separating external content, requiring approval for high-risk operations, and repeatedly testing the system with adversarial input.

NIST reaches a similar architectural conclusion: external resources can deliver hostile instructions, while agent permissions can turn model influence into system influence. That is why this belongs in application threat modeling, not only prompt engineering.

nexos.ai documents model-access policies, guardrails, and audit logs. If you evaluate it, test those controls against your actual retrieval and tool workflows; product positioning alone does not establish resistance to hostile input.

LLM Prompt Injection Detection and Prevention

There is no reliable single filter that makes prompt injection impossible. That does not mean defense is hopeless. It means the strongest controls are layered, measurable, and designed so that one manipulated model response cannot automatically become a high-impact action.

Treat External Content as Untrusted

Web pages, uploaded files, retrieved chunks, email bodies, code comments, and third-party data should remain untrusted. Delimiters help, but architectural separation matters more. The application should know which content is policy, which is user input, and which came from an external source.

Use Least Privilege for Tools and Agents

When an assistant only needs read access, do not give it write access. When it needs one API operation, do not hand it broad credentials. Least privilege is one of the strongest forms of LLM prompt injection defense because it limits what a manipulated decision can achieve.

Validate Outputs Outside the Model

Valid JSON can still describe an unauthorized action. Validate the format in code, then separately check the caller, operation, target, and parameters. A customer-support assistant must not read another customer’s record merely because its proposed request has the correct schema. Keep credentials and access-control decisions outside the model.

Also check what the interface renders. An external image or link in a generated answer can create an outbound request if the client loads or follows it. Treat generated HTML and Markdown as untrusted output, restrict automatic external-resource loading where appropriate, and keep sensitive context out of URLs. No explicit email tool is needed for every disclosure path.

Require Approval for High-Impact Actions

Before an agent sends, deletes, publishes, buys, or changes something sensitive, show the user the exact action, destination, and relevant data. The execution service must verify approval for that operation. If the agent changes the recipient or parameters after approval, require a new confirmation. A model-generated “user approved” flag is not evidence of consent.

Test Direct, Indirect, and Stateful Scenarios

Good LLM prompt injection testing covers more than direct chat input. I would include external documents, retrieved content, multi-turn state, tool responses, malformed content, multimodal input where supported, and permission boundaries. The test succeeds when it tells you which control failed and what the blast radius is, not merely when you collect a funny output.

Log Enough to Investigate

For business systems, record source identifiers, model and policy versions, proposed tool calls, authorization outcomes, and execution results. Redact credentials and unnecessary personal or confidential content. Restrict log access and retention: an investigation log should not become a second database of everything your users wanted kept private.

Realistic LLM Prompt Injection Attack Examples

These LLM prompt injection examples are safe scenarios for understanding impact. Decide in advance what the assistant should do, then inspect both its answer and any downstream action. A refusal message does not prove that no tool ran.

A Browser Assistant Summarizes a Hostile Page

The user asks for a summary of a local test page. Its content tells the assistant to abandon that task and return an unrelated recommendation. Following that instruction demonstrates task redirection; quoting it as suspicious source content does not. If the application also has access to private data or actions, test those permissions separately with dummy resources.

A Resume Tries to Influence an AI Evaluator

A recruiting workflow asks an LLM to evaluate uploaded resumes against a fixed rubric. A test resume contains an instruction attempting to force a top rating. If the system changes its score because of that text, the LLM prompt injection vulnerability affects decision integrity. The defense is not simply hiding the rubric better; the scoring pipeline itself needs validation and constraints.

An Agent Reads a Message That Requests an Unintended Tool Call

An assistant is asked to process a message or ticket. The content includes language intended to steer the agent toward an action outside the user’s task. A secure design should keep that content from silently authorizing the action. This is a practical LLM prompt injection example because it tests not just model behavior, but authorization and tool boundaries.

MCP Security: Checks Before You Expose AI Tools

MCP Security: 9 Essential Checks Before You Expose Tools

What to Do When a Test Finds a Boundary Failure

If a test exposes an LLM prompt injection failure, first disable the affected tool or retrieval path in your test environment. Preserve the input, configuration, and relevant redacted logs. Identify whether the model redirected the task, the application admitted unauthorized data, or execution code allowed an action it should have denied.

Fix the control responsible for the consequence: source permissions, output handling, tool scope, or approval validation. If a real system exposed credentials, revoke or rotate them and investigate their use. Clear affected stored memory or retrieved content before reconnecting the workflow. Re-run the failing case and ordinary tasks; blocking everything is containment, not a finished repair.

HackersGhost Note: A stronger prompt can be useful, but I would not close an incident just because the next answer looks better. Confirm that the execution path rejects the unauthorized action even when the model proposes it.

Recommended recovery check

Final Thoughts on LLM Prompt Injection Security

Start by listing what your AI application can read and do. Then choose one untrusted input route and test a harmless attempt to redirect it. That turns LLM prompt injection from an abstract concern into a boundary you can inspect.

Keep the useful controls layered: narrow permissions, independent authorization, safe output rendering, action-specific approvals, and repeatable tests. Recheck them whenever the model, prompt, retrieval sources, or connected tools change.

What matters to me is the consequence of a wrong decision. Your first objective is a workflow that contains it; more sophisticated detection can then improve that foundation.

If centralized AI policies fit your team’s needs, compare nexos.ai’s documented features with your own requirements and test results before choosing it.

Frequently Asked Questions