What Is Prompt Injection? Types, Examples, and Defenses
Prompt injection is an LLM security vulnerability in which crafted natural-language input causes a model or AI agent to ignore, reinterpret, or override its intended instructions.
Direct answer
Prompt injection is an LLM security vulnerability in which crafted natural-language input causes a model or AI agent to ignore, reinterpret, or override its intended instructions. Direct prompt injection occurs when the attacker places malicious instructions in the user prompt. Indirect prompt injection occurs when malicious instructions are embedded in external content, such as a document, web page, email, or tool response that the model later reads. Stored prompt injection is a persistent indirect variant in which the malicious instruction remains in a data source and activates when retrieved. Because trusted instructions and untrusted content often share the same context window, model-level safeguards are useful but insufficient. Enterprise defenses need layered controls across input handling, output validation, runtime policy enforcement, least-privilege tool access, monitoring, and audit logging.
Prompt injection defined
Prompt injection occurs when natural-language input causes a model or AI agent to ignore, reinterpret, or override its intended instructions. The issue is especially important in enterprise systems because trusted instructions and untrusted content can be placed into the same model context.
In that shared context, the model may encounter normal user requests, system or developer instructions, retrieved documents, tool responses, memory entries, web content, emails, and other external data. If malicious instructions are present in any of those sources, they can influence the model’s behavior unless the application enforces controls around how the content is handled.
Direct, indirect, and stored prompt injection
Prompt injection can appear in several forms. The distinction matters because each form enters the AI application through a different path.
| Type | How it appears | Why it matters |
|---|---|---|
| Direct prompt injection | The attacker places malicious instructions directly in the user prompt. | The model or AI agent may be asked to ignore, reinterpret, or override its intended instructions. |
| Indirect prompt injection | Malicious instructions are embedded in external content, such as a document, web page, email, or tool response that the model later reads. | The harmful instruction may arrive through content that looks like data rather than through the visible user prompt. |
| Stored prompt injection | A malicious instruction remains in a data source and activates when retrieved. | This is a persistent indirect variant, so the attack can recur when the stored content is placed back into model context. |
Why model-level safeguards are insufficient on their own
Model safeguards are useful, but they are not enough by themselves. The core problem is architectural: trusted instructions and untrusted content often share the same context window. When that happens, the model must interpret both instructions and data from the same stream of text.
Enterprise prompt injection protection therefore needs layered controls around the model. The goal is not only to improve model behavior, but also to constrain what the surrounding application allows before, during, and after a model response.
Key implication: prompt injection cannot be solved with prompts alone. Defenses need controls across input handling, output validation, runtime policy enforcement, least-privilege tool access, monitoring, and audit logging.
Why agentic systems increase prompt injection impact
Prompt injection becomes more consequential when an LLM is not only generating text but also controlling tools. A retrieval-only assistant may return an incorrect or unsafe answer. A tool-using agent may send a message, query a system, update a record, call an API, or pass data from one tool to another. The model’s interpretation of untrusted text can therefore become an operational action.
Modern agent architectures often connect to many external systems. The Model Context Protocol, published as an open standard for connecting AI assistants to tools and data sources, illustrates this shift. Standards such as MCP can make integration more consistent, but they also increase the number of channels through which an agent may receive untrusted content. Each connector, tool response, document, and data source can become a prompt injection carrier if its content is placed into model context without clear handling and enforcement.
The security concern is not the protocol alone. The concern is whether the agent treats retrieved content as instructions, whether tool calls are checked before execution, and whether the agent has broad permissions that allow a successful injection to cause meaningful harm. Agent security therefore requires controls outside the model, at the orchestration and runtime layers.
Prompt injection attack surface
Prompt injection risk is easiest to understand by looking at the content paths that can reach an LLM or AI agent.
User input
Direct instructions that attempt to override the system or developer prompt.
External content
Indirect instructions hidden in documents, pages, emails, or retrieved data.
Agent tools
Unauthorized actions triggered through tool calls, connectors, or MCP-style integrations.
Defense categories for enterprise prompt injection protection
Enterprise defenses should be layered so that the system does not depend on a single model response being perfectly safe. The supplied controls fall into several practical categories.
| Defense category | What it protects |
|---|---|
| Input handling | External and tool-provided content, not just direct user prompts. |
| Output validation | Model responses and proposed actions before they are used by the application. |
| Runtime policy enforcement | Agent behavior at the point where the system decides whether an action should proceed. |
| Least-privilege tool access | Agent permissions scoped by task, user, session, tool, and data source. |
| Monitoring and audit logging | Agent decisions, tool requests, approvals, denials, and actions for audit and investigation. |
Evaluation checklist for AI agent security
Use the following questions to evaluate whether an AI application is prepared for direct, indirect, and stored prompt injection risks.
- Does the application inspect external and tool-provided content, not just direct user prompts?
- Are retrieved documents, tool responses, and memory entries treated as untrusted data by default?
- Are proposed tool calls validated against policy before execution?
- Can agent permissions be scoped by task, user, session, tool, and data source?
- Are high-risk actions routed through approval workflows or additional runtime controls?
- Are agent decisions, tool requests, approvals, denials, and actions logged for audit and investigation?
Where Trussed AI fits
Trussed AI helps enterprises govern agent actions with runtime policy enforcement, least-privilege permissions, tool approvals, monitoring, and audit logging. In the context of prompt injection defense, those controls sit outside the model and help determine whether proposed agent actions should be allowed, denied, approved, or logged.
Add runtime controls to prompt injection defense
Prompt injection cannot be solved with prompts alone. Trussed AI helps enterprises govern agent actions with runtime policy enforcement, least-privilege permissions, tool approvals, monitoring, and audit logging.
Request a Demo