What Is Prompt Injection? Definition, Examples and Defenses (2026)

Prompt injection is an attack where text the model reads as data, such as a web page, an email, a PDF, or a code comment, contains instructions that the model follows as if they came from you. It works because a language model has no hard boundary between instructions and content: your system prompt, the user's message, and a fetched web page all arrive as tokens in one context window, and a sufficiently convincing sentence in any of them can redirect the task.

The term was coined by Simon Willison in September 2022, days after Riley Goodside showed that a GPT-3 translation app could be told to "ignore the above directions" and say something else entirely. Willison named it after SQL injection on purpose: in both cases, untrusted input is concatenated into something that gets executed. The difference is that SQL has a fix (parameterised queries) and language models do not yet have an equivalent.

Direct and indirect prompt injection

• Direct injection is the user typing the attack into the chat box. It matters when the application has secrets or capabilities the user should not reach, for example a support bot whose system prompt contains internal policy, or a tool the user is not meant to trigger.
• Indirect injection is the attacker planting instructions in content the model will read later, without ever talking to it. A 2023 paper by Greshake and colleagues showed it against LLM-integrated apps, and it is the form that matters now, because agents read untrusted content all day: web pages, repository files, issue comments, inbound email, tool results.

The damage scales with what the model can do after reading. A chatbot that gets injected says something wrong. An agent with a shell, a browser, or an API token can delete files, send data out, or make changes that look like normal work.

Real examples from coding agents

Our news desk has covered a steady run of these in 2026, and the pattern repeats:

• A researcher showed that asking Claude Code to summarize a web page was enough to redirect it, using nothing more than hidden text on the page.
• GitSpawn demonstrated that coding agents will execute code from a repository they were only asked to clone and inspect.
• GitHub's AI agent leaked private repository contents when asked conversationally, an authorization failure that injection makes exploitable at scale.
• Work on secrets extraction from black-box LLMs showed that anything placed in a system prompt or context window should be treated as readable by a determined user.

None of these needed a novel exploit. They needed an agent that read untrusted content while holding real permissions.

Why filters and detectors miss it

The intuitive fix is to scan inputs for injection phrases. It does not hold up. An evaluation of open-source prompt injection detectors found they miss a meaningful share of realistic agent attacks, because a malicious instruction can be phrased as ordinary prose, split across documents, encoded, or written in another language. A detector trained on yesterday's payloads is a speed bump.

A more useful framing comes from research that treats prompt injection as a role problem, not a text problem: the model fails because it cannot verify who is entitled to give which instruction. Until models have that notion built in, the fix has to live outside the model.

The defenses that hold

Simon Willison's "lethal trifecta" is the most practical test. An agent is exposed when it combines three things: access to private data, exposure to untrusted content, and a way to send data out (a web request, an email, a commit, even a rendered image URL). Remove any one leg and most injection attacks lose their payoff. In practice:

1. Least privilege per task. Scope tokens, directories, and tools to the job. A summarizer does not need write access; a code reviewer does not need network egress.
2. Separate reading from acting. Have a restricted model read untrusted content and return structured fields, and let only those fields reach the agent that holds permissions. This is the idea behind Willison's dual-LLM pattern and Google DeepMind's CaMeL design.
3. Mark untrusted content as data. Wrap fetched text in clearly labelled tags and tell the model that nothing inside them is an instruction. It is not a guarantee, but it raises the bar, and model providers now train for instruction hierarchy (system above user above tool output).
4. Require confirmation for irreversible actions. Deleting, sending, paying, publishing, and pushing should need a human or a separate policy check, especially right after the agent read external content.
5. Log and diff what the agent did after it read something. An unexpected tool call right after a fetch is the clearest injection signal you will get. Defenders are even planting honeypot injections in bait documents so a rogue agent reveals itself.

A prompt for auditing your own pipeline

You are a security reviewer for an LLM application.
<architecture>[describe each model call: what it reads, what tools and credentials it holds, what it can send out]</architecture>
For every model call, answer: 1) Which inputs could an outsider influence? 2) What is the worst action the call could take if those inputs contained instructions? 3) Does the call combine private data, untrusted content, and an outbound channel? Then rank the calls by risk and propose the smallest change that removes one leg of that combination for each of the top three.

It will not find every hole, but it forces the question most teams skip: what can this model do right after it reads something we did not write?

Prompt injection also has a long tail into memory. If an agent writes what it read into a persistent store, an injection can outlive the session that delivered it, which is why agent memory needs the same trust rules as the context window, whichever of the fragmenting memory architectures you pick.