Free tool
Prompt injection pattern library
Prompt injection patterns by vector and defence, plus a checker for which apply to your system. Open data, nothing leaves your browser.
Prompt injection is the most consequential unsolved problem in applied AI security, and the reference material for it is scattered across a PDF, a bot-blocked knowledge base, and one vendor's product documentation. This library collects the patterns in one searchable place, gives each a stable identifier you can cite in a ticket or a control mapping, and puts the defence beside the attack every time.
Nothing leaves your browser: Everything here runs in your browser. There is nothing to submit and no account to create, and the page is served with a Content Security Policy whose connect-src 'none' rule blocks fetch, XHR, WebSocket, EventSource and sendBeacon. Open your developer tools, watch the network tab, and confirm it. A policy inside the page cannot stop you copying the result somewhere else, so what you do with it afterwards is yours to protect. Refreshing the page loses your work, unless you pressed Copy link to this result: that puts your ticks after the # in the address, which a browser never sends to a server.
Tick what your system reads and does. The checker shows which of the patterns apply and which defences are worth starting with. It lists exposure; it does not test a live model, and nothing you tick leaves this page.
0 ticked
Nothing ticked yet
Start with what the system reads, because that decides who can reach it. A system that retrieves documents or reads mail is exposed to people who never touch it.
Showing 21 of 21 patterns
- PIP-001medium severity
Instruction override
Text that directly instructs the model to disregard everything it was told before it.
Direct overrideTyped by the userRetrieved documentHow it works
The attacker supplies text asserting that the preceding instructions are void, superseded, or were a test, then states the instructions to follow instead. No technical exploit is involved: the model is asked to prefer one set of instructions over another, and it obliges.
Why it works
Instructions and input arrive in one undifferentiated context. Nothing marks which text came from the developer and which arrived from outside, so precedence is decided by what reads as most authoritative rather than by where it came from.
Defences
Separate instructions from data structurallyRaises cost
Keep instructions and data apart
Place untrusted content in a dedicated field the model is trained to treat as data rather than concatenating it into the instruction text. This does not make the boundary absolute, but it is the difference between a boundary that exists and one that does not.
Constrain what the response can causeArchitectural
Limit what it can do
Scope the actions available on the strength of a model output. If the worst case of a successful override is a wrong answer rather than an action, the attack has somewhere to land but nothing to do.
Filter for override phrasingDo not rely on
Clean what goes in
Pattern matching on familiar phrasings catches unsophisticated attempts and generates useful telemetry. It is trivially defeated by rephrasing, so treat it as a volume reducer and a signal, never as a control.
LLM01:2025AML.T0051.000 - PIP-002medium severity
Persona reassignment
A new identity is assigned to the model, with different stated rules, and requests are then made of that identity.
Role manipulationTyped by the userHow it works
Rather than contradicting the instructions, the attacker establishes an alternative character with its own described constraints, then addresses that character. The model continues the fiction because continuing text consistently is precisely what it does.
Why it works
A model has no stable self to defend. Its behaviour is a product of context, so a sufficiently well-established alternative context competes with the configured one on equal footing.
Defences
Reassert the operating instructions late in the contextRaises cost
Harden the prompt and its context
Instructions placed after untrusted content are harder to displace than instructions placed before it. This helps and does not settle the matter, since the attacker controls length and can push the boundary.
Check the output rather than the inputRaises cost
Treat what it produces as untrusted
Whether the model has adopted an alternative persona is usually far more detectable in what it produces than in what it was sent. Screening responses catches successful attempts that input filtering missed.
Keep authority out of the conversationArchitectural
Limit what it can do
If no privilege is attached to what the model says in a chat turn, a compromised persona has no power to exercise. This is the only defence in this list that holds regardless of how convincing the fiction is.
LLM01:2025AML.T0054 - PIP-003medium severity
Fictional framing
The prohibited request is wrapped in a story, screenplay, or hypothetical so that answering feels like composition rather than compliance.
Role manipulationTyped by the userHow it works
The attacker asks for a narrative in which a character explains or performs the restricted thing. The request is genuinely a writing task, and the restricted content is genuinely part of it, which is what makes the framing effective.
Why it works
Refusal behaviour is trained against the appearance of a request. Change the appearance sufficiently and the trained response does not fire, even though the information produced is identical.
Defences
Evaluate the output, not the framingRaises cost
Treat what it produces as untrusted
Judge what the response contains rather than how it was requested. Fictional framing changes the wrapper and not the payload, so output-side evaluation is the natural place to catch it.
Constrain the task domainArchitectural
Harden the prompt and its context
An assistant scoped to a genuine business function has no reason to accept open-ended creative writing. Narrow systems are attacked through this pattern far less successfully than general ones.
LLM01:2025AML.T0054 - PIP-004high severityNo app access needed
Authority impersonation
Injected text imitates the formatting and tone of a system or developer message so it inherits the authority of one.
Role manipulationTyped by the userRetrieved documentTool resultHow it works
The attacker mimics whatever markers a system message carries in that application: a label, a delimiter, an all-capitals notice, an internal-sounding identifier. The model has no way to verify the provenance of a marker it only ever sees as text.
Why it works
Authority in a prompt is conveyed by convention, and conventions are copyable. Everything the model uses to recognise a privileged instruction is available to whoever can write into its context.
Defences
Use markers the attacker cannot reproduceRaises cost
Keep instructions and data apart
Delimit trusted instructions with unpredictable, per-request identifiers rather than fixed conventional markers, and strip any occurrence of them from untrusted content before assembly.
Never grant standing on formattingArchitectural
Limit what it can do
Do not let a system make decisions on the basis of text claiming to be authoritative. Authority should come from the channel content arrived on, which the application knows and the model does not.
LLM01:2025AML.T0051 - PIP-005high severityNo app access needed
Indirect injection through a retrieved document
Instructions are placed in a document the system will retrieve, so they enter the prompt without the user or the attacker touching the application.
Indirect injectionRetrieved documentHow it works
Retrieval selects passages by similarity, not by trustworthiness, and pastes what it finds into the prompt alongside the real instructions. Anyone able to write into a source the system indexes can therefore write into its context. The attacker never needs access to the application and the user never sees the payload.
Why it works
Retrieval and instruction assembly are separate concerns that meet in a single flat string. At the moment of assembly, a retrieved passage and a developer instruction are indistinguishable.
Defences
Treat retrieved content as hostile inputArchitectural
Keep instructions and data apart
Assume every retrieved passage may carry instructions. Keep it in a clearly demarcated region, and never let its content select an action.
Control who can write to the corpusArchitectural
Control sources, integrations and assumptions
Most indexes quietly include sources the organisation does not control: supplier documents, ticket bodies, crawled pages, user uploads. Establishing which sources are writeable by outsiders is usually the finding.
Scan documents at ingestionDo not rely on
Clean what goes in
Screening at index time catches careless payloads and gives a place to alert. It cannot be relied on, since the payload is ordinary prose and can be rewritten indefinitely.
LLM01:2025LLM08:2025AML.T0051.001 - PIP-006high severityNo app access needed
Indirect injection through web content
A page the assistant browses carries instructions, which are read with the user's authenticated session available.
Indirect injectionWeb pageHow it works
Browsing agents read pages and act on them, so any page in reach becomes an instruction channel. The browser was designed to render untrusted content, not to execute it with the user's authority; an agent collapses that distinction.
Why it works
The agent operates inside the user's trust boundary, behind authentication, and the payload is ordinary page content that no malware filter is looking for.
Defences
Withhold authenticated sessions from browsing agentsArchitectural
Limit what it can do
Deny agents access to sessions for finance, email and administrative surfaces until a vendor can demonstrate genuine separation between page content and instruction context.
Per-task least-privilege credentialsArchitectural
Limit what it can do
Prefer deployments where the agent holds narrow, short-lived credentials for the task at hand rather than inheriting the user's full session.
Monitor agent navigationRaises cost
Watch, log and alert
An agent that navigates to an unfamiliar domain in the middle of a task is a signal worth alerting on, and it is one of the few detections that works after the fact.
LLM01:2025AML.T0051.001 - PIP-007medium severityNo app access needed
Invisible text
The payload is present in the content but not visible to a person reviewing it.
ObfuscationWeb pageRetrieved documentEmail or messageImageHow it works
Text is hidden using presentation rather than encoding: matching the background colour, zero or near-zero font size, positioning outside the viewport, markup comments, document metadata, or alternative text. A parser reads it; a reviewer does not.
Why it works
Human review operates on rendered output while the model consumes the source. Any gap between what is rendered and what is parsed is available to an attacker.
Defences
Normalise before the model sees itRaises cost
Clean what goes in
Extract and canonicalise text at ingestion so the model receives what a reader would see. Strip comments, metadata and non-rendering regions rather than passing raw markup through.
Review the extracted text, not the documentRaises cost
Put a person in the loop
Where a human approves content for indexing, show them the text the model will actually receive. Reviewing the rendered document approves something different from what is used.
LLM01:2025AML.T0051.001 - PIP-008medium severity
Encoding and character obfuscation
The instruction is encoded, transliterated, or built from lookalike characters so that filters miss it while the model still resolves it.
ObfuscationTyped by the userRetrieved documentWeb pageHow it works
The payload is expressed in a form a string matcher does not recognise but a model does: an encoding scheme, spacing or separator insertion, visually similar characters from other scripts, or a different language. Capable models decode such text readily.
Why it works
Filtering operates on surface form while comprehension operates on meaning. Any transformation that preserves meaning while changing surface form defeats the filter without defeating the model.
Defences
Normalise Unicode and reject unexpected scriptsRaises cost
Clean what goes in
Apply canonical normalisation and flag content mixing scripts without a reason to. This closes the lookalike-character route specifically and is cheap.
Stop depending on input matchingArchitectural
Control sources, integrations and assumptions
This pattern exists to demonstrate that surface-form filtering cannot be the control. Its real lesson is architectural: assume the filter is bypassed and ensure the outcome is still contained.
LLM01:2025AML.T0051 - PIP-009medium severity
Payload splitting
The instruction is fragmented across turns or documents so that no single piece is recognisable on its own.
ObfuscationTyped by the userRetrieved documentHow it works
Each fragment is innocuous in isolation; the model assembles them from context. Where a filter inspects one message or one passage at a time, it never sees the complete instruction.
Why it works
Models integrate context across an entire conversation or prompt, while most inspection operates on individual units. The mismatch is the vulnerability.
Defences
Inspect the assembled contextRaises cost
Watch, log and alert
Evaluate the full context as constructed rather than each message as it arrives. This is the only inspection point where the complete instruction exists.
Constrain conversation-derived authorityArchitectural
Limit what it can do
Do not let accumulated conversation state expand what a system may do. If capability is fixed by configuration, assembling an instruction across turns achieves nothing.
LLM01:2025AML.T0051 - PIP-010high severityNo app access needed
Tool result injection
An agent calls a tool, and the text that comes back carries instructions the agent then follows.
Agentic and tool abuseTool resultHow it works
Tool output is appended to the agent's context as ordinary text, in the same format as its instructions. Anyone who can influence what a tool returns can therefore write into the agent's context, and the agent acts with its own credentials at machine speed.
Why it works
The observe step of an agent loop has no channel separation. A result and an instruction are the same kind of thing once appended.
Defences
Scope the agent's tools to the taskArchitectural
Limit what it can do
The question is not whether an agent can be misled, because it can. The question is what it holds when that happens. An agent with a bulk export and an unrestricted send is a breach waiting for the right record; the same agent scoped to its task is an inconvenience.
Confirm irreversible actions with a personArchitectural
Put a person in the loop
Sending, paying, deleting and publishing cannot be undone. Requiring human confirmation on exactly those steps contains the outcome without hobbling the agent.
Log every tool callRaises cost
Watch, log and alert
An agent is a service account. Record what it called and with which arguments, and alert on unfamiliar destinations.
LLM01:2025LLM06:2025AML.T0051.001 - PIP-011high severityNo app access needed
Connector and tool-description poisoning
The description of a tool, rather than its output, carries the instruction, so the attack lands before the tool is ever called.
Agentic and tool abuseConnector or MCP serverHow it works
An agent is told what tools it has using natural-language descriptions supplied by whoever provides them. Those descriptions sit in the context as instructions. A connector whose tool description contains directives can influence the agent's behaviour towards other tools entirely, without being invoked.
Why it works
Tool registration is trusted implicitly. The text describing a capability is treated as configuration, but it arrives from a third party and reaches the model as prose.
Defences
Review connector definitions before installationArchitectural
Control sources, integrations and assumptions
Read the tool descriptions a connector registers, not just its stated purpose. Treat installation with the same scrutiny as any privileged integration.
Inventory connectors as integrationsArchitectural
Control sources, integrations and assumptions
Connectors are privileged system-to-system integrations that teams install themselves. Bring them into the existing integration inventory and third-party review process.
Pin and monitor connector versionsRaises cost
Control sources, integrations and assumptions
A description that was benign at review can change at any update. Pin versions and re-review on change rather than trusting the initial assessment indefinitely.
LLM01:2025LLM06:2025 - PIP-012high severityNo app access needed
Memory poisoning
An instruction is written into an assistant's long-term memory, so it applies to every future session rather than one conversation.
Agentic and tool abuseStored memoryHow it works
Assistants that retain notes across sessions reload them into context automatically. Content that reaches the memory store becomes a standing instruction, surviving the conversation that planted it and applying to sessions the attacker is not present for.
Why it works
Memory is designed to be authoritative and persistent, and what qualifies for storage is usually decided by the model itself from conversation content.
Defences
Make memory writes explicit and visibleArchitectural
Put a person in the loop
Require deliberate confirmation for anything stored, and show users what is held. Memory that accumulates silently cannot be audited by the person it affects.
Never let memory expand capabilityArchitectural
Limit what it can do
Treat memory strictly as preference, never as authorisation. A stored note should not be able to change what a system is permitted to do.
Expire and re-confirm stored instructionsRaises cost
Control sources, integrations and assumptions
Age out stored directives so a single successful write does not persist indefinitely.
LLM01:2025 - PIP-013high severityNo app access needed
Multi-agent trust abuse
One agent's output becomes another agent's input, and the receiving agent trusts it because it came from inside the system.
Agentic and tool abuseTool resultConnector or MCP serverHow it works
In a pipeline of agents, output from an upstream agent is passed downstream as context. Downstream agents typically apply less scrutiny to internal messages than to user input, so a single compromised agent can direct the behaviour of every agent after it.
Why it works
Trust boundaries inside multi-agent systems are usually implicit and undocumented. Provenance is lost the moment content is handed on, and each hop tends to increase apparent trustworthiness.
Defences
Document the trust boundariesArchitectural
Control sources, integrations and assumptions
Establish which agent may instruct which, and where content originating outside the system enters the pipeline. Most such systems have never had this written down.
Carry provenance through the pipelineRaises cost
Keep instructions and data apart
Keep the origin of content attached to it, so a downstream agent can distinguish an upstream conclusion from text that entered from outside.
Grant privileges per agent, not per systemArchitectural
Limit what it can do
Give each agent only what its own step requires, so compromising the exposed agent does not confer the pipeline's full capability.
LLM01:2025LLM06:2025 - PIP-014high severityNo app access needed
Rendered-output exfiltration
The injected instruction makes the model emit a link or image reference that leaks data to an attacker when the interface renders it.
Output handlingRetrieved documentWeb pageTool resultHow it works
Interfaces commonly render model output as rich text. If the model can be induced to place data into a URL, the client requests that URL on render, transmitting the data without the user clicking anything. The model never sends the data; the interface does.
Why it works
The vulnerability lives in the renderer, not the model. Automatic rendering of model-authored references turns any successful injection into a data-exfiltration channel.
Defences
Do not auto-load model-authored referencesArchitectural
Treat what it produces as untrusted
Block automatic requests to arbitrary hosts from rendered output. Allow-list the origins that may be fetched on render. This closes the channel outright and is the single highest-value fix here.
Apply a content security policy to the rendering surfaceArchitectural
Treat what it produces as untrusted
Constrain where the interface may fetch from, so a reference to an unexpected host cannot be resolved even if it is produced.
Treat model output as untrusted inputArchitectural
Treat what it produces as untrusted
Encode and validate model output before it reaches any renderer, exactly as you would content from any other external source.
LLM01:2025LLM02:2025LLM05:2025 - PIP-015medium severity
System prompt extraction
The model is induced to reveal its own configuration, exposing instructions, tool definitions and sometimes credentials.
Direct overrideTyped by the userHow it works
The attacker asks for the preceding context directly, or by indirection: a translation, a summary, a repetition, a formatting task applied to everything above. The configuration is text in the same context, so it is available to be operated on.
Why it works
A system prompt is not a secret and cannot be made one. It sits in the context the model is asked to work with, and any operation over that context can surface it.
Defences
Put nothing secret in the promptArchitectural
Harden the prompt and its context
Treat the system prompt as public. No credentials, no internal endpoints, no information whose disclosure matters. This is the only reliable control and it is free.
Do not rely on instructions to keep instructions privateDo not rely on
Harden the prompt and its context
Telling a model not to reveal its instructions raises the cost of extraction and does not prevent it. Plan for the contents being known.
LLM01:2025LLM02:2025 - PIP-016high severityNo app access needed
Code and comment injection
Instructions placed in source files or comments influence AI coding assistants reading the repository.
Indirect injectionSource code or commentsHow it works
Coding assistants read files, comments, configuration and documentation as context. A comment addressed to the assistant rather than to a developer becomes an instruction, and can influence generated code across the project.
Why it works
Everything in the repository is context, and a comment is indistinguishable from guidance. Dependencies, vendored code and generated files are all in reach and rarely reviewed line by line.
Defences
Review generated code, not the promptArchitectural
Treat what it produces as untrusted
The output is the artefact that ships. Code review is the control that already exists for this class of problem, and it works here provided reviewers are actually reading the diff.
Constrain assistant context to reviewed sourcesRaises cost
Control sources, integrations and assumptions
Limit what an assistant is permitted to read, particularly across dependency trees and vendored code that no one on the team has read.
Keep secrets and deploy rights away from the assistantArchitectural
Limit what it can do
An assistant that can commit, publish or deploy converts a comment into an action. Separate authorship from release.
LLM01:2025AML.T0051.001 - PIP-017medium severity
Context eviction
The context is filled until earlier instructions are pushed out of the window, removing constraints without contradicting them.
Direct overrideTyped by the userRetrieved documentHow it works
Context windows are finite, and long conversations drop their oldest content. An attacker who can add enough material can cause earlier instructions to be evicted. Nothing is overridden; the constraint simply is no longer present.
Why it works
Eviction is a silent, mechanical process. Neither the model nor the user is notified that an instruction has left the context, so the change in behaviour has no visible cause.
Defences
Re-inject operating instructions every turnArchitectural
Harden the prompt and its context
Rebuild the instruction block on each request rather than relying on it persisting from the start of the conversation. Cheap, and it removes the pattern entirely.
Reserve budget for instructionsArchitectural
Harden the prompt and its context
Allocate context deliberately, evicting history before ever evicting configuration.
Alert on evictionRaises cost
Watch, log and alert
Make it visible when content is being dropped, so silent behaviour changes have a traceable cause.
LLM01:2025 - PIP-018high severityNo app access needed
Confused deputy escalation
The model is used as a proxy to exercise privileges the attacker does not hold, because the system acts on its own authority rather than the requester's.
Agentic and tool abuseTool resultRetrieved documentHow it works
An assistant typically runs with a service identity broader than any individual user. If it can be induced to perform an action, it performs it with that identity, so the attacker inherits reach they never had. This is the classic confused deputy problem, restated for systems that take instructions in natural language.
Why it works
Authorisation is checked when the system connects to a resource, not when it decides to. The decision is made from context an attacker can influence; the credential is applied afterwards regardless.
Defences
Act with the requester's authority, not the system'sArchitectural
Limit what it can do
Propagate the user's identity to downstream calls so the assistant cannot exceed what the person on whose behalf it acts could do directly. This eliminates the escalation rather than mitigating it.
Separate reading from actingArchitectural
Limit what it can do
Split components that consume untrusted content from components that hold privileges, so the part that can be influenced is not the part that can act.
Assess blast radius per systemRaises cost
Control sources, integrations and assumptions
For each assistant, establish what it holds and what the worst realistic outcome is if it is misled today. Most organisations cannot answer that, and the inability is itself the finding.
LLM01:2025LLM06:2025 - PIP-019medium severityNo app access needed
Instruction addressed to an automated analyser
Text planted in a file that speaks to the AI tool reviewing it, saying the file is harmless, protected or not worth analysing.
Indirect injectionSource code or commentsRetrieved documentHow it works
The author of an artefact, such as a script, a binary, a document or a package, embeds natural-language sentences aimed at whatever model will read its extracted text. The sentences do nothing when the artefact runs. Their only job is to be read. They ask the reviewing model to stop analysing, to report the file as benign, to refuse, or to take up a different task. The same sentence can be copied unchanged across unrelated artefacts, generated afresh for each build so that no fixed phrase matches, or repeated in several chat-template wrappers in the hope that one matches the wrapper the scanner uses.
Why it works
An analysis pipeline extracts text from the artefact and places it in one prompt beside the analyst's question. The model receives the question and the artefact's own words in the same format, with nothing marking which is which, so a sentence that reads like an instruction can compete with the real one. It is also the one place where the attacker knows the reader is a model.
Defences
Let the model advise and a rule decideArchitectural
Limit what it can do
A model's verdict may add suspicion or raise priority. It must never close, downgrade or approve an alert or a file on its own: a deterministic detection or a person has the last word, and a refusal or an empty output means a person looks. This removes the payoff for the attacker instead of trying to win an argument with the model.
Treat extracted text as evidence, not instructionRaises cost
Keep instructions and data apart
Keep the task apart from the extracted text, label the text as untrusted and say so in the prompt. It makes injection harder, and a well-built pipeline need not be unusually exposed, but a model cannot enforce the boundary on its own. It lowers the likelihood and is not a control to depend on.
Hunt for text addressed to a reviewerRaises cost
Watch, log and alert
Sentences that address an AI, an assistant or a language model, chat-template markers, and claims of copyright or harmlessness inside a binary or script are detection signals. A hit is evidence of intent. A miss proves nothing, because the wording can be generated for each build.
Log the model's input and output for every verdictRaises cost
Watch, log and alert
Record the full input and output, the tool calls and who accepted or overrode the verdict, somewhere the analysed text cannot alter, so that a shifted verdict can be found and explained afterwards.
Test your own pipeline with a harmless fileRaises cost
Control sources, integrations and assumptions
In a copy, not in production, submit a harmless file that conventional detection is certain to flag, with and without a plain sentence addressed to the reviewer saying it needs no analysis. Record the model, the prompt, the runs and whether the verdict moves, and repeat whenever either changes. Use no real malware and copy no wording from reports.
LLM01:2025AML.T0051.001 - PIP-020medium severityNo app access needed
Summary and priority manipulation
Hidden text in a message that steers the recipient's AI assistant to present it as legitimate or urgent, so the person is persuaded by the summary.
Indirect injectionEmail or messageRetrieved documentHow it works
The message carries two layers. One is what the person sees. The other is text they cannot see, placed in markup comments, styled to be invisible, encoded, or built from invisible characters, and aimed at the assistant that will summarise, rank or act on the message. The hidden text asks the assistant to describe the message as routine or urgent, to add a priority action, or to propose a change such as new payment details. The target is the summary the person trusts, as well as any action the assistant might take.
Why it works
People read the assistant's summary instead of the message, so the summary inherits the message's authority without its context. The assistant reads the raw content, including the parts a mail client hides, and cannot tell the text the sender showed from the text the sender hid for it.
Defences
Never let a summary be the only basis for money or accessArchitectural
Put a person in the loop
Payment changes, new suppliers and credential requests need a person to check the original message and confirm by a second channel the sender did not supply. A machine summary can prompt the check and must not replace it.
Give the assistant no actions it can take from external messagesArchitectural
Limit what it can do
Treat mail from outside the organisation as read-only for the assistant: no sending, forwarding, accepting invitations or editing records on the strength of what a model made of an external message.
Show the original beside the summaryRaises cost
Treat what it produces as untrusted
Display the sender and the original text next to any machine summary, and label the summary as machine generated, so that a person can see what it claims and what it was made from.
Strip hidden content before the model reads itRaises cost
Clean what goes in
Remove markup comments, invisible styling, encoded blocks and invisible characters, and give the model what a reader would see. This closes the crude forms and not a message that is persuasive in plain sight.
Alert on repeated attemptsRaises cost
Watch, log and alert
Log and count messages whose hidden text addresses an assistant, and tell the mail security team. One such message is a signal about the sender and the next ones are a campaign.
LLM01:2025AML.T0051.001 - PIP-021high severityNo app access needed
Self-propagating injection
An injected instruction that tells the model to copy the instruction into what it writes, so each assistant that reads the copy is injected in turn.
Agentic and tool abuseEmail or messageRetrieved documentStored memoryTool resultHow it works
The injected text asks the model to include the instruction itself, or a reworded form of it, in the documents, messages, tickets or stored notes that it produces. Whoever or whatever reads that output next, a person or another assistant, meets the instruction. The spread needs a shared surface where model output is written and later read by another model that is able to write again.
Why it works
Model-authored content is stored and later retrieved like any other content, and the reader cannot tell that a model wrote it or that it carries an instruction. Each step looks like normal use, and there is no single point at which something unusual is sent.
Defences
Keep model-authored content out of the instruction channelRaises cost
Keep instructions and data apart
Mark what a model wrote and keep it out of the instructions when another model reads it, carrying provenance so that a downstream assistant can tell an upstream model's output from a person's. The boundary is not absolute, and it breaks the loop at its usual joint.
Approve outbound writes that leave the boundaryArchitectural
Put a person in the loop
Require a person to approve messages, shares and publications an assistant composes from external content, so that a copy cannot leave on its own.
Give each assistant write access to as little as possibleArchitectural
Limit what it can do
Limit where an assistant can write and to whom it can send, so that a successful injection has few places to leave a copy.
Monitor and rate-limit what assistants writeRaises cost
Watch, log and alert
Count and sample the content assistants produce, and alert on identical or near-identical text appearing across many outputs, which is how a copy loop shows itself.
Know how to stop one and clean upRaises cost
Control sources, integrations and assumptions
Know which assistants can write where, and be able to disable one and purge what it wrote, so that a spread can be contained and the copies removed.
LLM01:2025AML.T0051.001Where it has been reported
Every pattern, by class
Each pattern has a stable identifier and its own page, so you can cite an individual technique in a finding, a ticket, or a control mapping. Identifiers are never reissued.
Direct override
- PIP-001Instruction overrideText that directly instructs the model to disregard everything it was told before it.
- PIP-015System prompt extractionThe model is induced to reveal its own configuration, exposing instructions, tool definitions and sometimes credentials.
- PIP-017Context evictionThe context is filled until earlier instructions are pushed out of the window, removing constraints without contradicting them.
Role manipulation
- PIP-002Persona reassignmentA new identity is assigned to the model, with different stated rules, and requests are then made of that identity.
- PIP-003Fictional framingThe prohibited request is wrapped in a story, screenplay, or hypothetical so that answering feels like composition rather than compliance.
- PIP-004Authority impersonationInjected text imitates the formatting and tone of a system or developer message so it inherits the authority of one.
Obfuscation
- PIP-007Invisible textThe payload is present in the content but not visible to a person reviewing it.
- PIP-008Encoding and character obfuscationThe instruction is encoded, transliterated, or built from lookalike characters so that filters miss it while the model still resolves it.
- PIP-009Payload splittingThe instruction is fragmented across turns or documents so that no single piece is recognisable on its own.
Indirect injection
- PIP-005Indirect injection through a retrieved documentInstructions are placed in a document the system will retrieve, so they enter the prompt without the user or the attacker touching the application.
- PIP-006Indirect injection through web contentA page the assistant browses carries instructions, which are read with the user's authenticated session available.
- PIP-016Code and comment injectionInstructions placed in source files or comments influence AI coding assistants reading the repository.
- PIP-019Instruction addressed to an automated analyserText planted in a file that speaks to the AI tool reviewing it, saying the file is harmless, protected or not worth analysing.
- PIP-020Summary and priority manipulationHidden text in a message that steers the recipient's AI assistant to present it as legitimate or urgent, so the person is persuaded by the summary.
Agentic and tool abuse
- PIP-010Tool result injectionAn agent calls a tool, and the text that comes back carries instructions the agent then follows.
- PIP-011Connector and tool-description poisoningThe description of a tool, rather than its output, carries the instruction, so the attack lands before the tool is ever called.
- PIP-012Memory poisoningAn instruction is written into an assistant's long-term memory, so it applies to every future session rather than one conversation.
- PIP-013Multi-agent trust abuseOne agent's output becomes another agent's input, and the receiving agent trusts it because it came from inside the system.
- PIP-018Confused deputy escalationThe model is used as a proxy to exercise privileges the attacker does not hold, because the system acts on its own authority rather than the requester's.
- PIP-021Self-propagating injectionAn injected instruction that tells the model to copy the instruction into what it writes, so each assistant that reads the copy is injected in turn.
Use the data
The whole corpus is published as JSON under CC BY 4.0, currently version 1.1.0, reviewed 2026-10-08. Every defence carries the lever it works on, and the changelog is in the file. Map it into your own control framework, cite individual patterns by identifier, or build something better on top of it. Corrections and additions are welcome.
What has changed
A corpus that changes without saying so cannot be cited, so each release is dated. Identifiers are never renumbered: a pattern added later takes the next number.
Version 1.1.0
- Added PIP-019, instruction addressed to an automated analyser, after Cisco Talos published a count of malware carrying text for AI triage and a test of how far it steers verdicts.
- Added PIP-020, summary and priority manipulation, after Barracuda reported a phishing email whose hidden text was aimed at the recipient's AI assistant.
- Added PIP-021, self-propagating injection, the pattern behind worm-style prompt injection reports.
- Every defence now carries a lever (what it works on), published in the data and usable as a filter.
- Added the exposure checker: tick what your system reads and does, and see which patterns apply and which defences to start with.
- Added source links to the patterns where a published report can be checked.
Version 1.0.0
- First release: 18 patterns in six classes, each with defences rated architectural, raises cost or do not rely on, and framework mappings only where the identifier is known correct.
Scope, and what is deliberately absent
This library describes mechanisms. It contains no working payloads, and it never will: the purpose is to help you recognise a class of attack and choose a control, which does not require a copy of the attack. Every pattern is published beside its defences, and each defence states its own strength honestly, because several widely recommended mitigations are partial and pretending otherwise is how organisations end up believing they are covered.
Framework mappings are asserted only where the identifier is known to be correct, and omitted where it is uncertain. A fabricated control reference is worse than a missing one.
Common questions
›What is prompt injection?
An attack where text supplied to a language model is treated as instructions rather than data. Because a model receives its instructions and its input in the same context, in the same format, with nothing marking which is which, text that arrives from anywhere can compete for authority with the instructions the developer wrote.
›What is the difference between prompt injection and jailbreaking?
Jailbreaking targets the model's own safety training: the attacker is the user, and the goal is to make the model produce something it was trained to refuse. Prompt injection targets an application built on a model: the attacker is usually not the user, and the goal is to subvert what the developer told the system to do. A jailbreak harms the person typing it. An injection harms whoever is using the application.
›What is indirect prompt injection?
Injection through content the system retrieves rather than text the user typed: a document, a web page, a support ticket, an email, a calendar invite, a tool result. It is the more serious form, because the attacker never needs access to the application and the victim never sees the payload.
›Can prompt injection be filtered out?
Not reliably. The payload is ordinary language, so there is no signature to match, and it can be rephrased without limit. Filtering reduces volume and is worth doing, but it cannot be a control you depend on. The durable mitigations are architectural: separate retrieved content from instructions, scope what the system may do with an answer, and reduce the privileges available when it is misled.
›Does a more capable model solve this?
It helps at the margin and changes nothing structural. Better models refuse more obvious attempts, which mostly raises the quality of the attempts. The exposure is set by what the system is permitted to do when it is fooled, and that is a deployment decision rather than a model one.
›How do I know which patterns apply to my system?
Use the checker at the top of the page. Tick what the system reads (documents, web pages, email, code, files from outside) and what it does (calls tools, remembers, passes work between agents, acts without approval). Each ticked item opens the vectors and the patterns that travel by them, and the result lists the patterns that apply and the defences to start with. It lists exposure from your answers. It does not test a live model, and it cannot see your prompts, permissions or monitoring.
›Can I use this data in my own work?
Yes. The full corpus is published as open JSON with a stable identifier per pattern and the lever each defence works on, so you can map it into your own control framework, cite individual patterns in findings, or build on it. Attribution is appreciated and not required.
When you need more than a tool
AI security assessment
Threat modelling, architecture review and adversarial testing of AI systems, mapped to the OWASP LLM Top 10, MITRE ATLAS and NIST AI RMF.
Read more