This is the "holy grail" of attacks on LLM-based applications. It's the threat that has held the top spot in the OWASP Top 10 for LLM Applications since the list's first edition, and it has kept that spot through every update since. Even OpenAI's own security team has said publicly that it doesn't expect prompt injection to ever be fully "solved," comparing it to phishing and social engineering: a permanent category of risk to be managed, not a bug to be patched.
OWASP Top 10 for LLM Applications Prompt Injection Description Prompt injection used to mostly mean getting a chatbot to say something embarrassing. Now it means getting an autonomous agent with access to your inbox, your files, and your payment methods to act on an attacker's behalf instead of yours. Same vulnerability class, much higher stakes.
What is Prompt Injection? Prompt injection is any input, crafted by an attacker, that manipulates an LLM or LLM-based application into behaving outside its intended scope. The model can't reliably tell the difference between "instructions from the system" and "data it's supposed to process," because both arrive in the same channel: natural language text. An attacker who understands this can smuggle instructions inside what looks like ordinary content, and the model will often follow them.
This becomes a serious problem the moment an LLM is connected to anything else: a database, an API, a code interpreter, an email inbox, a browser, or a tool via the Model Context Protocol (MCP). Every connection is a new place an attacker's instructions can land and a new action they can trigger. Traditional applications validate structured input against an expected format. LLM applications accept effectively unbounded natural language and then act on it, which is a fundamentally harder thing to secure.
Types of Prompt Injection There are several categories of prompt injection, each with different levels of technical depth. Here's an overview of the main ones as they stand today.
Direct Prompt Injection The classic version. The system expects a prompt from the user, and the user writes one intended to override the model's instructions rather than use it as intended, most commonly by telling it to disregard its system prompt. This remains the simplest form of the attack and the easiest to demonstrate, even as both offensive and defensive techniques around it have matured considerably.
Indirect Prompt Injection Here , the malicious instructions don't come from the user at all. They arrive through a third-party data source the LLM is asked to process: a webpage, a document, an email, a calendar invite, a search result. The user does something entirely benign, like asking an assistant to summarize an email or browse a page, and the assistant unknowingly ingests and executes instructions planted by someone else entirely.
Simple Indirect Prompt Injection from a LinkedIn Profile This is the category that has done the most damage to the "prompt injection is a lab curiosity" narrative. Security researchers have already disclosed a zero-click vulnerability in a major enterprise AI copilot: a single crafted email, requiring no click or download from the victim, was enough to get the assistant to quietly exfiltrate sensitive internal data to an attacker-controlled server. No phishing link. No attachment. The victim just had to have the email sitting in their inbox. It was patched, but it established indirect prompt injection as a practical, exploitable vulnerability class rather than a theoretical one, and it won't be the last example.
Agentic browsers have opened the same door from a different angle. When an AI agent can read a webpage or a shared document and then take actions like sending an email or completing a purchase, hidden text on that page becomes a command channel. Within hours of one major agentic browser's public launch, researchers had demonstrated that a few words hidden in a Google Doc could redirect the agent's behavior entirely.
Visual Prompt Injection As AI applications have gone multimodal, the attack surface has followed. An image (or, increasingly, audio or video) can carry instructions that are invisible or meaningless to a human viewer but fully legible to the model processing it. A textual prompt can be completely benign while the accompanying image quietly redirects the model's output. This category has only grown more relevant as multimodal agents take on more real-world tasks.
Agentic and Tool-Based Prompt Injection This category didn't really exist when this post was first written, and it's arguably the most important one now. As agents adopt standardized ways of calling external tools, most notably MCP, a new variant has emerged: tool poisoning. An attacker stands up a malicious MCP server, or compromises a legitimate one, and embeds hidden instructions inside a tool's metadata, such as its description field. That metadata isn't reviewed the way code is, and it isn't visible to the end user. When an agent evaluates which tool to call, it reads the poisoned description as ground truth and can be manipulated into leaking credentials, calling tools it shouldn't, or bypassing its own system prompt entirely, all without the "malicious" tool ever technically being invoked.
Tool poisoning is best understood as a specialized descendant of indirect injection, but it deserves its own category because the trust boundary it exploits is different: tool descriptions are typically checked once, at connection time, while nothing polices what a tool's actual responses smuggle in at runtime. Given how quickly MCP adoption has moved, this is a live and underscrutinized risk in most agentic deployments today.
Why is it still so hard to block? Traditional security layers relied on heuristics, pattern matching, regex, and known-bad signatures. Those approaches assume a structured, bounded input space. Prompt injection breaks that assumption: the input space is natural language, in any language, of any length, across infinite phrasings and contexts. There is no finite list of "bad strings" to block.
Guardrails built specifically for this problem, like classifiers trained to catch cross-prompt injection attempts, help, but they can be bypassed by simply not mentioning the AI system at all. The zero-click incident referenced above got past exactly this kind of classifier by phrasing its hidden instructions as though they were addressed to the human recipient of the email, not the AI reading it. A detector looking for "AI-directed language" never had anything to catch.
It's worth being direct about this: there is no version of this problem that gets fully solved. The realistic goal is raising the cost and complexity of a successful attack, not eliminating the possibility of one.
How risky are prompt injections, really? It depends on what the model is connected to.
At the low end, you get a chatbot that starts talking like a pirate or cracking bad jokes. Annoying, not damaging.
In the middle, you get brand and legal exposure. The textbook example is still the Chevrolet dealership chatbot that got talked into "agreeing" to sell a truck for a dollar. Not an infrastructure-down event, but exactly the kind of screenshot-ready embarrassment no legal or comms team wants to deal with.
At the extreme end is where things sit today for any organization running agents against real systems. When an LLM has genuine reach into APIs, databases, code execution, email, or file storage, prompt injection stops being about embarrassing outputs and starts being about unauthorized actions: silent data exfiltration, unintended transactions, privilege escalation, credential theft. This is SQL injection's blast radius with none of SQL injection's constraints. The input isn't limited to one query language; it can be English, code, or numbers, and the targets aren't limited to one database; it's anything the agent can touch.
So what can we actually do about it? Start with visibility. You can't catch what you're not watching for, so monitoring agent behavior for anomalies, and being able to reconstruct what happened after the fact, is table stakes.
From there, it's defense in depth, not a single fix:
Harden the prompt layer. Clearly separate system instructions from user and third-party content, and don't rely on the model to police that boundary on its own.Scope agent permissions tightly. Treat every agent and every MCP connection as a semi-trusted actor with the minimum access it needs for the task in front of it, not the account's full privileges.Review what agents can reach before an attacker does. What external content can this agent ingest? What internal data can it access? What actions can it take unsupervised? Those three questions define the actual blast radius, independent of any single vulnerability.Keep a human in the loop for consequential actions. Sending money, sending sensitive data externally, or modifying production systems are reasonable places to require a checkpoint, even in an otherwise autonomous workflow.Red team continuously, not once. New injection techniques and new agent capabilities both ship constantly. A defense validated last quarter is not guaranteed to hold today.Layered together, these controls add up to a real defense, a dedicated, multi-layered system built for how LLMs actually behave rather than security tooling retrofitted from traditional applications. That's the difference between catching an attempted injection before it does damage and finding out about it after the fact.
