Prompt Injection in the Wild

A tracker of publicly reported prompt-injection techniques from roughly the last two years, maintained by Rachel James (cybershujin).

Each technique is broken down into the three elements of a prompt injection:

1. Delivery method — how the injected instructions reach the model (a tool-call result, an external website, an MCP connection, a document, an email, an image, etc.).
2. Encoding — the obfuscation applied to the payload, if any (Base64, leetspeak, invisible Unicode tag characters, homoglyphs, …). Blank when the payload is plain text or the report doesn't say.
3. Propagation behavior — whether the injection is designed to spread or persist (delivered to anyone who connects to a poisoned MCP server, persisted in an agent's long-term/project memory, carried along a chain of tool calls, made to emit an email carrying further instructions, …). Blank when there is no propagation.

Each entry also records the models it was confirmed to work against (if any), a link to the reporting source, and — where known — the attack source (the researcher, red team, or in-the-wild actor it originated from).

Live dashboard: https://cybershujin.github.io/Prompt-Injection-in-the-Wild/

---

Scope & methodology

• In scope: techniques for injecting adversarial instructions into an LLM or LLM-powered agent that have been publicly reported — by security researchers, red teams, vendors, or as observed in-the-wild activity. Both direct and indirect (data-borne) prompt injection are included.
• Out of scope: generic jailbreak wordlists with no delivery/propagation mechanism, pure model-alignment complaints, and marketing with no technical substance.
• Never guessed. Every non-blank cell is taken from an explicit statement in the cited source. If a report does not state the encoding, the propagation behavior, the confirmed models, or the attack source, that cell is left blank — a blank means "not stated," never an inferred "none."
• Vetting. Each entry is marked Confirmed or Not fully vetted. "Not fully vetted" flags an entry whose source is vague, unconfirmed, or whose mechanism is unclear — it is surfaced rather than dropped, so a reviewer can judge it.
• Evidence class — in-the-wild vs. research. Each entry is tagged In-the-wild (observed real-world abuse or a real production incident), Research / red-team (a security-researcher or red-team demonstration / responsible disclosure — a real, working technique, but not observed being abused by an attacker), Vendor advisory, or Unclear. This is a separate axis from vetting: a technique can be Confirmed (verified and working) yet only ever demonstrated in a lab. Be aware: genuine in-the-wild malicious prompt injection is still rarely documented publicly, so the large majority of entries here are research / red-team disclosures — at the time of the initial backfill, 29 of 32 were research/red-team and only 3 were in-the-wild. Use the Evidence filter on the dashboard to isolate the real-world cases.
• Updates. New reporting is swept monthly (Perplexity sonar-deep-research, wide net) and proposed as a draft pull request for maintainer review. Nothing is auto-merged. See the sibling Threat-Actors-use-of-Artifical-Intelligence tracker for the same workflow applied to threat-actor AI use.

How the data is built

The data lives only in the table below (this file is the single source of truth). A deterministic, dependency-free generator (tools/build_exports.py) compiles it on every commit into:

• index.html — the interactive dashboard (served via GitHub Pages),
• tracker.json — normalized machine-readable data,
• stix/prompt-injection-stix2.1.json — a STIX 2.1 bundle (each technique as an attack-pattern, tagged with its MITRE ATLAS ID and a Not fully vetted → low-confidence mapping).

Do not hand-edit those three files; edit the table and let CI rebuild them.

---

Techniques

---

Appendix A — Delivery methods (controlled vocabulary)

How the injected instructions reach the model. Extensible; add a new term here when a report describes a genuinely new vector.

• Direct prompt — attacker-controlled text typed straight into the model's input.
• Indirect – website / HTML — instructions embedded in a web page the model browses or summarizes.
• Indirect – document / file — payload inside a PDF, DOCX, spreadsheet, or other file the model ingests.
• Indirect – email — instructions inside an email an agent reads or triages.
• Indirect – RAG / retrieved content — payload planted in a knowledge base, vector store, or search result the model retrieves.
• Tool-call / function result — instructions returned in the output of a tool/function the agent invokes.
• MCP server / connection — payload served by a Model Context Protocol server or tool description.
• Multimodal – image — instructions in an image (visible text, low-contrast text, or pixel/metadata payload).
• Multimodal – audio — instructions carried in an audio input.
• Code / repository content — payload in source code, comments, issues, or CI logs an agent reads.
• Calendar / invite — instructions inside a calendar event, invite, or meeting note.

Appendix B — Encodings (controlled vocabulary)

Obfuscation applied to the payload. Blank in the table means the payload was plain text or the report did not specify.

• Base64
• Hex
• ROT13
• Leetspeak
• Unicode tag characters (invisible) — U+E0000-range "tag" glyphs that render invisibly.
• Zero-width characters — zero-width space/joiner used to hide or split text.
• Homoglyphs — look-alike Unicode substitutes for ASCII letters.
• Emoji / variation-selector smuggling
• HTML / Markdown comment — payload hidden in comments or non-rendered markup.
• Metadata / EXIF — instructions in file or image metadata.
• Multi-layer — more than one of the above, stacked.

Appendix C — Propagation behaviors (controlled vocabulary)

Whether the injection is designed to spread or persist. Blank in the table means no propagation behavior was reported.

• Self-propagating / worm (AI-to-AI) — output is crafted to become the next system's injected input.
• Persists in agent / project memory — written into long-term or project memory so it re-triggers on later sessions.
• Spreads via MCP to connectors — a poisoned MCP server delivers the payload to every client that connects.
• Moves through tool-call chain — carried forward across a sequence of tool calls within one agent run.
• Emits outbound email / message with further instructions — causes the agent to send a message that itself carries the injection.
• Poisons shared data store / RAG — plants the payload where other users' or agents' retrievals will pick it up.
• Spreads via shared config / rules files — malicious agent rules/config propagate through shared or central rule repositories into derived projects (CREDIT: Rachel James, based on the Pillar Security "Rules File Backdoor" report).
• Cross-agent / cross-session — reaches other agents or later sessions beyond the initial context.

Appendix D — MITRE ATLAS crosswalk

Techniques are tagged with MITRE ATLAS technique IDs where one applies. IDs are validated on each update against MITRE's canonical mitre-atlas/atlas-data source (the data that generates the live matrix; the atlas.mitre.org site is a JS app that blocks automated fetch). Behaviors with no clean ATLAS mapping are noted with a coined label (CREDIT: Rachel James, based on the cited report). IDs used in this tracker:

• AML.T0051 LLM Prompt Injection — AML.T0051.000 Direct, AML.T0051.001 Indirect
• AML.T0053 AI Agent Tool Invocation (supersedes the retired "LLM Plugin Compromise" title)
• AML.T0054 LLM Jailbreak
• AML.T0057 LLM Data Leakage
• AML.T0068 LLM Prompt Obfuscation

---

Contributions welcome — see CONTRIBUTING.md, or submit a technique directly. Every proposed row must cite an explicit source for each non-blank field; unclear entries are marked "Not fully vetted" rather than dropped.