Incident record

Prompt Injection Incidents

A dated, sourced timeline of prompt-injection reports and demonstrations, with the defensive lesson from each case.

Updated 2026-07-06

Timeline of documented cases

Public prompt-injection history is young and uneven. Some entries are production incidents, some are research demonstrations, and some are proof-of-concept attacks disclosed by security researchers. They are still useful because they expose the same recurring failure modes: hidden instructions, weak trust boundaries, excessive tool authority, and output channels that can leak data.

February 2023

Bing Chat initial prompt leakage

Early testers reported that Bing Chat could be induced to reveal hidden setup instructions. The defensive lesson is that system prompts are not secrets and should not contain credentials, policy bypasses, or information that must remain confidential.

February to May 2023

Indirect prompt injection formalized

Greshake et al. described how retrieved prompts in web pages, documents, and other external data can influence LLM-integrated applications. The defensive lesson is to treat retrieval as an untrusted input path, not as neutral background context.

May 2023

Plugin and rendering exfiltration demonstrations

Researchers showed how a malicious page processed by a plugin-enabled chat session could steer the assistant toward data exfiltration paths such as rendered Markdown images or chained plugin calls. The defensive lesson is to validate outputs and outbound requests, not just inputs.

Email assistant cases

Hidden instructions in email workflows

Email-agent demonstrations show how malicious instructions can be hidden inside HTML email, metadata, or documents and activated later by an AI assistant. The defensive lesson is that inbox content is untrusted even when it sits inside a user's own mailbox.

What defenders should take from the timeline

Do not store secrets in prompts. Do not let page or email text decide tool calls. Do not render model-generated links, images, HTML, or Markdown without safety checks. Do not assume a retrieved document is safe because the user asked the assistant to read it. Do not give an agent broad permissions and then rely on a model instruction to use them responsibly.

The cases also show why "no known exploit in our app" is a weak comfort. Product teams change prompts, retrieval, tools, models, and UI affordances frequently. A safe design needs regression tests and logs that survive those changes.

Limits of this incident list

This page intentionally avoids live payloads and does not claim that every proof of concept reflects a confirmed production breach. The goal is defensive pattern recognition. Each source below should be read in context, especially when deciding whether a case applies to your architecture.