Prompt Injection in LLM Security: Threats and Defenses

A traditional web application separates code from data through syntax. A parameterized query marks which part of a request is an instruction and which part is user input, and the database treats that input strictly as data. A large language model (LLM) lacks a comparable boundary, since system instructions and user messages reach the model as text in the same context, leaving the model to infer which parts are commands.

This architectural characteristic underlies most security problems in LLM applications. The Open Worldwide Application Security Project (OWASP) ranks this vulnerability first among the ten risk categories it tracks for LLM applications, listing it as LLM01:2025. The peer-reviewed survey Prompt Injection Attacks in Large Language Models and AI Agent Systems, published in Information in January 2026, documents that framework alongside the incidents behind it. No single control completely eliminates prompt-injection risk, because the flexibility the attack exploits is the same flexibility that lets the model follow instructions written in natural language.

Containment is the realistic objective. This article covers why LLM security differs from conventional application security, then works through the threat classes you are defending against and the reason autonomous agents raise the stakes. It closes with the controls that limit damage and an honest account of what they fail to stop.

Why LLM Security Is an Architecture Problem

Precision about the instruction-data ambiguity matters, since it determines which defenses can work. When a system prompt establishes a role and a user message arrives, the model processes both as tokens in a single context. Nothing in the format marks one as privileged. The model infers hierarchy from meaning, which persuasive content can renegotiate at any point.

This is where the comparison to SQL injection stops holding. Parameterized queries solved SQL injection by moving the instruction boundary out of the string and into the protocol, so no input can cross it. LLMs offer no equivalent mechanism. Delimiters and structured formats help, though the model treats them as ordinary text that sufficiently persuasive content can override.

Your objective therefore changes because OWASP itself acknowledges that fool-proof prevention remains unclear given the stochastic nature of these models. That leaves the damage an injection causes as the variable you can still reduce. Every control described below follows from that position, which also underpins the applied security thinking covered across these engineering insights.

The Threat Classes You Are Defending Against

LLM security threats fall into a small number of categories, separated by where untrusted content enters your system. Knowing the category tells you which boundary failed:

• Direct injection: A user crafts input that overrides the behavior your system prompt established. This category includes jailbreaking, which targets safety constraints specifically. It requires the attacker to interact with your application, which makes it the most visible class.
• Indirect injection: Your model ingests attacker-controlled content from an external source such as a web page or an incoming support ticket, and acts on instructions hidden inside it. The victim performs no suspicious action, as simply asking the assistant to summarize a file is enough. This class scales well for an attacker, given that a single poisoned document can affect every user whose assistant later reads it.
• Data and retrieval poisoning: An attacker corrupts the knowledge base your retrieval-augmented generation (RAG) pipeline draws from, so the model returns attacker-influenced answers to ordinary questions. The compromise persists until you find and remove the poisoned content.
• Tool and agent abuse: The model holds function-calling privileges, and injected instructions redirect those privileges toward the attacker’s goals. The model behaves as designed while acting on an instruction it should never have accepted.

The table below maps each class to the boundary involved and the control that carries the primary defensive load:

Threat Class	Where Untrusted Input Enters	What an Attacker Gains	Primary Control
Direct injection	User-facing prompt	Behavior outside your intended scope	Input handling with output verification
Indirect injection	Retrieved or ingested content	Silent control of a session	Isolation of external content
Retrieval poisoning	Knowledge base or vector store	Durable influence over answers	Provenance checks and access control
Tool and agent abuse	Any of the above, then tool calls	Actions taken with your credentials	Least privilege and sandboxing

The final column repeats a single theme. The controls that matter operate on privilege and isolation, which is a different problem from detecting malicious text.

Retrieval poisoning deserves particular attention for how little effort it requires. In the PoisonedRAG study, presented at the 2025 USENIX Security Symposium, researchers reached a 90 percent attack success rate by injecting five crafted texts for each targeted question into a knowledge database holding millions of entries. A small number of passages written to match the queries an attacker cares about can redirect a retrieval pipeline, even when the knowledge base is very large. That asymmetry favors the attacker heavily, which is why provenance verification belongs in your pipeline before the knowledge base reaches production scale.

Why Agents Raise the Stakes

The risk profile depends on what the model is permitted to do. A text-only assistant exposes you to misleading output or extracted system instructions. An agent holding tool access converts the same injection into actions taken in systems that trust its credentials.

The Information survey frames the danger through what practitioners call the lethal trifecta, three capabilities that together turn an agent into a serious exfiltration risk:

• Privileged data access: The agent can read sensitive or confidential information.
• Exposure to untrusted content: It processes input an attacker can influence, such as web pages or incoming documents.
• External communication: It can send data outside your environment, whether through an outbound request or a rendered link.

Any deployment holding all three deserves your maximum scrutiny, and the paper documents cases where that combination produced real compromise.

This is the confused deputy problem in a new setting. The agent holds legitimate credentials and acts on instructions whose origin it cannot verify. Authorization separates from authentication, as the system confirms that the agent may perform an action without establishing who actually requested it.

Defenses That Work and Where They Fall Short

Each control below reduces risk, and none of them closes the vulnerability. Knowing where each stops is what keeps your threat model accurate.

Input filtering catches unsophisticated attempts and fails against adaptive attackers, who test inputs against your filter and adjust until one passes. Semantic filters that assess intent perform better than keyword matching, though they carry false positive rates that degrade the product when tuned aggressively.

Context isolation through delimiters or structured formats raises the effort required and remains bypassable, since the model reads your delimiters as text. Treat isolation as friction that raises cost without enforcing a limit.

Sandboxing is stronger, because it accepts that injection will sometimes succeed and constrains what follows. Running tool execution in an isolated environment limits the blast radius to that environment. Least privilege does comparable work by scoping each agent’s permissions to its actual task, so a compromised agent cannot reach systems it never needed.

Human approval for consequential tool calls is among the most dependable controls in practice, and it reduces automation benefits that made the agent valuable. You have to decide which operations warrant that interruption.

A Practical Defense Sequence

The five steps below form a review you can run against an existing system.

Step 1: Map every point where untrusted content enters. Trace user input and retrieved documents, along with tool outputs and any third-party content entering the context window. The indirect paths are the most commonly overlooked, and attackers favor them for that reason.

Step 2: Scope agent privileges to the task. Grant read access where write access is unnecessary, and limit each credential to the specific systems the workflow requires. Audit permissions that accumulated during development.

Step 3: Sandbox tool execution. Run agent actions inside an isolated runtime so that a successful injection cannot reach your production systems directly. Accept the overhead as the price of a contained failure.

Step 4: Treat model output as untrusted input. Anything the model produces that flows into another system needs the validation you would apply to user input, since OWASP classifies improper output handling as its own vulnerability category. Output passed to a shell or a database is where injection becomes code execution.

Step 5: Monitor tool-call behavior against a baseline. Record what normal sequences look like for each agent, then alert on deviations such as unexpected data access or unusual call ordering. Non-deterministic systems make this harder than traditional anomaly detection, which is why the baseline needs to be specific to each workflow.

Running that review demands two distinct capabilities. It requires sufficient security reasoning to recognize where a trust boundary has failed, alongside enough architectural knowledge of these models to judge which risks call for controls beyond prompt design.

What Better Prompts Cannot Fix

Each step in that sequence holds even when the model follows an injected instruction, which is why the sequence operates at the level of architecture. Prompt-level defenses work inside the model’s own behavior, and three of them receive more confidence than their performance supports. Knowing where they stop will keep you from a false sense of security.

System prompt hardening lowers exposure without removing it. Instructions telling the model to ignore embedded commands increase the effort an attack requires, and determined attackers circumvent them through role-playing or gradual multi-turn pressure that erodes the boundary.

Alignment tuning improves refusal behavior in isolation without surviving agent deployment. The same survey records safety-aligned flagship models complying with sophisticated attacks once they operate with tool access and process untrusted text, because the failure occurs at the workflow level, well outside what refusal training governs.

Detection by pattern matching carries the same limitation. Detectors examining single requests for suspicious substrings give you little protection against indirect attacks distributed across several agent calls, where no individual request appears malicious.

Conclusion

Prompt injection, the LLM security threat that OWASP ranks first, persists because models interpret instructions and data through the same mechanism. Your defenses should therefore assume that some injection attempts will succeed. Defenses built on that assumption restrict privilege and enforce isolation, limiting what an attacker reaches once inside, while filtering and prompt hardening reduce volume without providing a boundary.

Run the trifecta test against your highest-privilege agent this week. Establish whether it holds privileged data access while processing untrusted content, and whether it can communicate externally. An agent holding all three matches the pattern behind the compromises the survey documents, and removing any one of them breaks the exfiltration path that the combination creates.