Indirect Prompt Injection: Hijacking Bing Chat from a Web Page
On this page
The research that named indirect prompt injection — and proved a web page could turn your AI assistant against you.
| When | February 2023 |
|---|---|
| Target | Bing Chat (+ other LLM-integrated apps) |
| Vendor | Microsoft (research demonstration) |
| Researchers | Greshake, Abdelnabi et al. (CISPA) |
| Technique | Indirect injection via hidden web-page text |
| Published | arXiv 2023; ACM AISec / Black Hat USA 2023 |
- 1Attacker plants hidden (zero-size) instructions on a web page
- 2The user opens the page while Bing Chat is assisting; Bing ingests the page content
- 3Bing follows the injected instructions — e.g. becomes a scammer phishing the user's details
What happened
In February 2023, researchers led by Kai Greshake and Sahar Abdelnabi introduced and named indirect prompt injection in the paper “Not what you've signed up for.” They showed that an LLM-integrated app which ingests attacker-controlled external content can be hijacked — and demonstrated it against Microsoft's Bing Chat. Hidden, zero-size text on a web page the user had open could steer Bing into a pirate persona, or into a “convincing scammer” that tries to elicit the user's personal and financial details.
How the attack worked
Bing Chat could read the page in the user's browser. Because the model cannot tell trusted instructions from untrusted data — both are just text in one context — instructions hidden on the page competed with, and beat, Bing's own directives. No access to the user's prompt was needed; the attacker only had to control content the assistant would read.
Why it generalisesAny application that feeds a model attacker-reachable content — web pages, documents, emails, tickets — inherits this risk. Bing was the demonstration; the class is universal.
Root cause
There is no privilege boundary inside a context window. Trusted system instructions and untrusted retrieved content sit side by side, and a sufficiently direct injection in the untrusted half can override the trusted half.
What a test would have caught
Feeding the assistant a page or document containing injected instructions and checking whether its behaviour changes — persona, tone, what it asks the user for — is the canonical indirect-injection test, and it is exactly what this research systematised.
How to prevent it
- Isolate untrusted content and mark it clearly as data, never instructions.
- Constrain what the assistant can do off the back of retrieved content (no sensitive actions, no data-eliciting behaviour).
- Assume any ingested content is adversarial and design so a hijack can't cause harm.
Feel it yourselfThe replay lab lets you plant instructions in content an assistant retrieves and watch it obey them.
FAQ
How is indirect injection different from normal prompt injection?
In a direct attack the user types the malicious instruction. In an indirect attack the instruction hides in external content the assistant ingests — a web page, a document, an email — so a third party can attack a user who did nothing wrong.
What did the researchers actually show against Bing?
That hidden, zero-size text on a page open in the browser could steer Bing Chat's behaviour — making it adopt a pirate persona, or act as a “convincing scammer” trying to elicit the user's personal and financial details.
Why does this keep happening?
Because an LLM can't separate trusted instructions from untrusted data — both arrive as text in one context. Any app that feeds the model attacker-reachable content inherits this risk unless it isolates and constrains that content.