Prompt injection is the top entry on the OWASP Top 10 for LLM Applications (2025), listed as LLM01, and it comes in two forms that behave very differently in production systems. Direct prompt injection happens when an attacker types adversarial instructions straight into a chat interface — the December 2023 case where a Chevrolet dealership's chatbot was talked into "agreeing" to sell a 2024 Tahoe for $1 is a textbook example. Indirect prompt injection is scarier for engineering teams: the malicious instructions live inside a document, webpage, email, or file that the model ingests later, with no attacker ever touching the prompt box directly. Kai Greshake and colleagues formalized this distinction in their February 2023 paper "Not What You've Signed Up For," and it has since driven real CVEs, including a 9.3-severity zero-click flaw in Microsoft 365 Copilot. This post breaks down both vectors, how they differ operationally, and what to actually do about them.
What is direct prompt injection?
Direct prompt injection is when an attacker submits adversarial text as their own input to an LLM, trying to override its system prompt or safety instructions in the same turn. The classic pattern is "ignore all previous instructions and instead..." followed by a request the model would normally refuse. The DAN ("Do Anything Now") jailbreak prompts that circulated across Reddit and GitHub throughout 2023 are the most widely cited example — they instructed ChatGPT to roleplay an unrestricted persona to bypass content policies. The Chevrolet of Watsonville incident in December 2023 is the commercial-harm version: a customer directly prompted the dealership's GPT-powered chatbot with instructions to agree to any statement and confirm no take-backs, then got it to "sell" a $76,000 truck for one dollar. In both cases, the attacker is the same person interacting with the model — there's no third party and no hidden payload. This makes direct injection easier to reason about: the trust boundary is "the user typing right now," and defenses like input filtering, system-prompt hardening, and output validation apply directly to that single channel.
What is indirect prompt injection?
Indirect prompt injection is when malicious instructions are planted in external content — a webpage, PDF, email, calendar invite, GitHub issue, or API response — that an LLM later retrieves and processes as trusted data. Greshake et al.'s 2023 paper demonstrated this against Bing Chat by embedding hidden instructions in a webpage that the assistant summarized, causing it to attempt to extract user information and impersonate a Microsoft support agent. The attacker never talks to the model; they poison a data source the model is expected to consume, and the actual victim is whoever asks the model to summarize, search, or act on that content later. This is fundamentally a software supply chain problem: any pipeline that feeds retrieved, third-party, or user-uploaded content into an LLM without treating it as untrusted input inherits this risk, whether that content arrives via RAG, browser plugins, email connectors, or MCP tool calls.
How do direct and indirect attacks differ in practice?
The core difference is who controls the malicious input and how far it travels before it executes. In direct injection, the attacker and the victim are the same entity, the payload arrives in a single request, and the blast radius is typically limited to that user's own session. In indirect injection, the attacker and the victim are different people, the payload is staged in advance inside content the model will later ingest, and the blast radius extends to every user or automated agent that processes that poisoned source — a shared document, a public repo, a scraped webpage. That means a single indirect injection payload planted once can compromise hundreds of downstream sessions without the attacker doing anything further, which is why indirect injection scores far higher on severity in agentic and RAG-connected systems: Aim Security's June 2025 EchoLeak disclosure (CVE-2025-32711) carried a CVSS score of 9.3 precisely because it required zero user interaction — a single crafted email triggered Microsoft 365 Copilot to exfiltrate internal data automatically.
What real-world incidents show indirect injection hitting the software supply chain?
Two disclosures in 2025 show indirect prompt injection moving from research demo to exploitable supply chain risk. EchoLeak (CVE-2025-32711), disclosed by Aim Security in June 2025, let an attacker send a specially crafted email to a target; when Microsoft 365 Copilot later processed that email as context for an unrelated user request, hidden instructions caused it to pull sensitive internal data and leak it via a crafted link — no click, no attachment open, nothing from the victim required. Separately, in March 2025 Pillar Security disclosed the "Rules File Backdoor" technique, in which attackers embedded invisible Unicode characters and hidden instructions inside configuration and rules files consumed by AI coding assistants like GitHub Copilot and Cursor, causing the assistants to silently inject vulnerable or backdoored code into generated output while appearing to produce clean diffs. Both cases share the same shape: a legitimate-looking artifact — an email, a repo config file — carries a payload that only executes once an LLM with elevated access reads it, which is exactly the attack surface software supply chain teams are already used to defending in the form of dependency and build-pipeline compromise.
Why is indirect injection harder to defend against than direct injection?
Indirect injection is harder because the attack surface is every external data source an LLM touches, not a single input box you control. Direct injection defenses — system prompt hardening, keyword and intent filtering, refusal fine-tuning — all assume you can inspect the one channel where user text arrives. Indirect injection payloads can hide in HTML comments, alt text, PDF metadata, invisible Unicode (as in the Rules File Backdoor case), email headers, or tool-call responses from third-party APIs, and they only need to survive whatever content the model is told to trust as "context" rather than "instructions." Worse, agentic systems that chain multiple tool calls — search, then summarize, then send an email — can propagate an injected instruction across several steps before a human ever sees the output, which is what made EchoLeak a zero-click exploit rather than a phishing-style attack requiring victim action.
How can security and engineering teams detect and mitigate both types?
Effective mitigation treats direct and indirect injection as related but distinct problems requiring layered controls. For direct injection: harden system prompts against override language, apply output-side validation before actions execute, and rate-limit or log adversarial patterns at the input layer. For indirect injection: treat all retrieved content — scraped pages, ingested documents, tool outputs, repo files — as untrusted data, strip or flag hidden Unicode and non-printing characters before they reach the model, and require explicit human or policy-gated approval before an agent with tool access acts on instructions found inside retrieved content. For both, least-privilege scoping of what an LLM agent can actually do (send email, write files, call APIs) limits how much damage a successful injection can cause, and continuous monitoring of AI-assisted code changes and file ingestion pipelines catches payloads like the Rules File Backdoor before they merge.
How Safeguard Helps
Safeguard's Griffin AI engine is built to catch exactly the kind of injected, obfuscated payload seen in the Rules File Backdoor case — flagging hidden Unicode, suspicious instruction-like strings, and anomalous patterns in AI-assistant config files, rules files, and dependencies before they land in a codebase. Reachability analysis lets teams prioritize which ingested-content pathways (RAG pipelines, email connectors, plugin integrations) actually expose exploitable LLM tool-call chains in their running application, rather than treating every third-party data source as equal risk. Safeguard's SBOM generation and ingest capabilities extend software bill of materials visibility to AI tooling and coding-assistant configurations, so a poisoned rules file or compromised plugin shows up as a tracked component rather than an invisible blind spot. When Griffin AI flags an injection risk, Safeguard can open an auto-fix PR that strips the malicious content or hardens the affected file, closing the loop from detection to remediation without waiting on a manual triage queue.