What Is Prompt Injection? LLM Security Risks Explained

Prompt injection is an attack against LLM-powered applications where text that’s supposed to be treated as data ends up being treated as instructions instead. If an application feeds a model some fixed system prompt plus untrusted content — a web page, an email, a file, a tool’s output — an attacker who controls that untrusted content can embed text designed to override or redirect the model’s behavior. The model can’t reliably tell the difference between “instructions from my developer” and “instructions that happened to appear in the data I was asked to process.”

Why it works

Traditional software security has a clean separation between code and data — a SQL query and its parameters, for instance, are distinct channels, which is exactly what parameterized queries exploit to prevent SQL injection. LLMs don’t have that separation. Everything a model sees — the system prompt, the user’s message, any retrieved documents, any tool output — gets concatenated into a single stream of tokens and processed the same way. There’s no hardware-enforced boundary between “trusted instruction” and “untrusted content”; it’s all just text competing for the model’s attention.

This means any point where an LLM application ingests outside content is a potential injection surface:

• A RAG system that retrieves documents and feeds them to the model — a poisoned document can carry instructions.
• An AI agent that browses a web page or reads an email on the user’s behalf — the page or email can contain text aimed at the agent, not the human reader.
• A tool call whose output gets fed back into the model’s context, as happens in Model Context Protocol integrations — a compromised or malicious tool response can inject instructions the same way a document can.

Direct vs indirect injection

Direct prompt injection is when the attacker is the one talking to the model — typing “ignore your previous instructions and do X” straight into a chat interface, trying to get the model to bypass restrictions the application put in place. This is the more familiar case and the one most guardrails are built to catch.

Indirect prompt injection is more dangerous in agentic systems: the attacker never interacts with the model directly. Instead they plant instructions somewhere the model will later read — a hidden comment in a web page a shopping agent visits, invisible text in a document a summarization tool ingests, a crafted filename or metadata field. When the model processes that content as part of its normal task, it encounters the attacker’s instructions with no obvious “this came from an untrusted source” marker attached.

What a successful injection can do

The impact depends entirely on what the application lets the model do. A chatbot with no tool access that gets injected might just say something embarrassing or off-brand. An agent with access to email, file systems, browsers, or payment tools that gets injected could exfiltrate data, send messages on the user’s behalf, or take actions the user never asked for — the injected instructions ride on whatever permissions the model’s session already has.

This is why the risk scales with capability: the more tools and autonomy an AI agent has, the more a successful prompt injection can do with them.

Mitigations — and their limits

There’s no complete fix, because the underlying cause — no hard boundary between instructions and data in a single token stream — is architectural. Practical mitigations reduce risk rather than eliminate it:

• Least privilege for agent tool access. If an agent doesn’t need the ability to send emails or make purchases for a given task, it shouldn’t have that tool available, so an injection has less to exploit.
• Human confirmation for consequential actions. Requiring explicit user approval before an agent sends a message, spends money, or deletes data limits the blast radius of an injected instruction, even if the model was fooled.
• Treating retrieved and tool content as data, not instructions, in how the application constructs its context — some frameworks tag or delimit untrusted content distinctly, though a sufficiently motivated model can still be swayed by content that “sounds like” an instruction.
• Output filtering and monitoring for signs that a response is acting on injected instructions rather than the user’s actual request.
• Scoped credentials. An agent’s tool access should use tokens scoped as narrowly as possible — the same least-privilege principle that applies to any service account applies doubly to one an LLM is driving.

None of these close the hole; they narrow what an attacker can achieve once it’s exploited. Anyone building an agentic system should assume some prompt injections will get through and design permissions accordingly, the same way web applications are built assuming some requests will be malicious rather than assuming injection is fully preventable.

Prompt injection vs traditional injection attacks

	SQL injection	Prompt injection
Root cause	Unescaped input concatenated into a query	No boundary between instructions and data in the token stream
Fix maturity	Solved — parameterized queries	Unsolved — mitigations reduce, don’t eliminate
Attack surface	Any input reaching a raw query	Any content an LLM ingests: prompts, documents, tool output
Primary defense	Separate code and data channels	Least-privilege tool access, human approval gates

The takeaway

Prompt injection exploits the fact that an LLM processes instructions and untrusted content as the same kind of thing — tokens in a shared context — with no reliable way to tell them apart. Indirect injection, where the attacker plants instructions in content the model will later read rather than typing to it directly, is the more serious variant for agentic systems with real tool access. There’s no complete fix yet, so the practical response is to limit what a model’s session can do, require confirmation for consequential actions, and assume some injections will succeed rather than assuming they can all be filtered out.