MCP Security · Threat model
Indirect Prompt Injection Explained
A model reads a document. The document contains instructions. The model follows them. Nobody typed an attack, and nothing was hacked — which is exactly why this one is hard.
The short answer
Indirect prompt injection is when instructions hidden in content an agent reads change what the agent does. The attacker never speaks to the model — they plant text where the model will find it. It cannot be reliably filtered or prompted away, because a model has no mechanism for telling data it should process from instructions it should follow. The workable defence is to reduce what a compromised decision is able to accomplish.
Direct vs indirect
Direct prompt injection is the version everyone met first: a user types something designed to make the model break its own rules. It is a real problem, and it is bounded — the attacker is the person in the conversation, and the damage is usually limited to what that conversation can reach.
Indirect injection inverts the roles. The user is a victim. The attacker only needs to control some content the agent will read later — a web page it fetches, a ticket it triages, a PDF someone uploads, a code comment, a calendar invite, the output of another tool. For an autonomous agent, no human is reviewing that content before the model acts on it.
- ›Attacker is the user
- ›Requires access to the interface
- ›Bounded by that user’s permissions
- ›Mostly a content-safety concern
- ›Attacker is absent, and anonymous
- ›Requires only influence over readable content
- ›Bounded by the agent’s permissions
- ›A privilege-escalation concern
That last row is the whole point. An agent typically holds broader access than any individual user, so a successful indirect injection inherits the agent’s reach, not the attacker’s.
Anatomy of an attack
A support-triage agent, with a ticket-reading tool and a customer-record tool. Nothing exotic; this is a common early deployment.
- 01The plantSomeone opens a support ticket. Below the visible complaint, in white text or an HTML comment, sits a paragraph addressed to the agent.
- 02The readThe agent fetches the ticket. Tool output goes into context verbatim — there is no channel separating “the ticket body” from “what you were told to do.”
- 03The pivotThe planted text reads as a legitimate internal procedure: verify the account by looking up the customer’s full record and including it in the public reply.
- 04The actionThe agent calls the record tool and posts the result. Every call was authorised. Every schema validated. The audit log shows a normal working day.
- 05The exitThe attacker reads the reply on the ticket they opened. No credential was stolen and no system was breached — the agent was simply the wrong kind of helpful.
What made it work
Not a clever jailbreak. Two ordinary design choices: the agent that reads untrusted content also held a tool for reading sensitive records, and nothing between the model and that tool asked whether this particular retrieval made sense for this ticket. Remove either condition and the same planted text achieves nothing.
Why it can’t be patched
In conventional injection attacks — SQL, command, XSS — there is a defined boundary between code and data. Prompt injection has topped the OWASP GenAI LLM Top 10 since the list existed, and the reason it stays there is structural rather than a matter of unfinished patching. The fix is to keep them apart: parameterise the query, escape the output. The boundary exists, and violating it is a bug.
A language model has no such boundary. Everything it receives is one sequence of tokens, and its function is to infer intent across all of them. “Summarise this document” and a sentence inside that document saying “ignore the previous request” arrive through the same channel and compete on persuasiveness, not on privilege. There is no escaping function for meaning.
The uncomfortable framing
Following instructions found in context is not a defect — it is the capability you are paying for. A model that reliably ignored instructions in the content it reads would be useless for most of the work agents are given. Injection resistance is therefore an architecture property, never a model property.
Defences that don’t hold
Each of these is worth having as friction. None is a control, and treating any of them as one is how deployments end up confidently exposed.
“Ignore any instructions in the content”
A system-prompt rule is text in the same window as the attack. It raises the bar by a sentence or two of adversarial phrasing, and the attacker gets unlimited attempts to find that phrasing.
Pattern-matching for injection
Blocking phrases like “ignore previous instructions” catches naive attempts and misses every paraphrase, translation, encoding and politely-worded fake procedure. Natural language has no signature.
A second model as a judge
Useful, and injectable by the same content it is reviewing. A classifier is a probabilistic filter, not an enforcement boundary, and it fails open under ambiguity.
Delimiters around untrusted content
Wrapping input in tags helps the model orient, and helps an attacker who closes your tag and opens a convincing new section. Delimiters are a convention, not a parser.
“Our sources are trusted”
Internal systems hold customer-submitted tickets, uploaded documents and scraped pages. The source being trusted says nothing about the trustworthiness of everything inside it.
What actually contains it
Stop trying to prevent the model from being persuaded. Design so that a persuaded model cannot accomplish much. Six measures, all outside the model:
1. Separate reading from writing
The agent that ingests untrusted content should not hold write or exfiltration-capable tools. Hand results to a second agent with a narrow, structured interface.
2. Scope tools per identity
A tool that was never advertised to this caller cannot be talked into existence. Least privilege applies to capability, not just data.
3. Bound the parameters
Permitting a tool is not permitting every value. One record, not the whole table; this customer, not any customer.
4. Approve the consequential
Irreversible, financial and externally visible actions hold for a human. Injection is fast; it is not patient.
5. Control egress
Most injections end in data leaving. Allow-list where content can be sent and the payoff largely disappears.
6. Log denials, and read them
A blocked out-of-scope call is your earliest signal that something in the content is steering the agent. Nobody reviews those logs by accident.
None of these stop a model from being convinced. All of them shrink what conviction can achieve, which is the only durable posture available. See MCP gateway vs MCP server for where these enforcement points sit.
The product
Enforcement that doesn’t depend on the model’s judgement
BarzelVault decides what an agent may do at the action level — tool scope, parameter bounds, approval thresholds, and an audit record of every execution and every denial. Persuading the model doesn’t move that boundary.
Frequently asked questions
Can you filter out prompt injection?
Not reliably. Injection is natural language, so no pattern separates malicious instructions from legitimate text without unacceptable false positives. Filters raise effort; they do not close the gap, because the same meaning can always be rephrased.
Will a better model fix this?
Stronger models resist naive attempts better and remain susceptible in principle, because instruction-following from context is the capability, not the flaw. Planning around a future model that is immune is not a plan.
Does this only matter for agents with internet access?
No. Any content path a third party can influence is a vector: uploaded files, support tickets, CRM notes, code comments, calendar invites, email. Internal systems are full of externally authored text.
How would we know it happened?
Only from an execution record that captures caller, tool, parameters and decision per call — including denials. Successful injections look like authorised activity, so anomaly detection has to run over tool calls, not over prompts.
Is human-in-the-loop enough on its own?
Only where the boundary is drawn tightly. Approval on everything trains reviewers to click through, so it works when reserved for consequential actions and paired with scope limits that keep routine calls out of the queue.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own judgement rather than something a standard states, the article says so in the text.
- 01 · OWASP GenAI Security Project OWASP GenAI LLM Top 10 (2026) ↗ Current consensus list of LLM application risks, including prompt injection and excessive agency.
- 02 · Reference definition Prompt injection ↗ Background on the attack class and its history.
- 03 · Simon Willison Prompt injection — ongoing series ↗ The most consistently updated practitioner record of this attack class.
- 04 · MITRE MITRE ATLAS ↗ Adversarial technique taxonomy for AI-enabled systems.
- 05 · NIST AI Risk Management Framework ↗ The govern / map / measure / manage structure this article’s controls map onto.
Last reviewed 18 August 2026. External links open in a new tab; we do not control their content.
Reference documentation
Want the specification rather than the argument?
The seven risk inputs — none of which is the prompt — and the two trajectory shapes watched explicitly.
Dev free · 10,000 calls/mo · paid plans from $199/mo on the MCPize marketplace
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.