Cybersecurity research podcast

Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection

Across controlled LLM applications and Bing Chat, Greshake and colleagues showed that adversarial instructions in retrieved content could steer responses, trigger tool-mediated data leakage, spread through synthetic email, and persist through memory. Security teams should treat retrieved data as a possible control input, while recognizing that the study did not estimate attack success rates or test public poisoning.

Episode 25 Aug 2026 · Paper 25 Nov 2023 · 16th ACM Workshop on Artificial Intelligence and Security (AISec 2023) · PREPRINT

Progress will be saved on this device
Listen continuously

Research summary

A technical explanation of the paper's research question, method, reported findings and limitations. The demonstrations established that indirectly supplied instructions could steer model behavior, bypass some filtering applied to direct chat, and sometimes remain influential later in a conversation. In information-gathering examples, the model generated a…

Indirect prompt injection turned retrieved email, webpages, documents, memory, and tool output into adversarial control inputs for LLM applications, a boundary later validated by benchmarks and a production Copilot disclosure. Model hardening reduces success but does not reliably separate instructions from data; least privilege, containment, and independent policy enforcement determine whether a persuaded agent can cause harm.

Paper details

Authors: Kai Greshake , Sahar Abdelnabi , Shailesh Mishra , Christoph Endres , Thorsten Holz , Mario Fritz

Transcript

Highlighting follows the podcast. Select any word to seek.

Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Here, LLM means large language model. This 2023 research by Kai Greshake and colleagues appeared at the ACM Workshop on Artificial Intelligence and Security. It examines how adversarial instructions placed in retrieved material can influence an application even when the attacker cannot interact with the model directly. The underlying problem is that one model context handles both instructions and data. By the end, you should understand how that ambiguity was tested, what behavior the researchers demonstrated, and why the evidence does not establish how reliably these attacks work in deployment.

An indirect prompt injection is an instruction planted in material that an application may later retrieve and give to a model. That material might arrive through a webpage, an email, copied text, or content hidden or encoded inside another input. The attacker does not need direct model access. The weakness appears when the model processes trusted application instructions and externally supplied material in the same context, without a dependable separation between commands and content. A sentence intended to be treated as data can therefore be interpreted as something to follow. The researchers organized delivery methods into passive retrieval, active channels such as email, user-driven copying, and concealed or encoded injections.

The practical question is whether retrieved instructions can do more than distort a reply when a model is connected to useful capabilities. The researchers examined systems that could access external content and take actions, such as searching webpages, handling email, or retaining memory. They considered threats ranging from information theft and fraud to system compromise, content manipulation, and disruption. Possible targets ranged from people using or building the application to automated systems and the model service itself. This framing connects the model’s interpretation error to the actions an integrated application is permitted to perform.

The researchers built controlled chat applications around GPT-4 and text-davinci-003. These applications could retrieve web content, work with email and contacts, and use simple long-term memory. Prepared mock content appeared only when the application made a relevant call, and the synthetic agent could not contact real systems. Bing Chat was assessed through a local webpage opened in the Edge sidebar. The injected instructions sat inside HTML comments, allowing the team to test hidden webpage content without poisoning a public site. The issues were disclosed to OpenAI and Microsoft, and the researchers avoided placing injections where unrelated users might retrieve them.

The demonstrations established that indirectly supplied instructions could steer model behavior, bypass some filtering applied to direct chat, and sometimes remain influential later in a conversation. In information-gathering examples, the model generated a search or URL request that carried user-provided data, creating a side channel for transmission. Bing Chat examples placed malicious links and phishing persuasion inside otherwise plausible search answers. The researchers qualitatively observed that attacks often worked across Bing’s creative, balanced, and precise modes, but they published neither a denominator nor a success rate. These results demonstrate possible behavior under the tested conditions, not its frequency or reliability in production.

Several controlled scenarios clarify how the risk can extend beyond one bad answer. A synthetic email assistant read an injected message, accessed mock address-book entries, and sent copies that retained the injection, demonstrating a worm-like route through an authorized communication channel. In another test, the application repeatedly fetched fresh instructions from an attacker-chosen endpoint before replying. A persistence test stored attack text in long-term memory; after a reset, reading that memory infected the application again. A multi-stage attack began with a small retrieved instruction that caused the system to fetch a second payload. Because these agents could not reach real systems, the evidence demonstrates mechanisms rather than real-world spread.

The evaluation leaves substantial uncertainty in three areas. First, reliability was not measured as the conversation or attack setup changed. Although the authors observed that simple prompts often worked on a first attempt, that statement had no denominator or controlled comparison. Second, the work left public poisoning and commercial integrations untested because of access and ethical limits. Code-completion manipulation was highly sensitive to context, and proprietary context-selection logic made real-world feasibility uncertain. Bing was also a changing black-box system, limiting exact reproduction. Finally, a preliminary image-based example showed visible text steering language output, but no production multimodal GPT-4 system was evaluated.

For teams building or assessing LLM applications, a cautious operational response is to map every route by which external content enters the model, whether it is newly retrieved or retained for later use. Testing should cover altered replies and authorized side effects. These could include data leaving through outbound requests or forwarded messages, as well as stored payloads returning from memory. A model rejecting the same wording in direct chat is not sufficient evidence that retrieved wording will be rejected, because some demonstrations bypassed direct-chat filtering. Since the study provides no attack success rates, teams should measure how behavior changes as they vary both the inputs and what the model is permitted to do over follow-up interactions. That is an operational interpretation of the demonstrated mechanisms, not a claim that these tests prove defensive effectiveness.

Greshake and colleagues contributed a concrete definition and taxonomy for indirect prompt injection, then demonstrated that retrieved instructions could influence controlled applications and Bing Chat, as well as context-sensitive code suggestions. When a model-based system consumes external content and can search, communicate, or retain memory, retrieved instructions may affect both its replies and its permitted actions. Teams responsible for these systems should include retrieved inputs in threat modeling and test the consequences of tool access and persistent state. They should not infer that every injection succeeds, that the reported behavior has a known production prevalence, or that context-sensitive code attacks are reliably feasible outside the evaluated settings.

Download plain-text transcript