Direct vs Indirect Prompt Injection

The taxonomy starts with the attacker path

Prompt injection is easiest to understand by asking where the hostile instruction enters the system. In a direct attack, the attacker is the user, or at least controls the user prompt. In an indirect attack, the attacker controls content the application retrieves, summarizes, ranks, parses, or reasons over. Both exploit the same design weakness: natural language can be both data and instruction.

Jailbreak is often used for direct attempts to bypass safety behavior. Prompt injection is broader. It includes jailbreak-style requests, but it also includes attacks that target the surrounding application: tool use, retrieval, output rendering, policy decisions, memory, or private context.

Direct prompt injection

Direct prompt injection happens when a user prompt asks the model to ignore, reinterpret, or override the developer's intended behavior. The content may be obvious, encoded, role-played, wrapped in fake conversation turns, translated, or hidden in a format the application did not expect. The details vary, but the goal is the same: make the model prefer the attacker's instruction over the app's instruction.

The defensive lesson is not "block one phrase." Attackers can paraphrase. They can use another language. They can wrap the request in a story, a test case, a quoted document, a JSON field, or a faux system message. A production app needs policy outside the model: what data can be returned, what tools can be called, what parameters are valid, and when a human must approve.

Indirect prompt injection

Indirect prompt injection is data-borne. The user may ask a harmless question: "summarize this page," "find action items in my email," "review this pull request," or "compare these vendors." The application then fetches content controlled by someone else. If that content contains instructions aimed at the model, the model may treat them as part of the task.

Greshake et al. made this risk concrete in 2023 by studying LLM-integrated applications where retrieved prompts can shape behavior. The important insight is that retrieval turns third-party data into model input. Once an LLM has tools or private context, the difference between "read this text" and "obey this text" becomes a security boundary the application must enforce.

Real examples map to the same pattern

The early Bing Chat prompt-leak episode is a direct case: a user interacted with a production chatbot and elicited hidden setup instructions. Browser-sidebar and web-page examples are indirect: the assistant reads a page, and page content tries to influence the assistant. Plugin demonstrations are indirect plus tool abuse: a retrieved page steers the chat toward another plugin or rendering behavior. Email-assistant cases are indirect plus ambient authority: a malicious email sits in a mailbox until an AI assistant indexes or summarizes it.

These are not separate species of bug. They differ mostly by entry point, privilege, and blast radius. A chatbot with no tools can still mislead. An agent with inbox access, CRM write access, shell access, or payment authority can cause much more concrete harm.

The defensive rule

Treat anything outside your application boundary as untrusted data, even when the user asked the model to process it. That includes web pages, emails, PDFs, code comments, retrieved chunks, search snippets, calendar invites, GitHub issues, Slack messages, and customer records. The model can summarize untrusted text, but untrusted text should not gain the power to change policy, access private data, or trigger high-impact actions.