How Prompt-Injection Attacks Work

Instruction and data collapse into one context

Traditional software tries to keep code and data separate. SQL injection is dangerous because user-controlled text escapes the data lane and changes the query. Prompt injection has a similar shape, but the medium is natural language. The model receives developer instructions, user instructions, prior conversation, retrieved documents, tool outputs, and formatting hints as tokens in one context. The application may label some tokens as trusted, but the model still reasons over all of them as language.

That does not mean every model response is compromised. It means the application cannot assume that a natural-language instruction in a system prompt will reliably dominate every conflicting instruction that appears later in untrusted content. Security has to live in the application architecture, not only in the words sent to the model.

Privileges turn weird output into security impact

A language model that only drafts text can still mislead users, but the highest-risk systems are agents and copilots connected to tools. Tool access changes the question from "will the model say the wrong thing?" to "can the model act on the wrong instruction?" Common amplifiers include inbox access, search and browsing, code execution, database queries, calendars, payment flows, CRM updates, issue trackers, file systems, and internal APIs.

Retrieval-augmented generation adds a second amplifier. The application may pull in documents the user is authorized to read, documents the user is not authorized to read, or documents an attacker can write. If the retrieval layer ignores per-user permissions, prompt injection and data leakage can combine.

The usual failure chain

A defensive threat model can avoid payload details and still be precise. Most serious prompt-injection failures follow the same chain:

1. Untrusted text enters the context. It might come from a page, email, PDF, code comment, RAG chunk, chat message, or search result.
2. The app does not preserve a hard boundary. The text is concatenated into the model prompt, summarized by the same privileged model, or rendered into a tool decision.
3. The model output crosses a trust boundary. It becomes a tool call, a policy decision, a database query, code, a rendered link, a user-facing answer, or a memory update.
4. The application accepts the output too readily. There is no deterministic validation, no allow-list, no separate authorization check, no user confirmation, or no audit trail.

The defender's job is to break the chain in multiple places. A good system can still have a model that reads malicious text, but the text should not gain authority over tools, secrets, or irreversible actions.

What this page intentionally does not include

This is not a payload cookbook. You do not need novel attack strings to build a strong model of the risk. The useful defensive concepts are trust boundaries, untrusted content, tool authority, retrieval permissions, output validation, and auditability. When teams understand those concepts, they can test their own systems responsibly without copying live exploit prompts against third parties.