What Is Prompt Injection?

TL;DR: Prompt injection is an attempt to make a model treat lower-authority content as instructions that override the task or governing rules. A useful review follows that influence to a specific decision: what the model proposes, what the application permits, and what actually reaches a person or system.

What you should be able to do

Identify the author of a proposed instruction, the authority they actually hold and the consequence they are trying to change. Trace one attempted redirection from source content to an answer, a read or an external action. Then specify the check that limits that consequence and the evidence needed to test it. Begin with trust boundaries if an input's origin and its authority still seem interchangeable.

An instruction needs authority, not just imperative wording

In a fictional support product, operator Leena asks an assistant to summarize customer Aster's issue. The task allows relevant Aster records to be read and a draft to be shown to Leena. A retrieved Aster ticket contains a third party's attempt to redirect the assistant toward another customer's internal notes and an unrelated recipient.

The ticket is evidence for the summary. Its author cannot grant access to other records, change the delivery audience or revise Leena's task. The security failure begins when that source content acquires authority it was never given. It does not require the application to alter its stored system prompt.

Compare three inputs:

Imperative sentences also occur in manuals, transcripts and legitimate requests. A keyword or grammatical form cannot establish which actor may command the application. Nor is every wrong answer evidence of injection: retrieval mistakes and unsupported generation can produce errors without an adversary. Report a suspected source influence as a hypothesis until the trace or controlled comparison supports it.

What roles and structured messages establish

An application can control which API message has a system, developer, user or tool role. It should preserve that separation and prevent source text from being promoted into trusted configuration. Those are meaningful implementation controls.

The model must still interpret the content it receives. Its learned instruction-following behavior may assign authority incorrectly, even when the API roles are correct. Instruction-hierarchy research by Wallace and colleagues (2024) trains models to prioritize instructions and ignore conflicting material from less privileged sources. Its evaluated improvements support using that behavior; they do not establish that your application's resources are authorized by a model response.

Avoid a universal claim that every present or future architecture simply concatenates everything or that architectural defenses are impossible. The practical distinction is narrower: a model's decision to follow a role label is not the same operation as a resource service checking an authenticated caller, task grant and requested object. A well-formed tool call can still request something forbidden.

Why the SQL comparison helps, and where it stops

Both comparisons concern input gaining unintended control over interpretation. With a correctly parameterized SQL statement, the database receives values through a binding mechanism that keeps them from changing the statement's syntax. This protection has a defined scope: unsafe query fragments constructed elsewhere remain unsafe, and a syntactically valid query can still read a record the caller is forbidden to see. OWASP's SQL guidance, checked November 2026, separates bound values, application-owned structural choices and least privilege.

Putting source material inside delimiters can help a model identify its role. It does not give the same guarantee as a database parameter binding. Conversely, an application's typed API, object permissions and effect executor can enforce particular restrictions around a model. Explain the property each mechanism provides instead of declaring either the entire SQL problem solved or the entire prompt-injection problem beyond design.

Read, propose, permit and observe are different events

Return to Leena's assistant. Suppose an isolated test produces these synthetic observations:

A classifier flag describes a detector's decision. A rejected tool call describes an enforcement decision. A delivery receipt describes an observed effect. Combining them into one success number obscures what failed and what worked.

For a replay, use synthetic records and an authorized isolated test environment with effect sinks. Record the model and application configuration, permitted source changes, current task, expected allowed behavior and observation gaps. Test legitimate instructions as well: a defense that prevents every summary by refusing all tickets has failed the product's purpose.

Place controls where the consequences occur

Before reading: authenticate the actor and service, resolve the current task scope and check the particular resources. A user may have broad access while the active task is narrower. Shared or delegated access can also be legitimate; do not replace a policy with a blanket rule that every record must be owned by the signed-in user.

Before an effect: validate the action and its material terms against trusted policy inputs. A standing grant can authorize bounded automatic work. When new approval is needed, show the actual resource, recipient and content through a trusted interface and bind approval to the version executed. See approval design for the mechanics.

Before disclosure: check who may receive the particular data, including generated replies, stored drafts, exports, previews and logs. An operator's permission to read a record does not make every customer an authorized recipient. A familiar domain or contact is also insufficient by itself. Safe rendering prevents particular active-content behaviors; it does not establish the truth or permitted audience of an ordinary sentence.

Around model behavior: retain source identity, label data clearly, use suitable instruction training and evaluate detectors. These measures can improve decisions. Their effectiveness depends on the configuration and cases tested. They do not replace an independently enforced permission rule.

A correct code check can still enforce the wrong policy or rely on an attacker-controlled tenant label. A control claim should name its trusted inputs, coverage and failure behavior. The lethal trifecta helps find sensitive input-to-output paths; use that map to remove unnecessary capabilities or constrain the paths the task genuinely requires.

A text-only result can matter

Tools create additional ways to change systems, but plain text can disclose a secret, distort an important decision or carry unsafe guidance. Rank the consequence using the audience, sensitivity and downstream use. Do not dismiss a source-driven ranking error because there is no write API, or call every odd output a demonstrated breach.

The OWASP 2025 prompt-injection entry, checked November 2026, covers direct and indirect inputs and several kinds of impact. The route is a useful part of the threat model. It is not a severity score.

Work through the changed constraints

Explain the design decision

A concise explanation should identify the source with insufficient authority, the attempted change and the check that governs the consequence. For Leena's assistant: a ticket can supply facts for the summary, but it cannot expand the task's read scope or delivery audience. The resource and delivery services must enforce those limits even when a model proposes a validly formatted request.

Continue with indirect prompt injection to map source and transformation paths, and injection versus jailbreak to separate overlapping policy failures without assigning severity by label.