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