The short answer
Prompt injection is what happens when text a model was supposed to read gets treated as an instruction to follow.
The cause is structural. A language model receives instructions and data through the same channel. To a person, "summarize this email" and the contents of the email are obviously different kinds of thing. To the model they are words in sequence, and it has no reliable mechanism to tell which is which.
(cite index="40-1">Prompt injection holds the top spot in the OWASP Top 10 for LLM Applications for the second consecutive edition, because LLMs process instructions and data in the same channel without clear separation, which means an attacker can craft input the model interprets as a new instruction rather than content to process.</cite>
The important consequence for enterprise teams: (cite index="40-1">you cannot patch your way out of prompt injection, because it exploits LLM design itself.</cite> The response is architectural. Decide what the model is allowed to read, what it is allowed to do with what it reads, and where a human decision is required before anything executes.
You also do not need an attacker to trigger it. Ordinary content can contain text that reads as an instruction.
Key takeaways
- Prompt injection is LLM01 in the OWASP Top 10 for LLM Applications 2025, the first entry for a second consecutive edition.
- The direct variant comes from user input. The indirect variant comes from documents, web pages, emails, and other content the system retrieves. The indirect one is the enterprise problem.
- No prompt-level defense is complete, because the vulnerability is a property of how models process input.
- Containment comes from limiting what the model can access and what it can execute, not from instructing it to behave.
- Risk scales with agency: a model that only summarizes has a small blast radius, a model with tool access has a large one.
- The boundary has to be explicit and owned. An implicit boundary is an assumption waiting to be tested.
What is prompt injection?
Prompt injection is a vulnerability in which text within the data an LLM processes is interpreted as an instruction, causing the model to behave in ways its operator did not intend.
It is frequently compared to SQL injection, and the analogy holds at the level of cause: both arise when a system fails to separate instructions from data. The analogy breaks at the level of remedy. SQL injection is solved by parameterized queries, which enforce the separation structurally. No equivalent exists for natural language input to a model, because the separation the model would need to enforce is semantic rather than syntactic.
(cite index="43-1">The OWASP guidance is explicit on this point: given the stochastic influence at the heart of how models work, it is unclear whether fool-proof prevention methods for prompt injection exist.</cite>
Direct and indirect injection
The two variants have different threat surfaces and different defenses.
| Direct injection | Indirect injection | |
|---|---|---|
| Source | The user's own input | Content the system retrieves or processes |
| Example | A user types instructions telling the model to disregard its configuration | Text embedded in a document, web page, ticket, or email the model reads |
| Who is targeted | The application operator | The user of the application |
| Visibility | The input is logged and inspectable | The instruction may be invisible in rendered content |
| Enterprise relevance | Moderate: internal users, some abuse potential | High: any RAG system, document processor, or agent with retrieval |
(cite index="40-1">Indirect injection is the subtler case: attackers embed instructions in documents, websites or other content the LLM later processes, and when the model summarizes that content it may follow the embedded instructions as if they were legitimate. The 2025 list also highlights multimodal injection, where instructions are hidden in images or other non-text inputs.</cite>
For most enterprise deployments the indirect variant is the one that matters, because enterprise systems are built specifically to retrieve and process content the organization did not author: vendor documents, customer emails, support tickets, uploaded files, external web pages.
(cite index="43-1">A concrete example from the OWASP material: an attacker uploads a resume containing split malicious prompts, and when an LLM evaluates the candidate the combined prompts manipulate the model's response, producing a positive recommendation regardless of the actual contents.</cite>
Why this is an architecture problem
The instinct is to solve it in the prompt. Add instructions telling the model to ignore embedded commands. Add a rule that only the system prompt carries authority.
That reduces the success rate of naive attempts. It does not close the gap, for a structural reason: the defense and the attack occupy the same channel. Any instruction you can write to constrain the model, an attacker can write text designed to reframe.
The productive framing is containment rather than prevention. Assume some fraction of injections will succeed, and design so that success is not catastrophic.
Three questions define the containment boundary.
What can the model read? Every source of untrusted content is an injection vector. A model with access to a public web page, a customer-uploaded document, or an inbound email is processing text an adversary can author.
What can the model do with what it reads? A model that produces text has a small blast radius. A model that can call tools, query databases, send messages, or modify records has a large one. Risk is a function of agency, not of input volume.
Where does a human decide? Any action with material or irreversible consequence should require a person, regardless of model confidence. Confidence is not a security control, because a successfully injected model is confident.
Containment layers
Where each control actually helps
| Layer | Control | What it stops | What it does not stop |
|---|---|---|---|
| Input | Segregate and label untrusted content | Reduces naive injection success | Sophisticated reframing |
| Input | Adversarial testing and regression suites | Known attack patterns | Novel patterns |
| Model | System-prompt constraints, defined output formats | Casual and opportunistic attempts | Determined attacks |
| Output | Validation against expected format and schema | Malformed or off-pattern output | Semantically valid malicious output |
| Privilege | Least-privilege scoping of tools and data access | Blast radius of a successful injection | The injection itself |
| Action | Human approval for material or irreversible actions | Consequence of a successful injection | The injection itself |
| Monitoring | Anomaly detection on tool calls and output patterns | Undetected exploitation over time | The first occurrence |
The bottom three layers are the ones that hold when the top four fail. Programs that invest only in the top four have a defense that works until it does not.
Practical controls for enterprise deployments
OWASP's mitigation guidance points toward defense in depth. (cite index="40-1">Mitigation requires combining input validation with output filtering, privilege restrictions and human-in-the-loop controls for sensitive operations, along with constraining model behavior through system prompts, defining expected output formats, and segregating external content so untrusted data cannot influence instructions.</cite>
Translated into decisions an enterprise team has to make:
1. Classify every input source by trust level
Build an inventory: which content the model processes is authored internally under governance, which comes from known counterparties, and which is fully untrusted. Retrieval from an internal governed corpus is a different risk profile from processing an inbound attachment.
2. Scope tool access to the minimum
For each tool the model can call, ask what a successfully injected model could do with it. A read-only query against a scoped dataset is very different from a write action against a system of record. Most deployments grant more access than the use case requires because the integration made it available.
3. Separate the reading context from the acting context
A useful pattern: the component that processes untrusted content produces structured output only, with no tool access. A separate component with tool access consumes that structured output. The injection can corrupt the content of the analysis. It cannot directly trigger an action.
4. Require human approval for material actions
Any action that moves money, communicates externally, modifies a record of consequence, or affects an individual should require a person. This is the same boundary logic that governs agent autonomy generally: score the decision on cost of error and reversibility, and set the tier accordingly.
5. Validate output against a schema
Defining an expected output format turns a class of injection outcomes into a detectable anomaly. It does not stop semantically valid malicious output, but it narrows the surface.
6. Run adversarial testing as a regression suite
Treat injection attempts as test cases that run on every change to prompts, retrieval configuration, or model version. A prompt-injection regression suite is a standard control in current governance frameworks.
7. Monitor for the signals a successful injection produces
Unexpected tool calls, output that departs from the established distribution, retrieval patterns that do not match the query, sudden changes in escalation or refusal rates. The first injection will not be caught by prevention. It can be caught by monitoring.
Who owns this
Prompt injection sits awkwardly between security and product, which is why it often has no owner.
| Function | Responsibility |
|---|---|
| Security | Threat model, adversarial testing, incident response, monitoring signals |
| Platform / AI engineering | Privilege scoping, context separation, output validation, prompt versioning |
| Business process owner | Which actions require human approval and why |
| Risk and compliance | Risk tier assignment, audit trail requirements, escalation path |
| Legal | Exposure from external communications and data handling |
The decision that most often has no owner is the third one: which actions the system may take without a person. That is a business decision expressed as an architectural constraint, and it needs a named owner rather than a default.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform, not a security tool. Its relevance to this topic is upstream of the controls.
The hardest question in setting an injection containment boundary is not technical. It is knowing which actions in a workflow are material, which are reversible, which counterparties and case types carry elevated risk, and where the current process already requires a human decision. That information sits with the people who run the process, and it is rarely documented in a form the platform team can use.
Horizon runs AI-led discovery conversations across an organization and structures the result into a map of how work actually happens: who owns each decision, which approvals exist formally and informally, where the process varies by region or segment, and which exceptions carry the most risk. That is the input the boundary-setting exercise needs.
In the published Mercado Libre case, Horizon ran discovery across 2,000 employees in Finance and adjacent functions in five countries in four days, against a manual baseline of 11 to 20 weeks. Horizon is SOC 2 compliant and does not train models on customer data.
The connection is the same one that runs through enterprise AI generally. A containment boundary set from documentation reflects the process as intended. A boundary set from evidence reflects the exceptions the system will actually encounter.
Prompt injection readiness checklist
- Have you inventoried every untrusted input source the model processes?
- Do you know what a successfully injected model could do with each tool it can call?
- Is tool access scoped to the minimum the use case requires?
- Are the reading context and the acting context architecturally separated?
- Is there a defined list of actions that require human approval?
- Is output validated against an expected schema?
- Does adversarial testing run as a regression suite on every change?
- Do you monitor for unexpected tool calls and output-distribution shifts?
- Is there a named owner for the boundary between permitted and escalated actions?
- Is there an incident path for a suspected injection, with a defined first responder?
- Have you tested multimodal inputs, not only text?
- Does the risk tier of each use case determine the depth of these controls?
Common mistakes
Solving it in the prompt. Prompt-level defenses reduce naive success rates and provide no guarantee. Treating them as the control is the most common error.
Treating it as a chatbot problem. The higher-risk surface is any system that retrieves and processes content the organization did not author, which includes most RAG deployments and document processors.
Granting tool access because the integration supports it. Capability is not a reason to authorize. Each tool should be justified by the use case.
Using model confidence as a control. A successfully injected model is confident. Confidence signals detect uncertainty, not manipulation.
Testing only text. The 2025 OWASP list explicitly raises multimodal injection, where instructions are embedded in images or other non-text inputs.
Leaving the approval boundary undefined. If nobody decided which actions require a person, the architecture decided for you.
FAQ
What is prompt injection?
Prompt injection is a vulnerability in which text inside the data an LLM processes is interpreted by the model as an instruction. It occurs because models receive instructions and data through the same channel and cannot reliably distinguish between them. It is ranked LLM01 in the OWASP Top 10 for LLM Applications 2025, the top position for a second consecutive edition.
What is the difference between direct and indirect prompt injection?
Direct injection comes from the user's own input, such as a message instructing the model to disregard its configuration. Indirect injection comes from content the system retrieves and processes, such as a document, web page, or email containing embedded instructions. Indirect injection is the greater enterprise concern because enterprise systems are built to process content the organization did not author.
Can prompt injection be prevented completely?
No. OWASP's own guidance notes that given how models work, it is unclear whether fool-proof prevention methods exist. The practical approach is containment: limit what the model can read, limit what it can do, validate output, and require human approval for material or irreversible actions.
Is prompt injection the same as jailbreaking?
They overlap but are not identical. Jailbreaking generally refers to getting a model to bypass its safety guidelines. Prompt injection is the broader mechanism by which input is interpreted as instruction, which can be used for jailbreaking, data exfiltration, unauthorized tool invocation, or manipulation of downstream decisions.
How does prompt injection risk change with AI agents?
It scales with agency. A model that only produces text has a limited blast radius. A model that can call tools, query systems, send communications, or modify records can turn a successful injection into an action with real consequences. Agent deployments should scope tool access tightly and require human approval for anything material or irreversible.
Who should own prompt injection risk in an enterprise?
Security owns the threat model, testing, and monitoring. Platform engineering owns privilege scoping and context separation. The business process owner should own the decision about which actions require human approval, since that is a business risk judgment rather than a technical one. Risk and compliance assign the tier that determines how deep the controls go.
Design for the gap, because it is always there
Prompt injection is not a bug awaiting a fix. It is a property of how language models process input, and it will remain one for the foreseeable future.
The organizations that handle it well are not the ones with the cleverest system prompts. They are the ones that decided explicitly what the model may read, what it may do, and where a person has to make the call, and wrote that boundary down with a name next to it.
See it. Fix it. Stay ahead.