Prompt Injection: What It Is and How to Stop It
RedHub AI Editorialupdated August 18, 20265 min read
Jump to a section9
TL;DR
- What it is: prompt injection hides a malicious instruction inside content an agent reads — a web page, email, or document — so the agent executes it as if its real user asked.
- Who it's for: any team whose agent reads untrusted content — see the Indirect Prompt-Injection Exposure Gate.
- How it works: direct (typed straight at the model) vs. indirect (planted in content the agent later reads); the dangerous chain is enter, act, go uncaught.
- Bottom line: it's not a bug you patch once — it's an attack class. Grade the exposure and gate it, don't assume it can't reach you.
What is prompt injection?
Prompt injection is an attack where hidden or disguised instructions get an AI model to do something its real user never asked for. In an agent, the dangerous version is indirect prompt injection — the instruction isn't typed by an attacker into the chat; it's planted in content the agent reads later, like a web page, an email, or a shared document, and the model can't reliably tell that content apart from a real instruction.
Best for: teams whose agent browses, reads email, or processes documents — grade the exposure with the Indirect Prompt-Injection Exposure Gate.
Prompt injection is the attack every team building an AI agent eventually has to answer for, because it targets the one thing an agent can't avoid doing: reading content it didn't write. This guide covers what prompt injection actually is, how the indirect version hides inside ordinary content, and how to grade whether your agent is exposed before an attacker finds out for you.
Direct vs. indirect prompt injection
There are two versions of this attack, and they matter differently depending on what your agent does.
| Type | Where the instruction comes from | Who's at risk |
|---|---|---|
| Direct | Typed straight into the chat by the user or an attacker with access | Public-facing chatbots without proper output boundaries |
| Indirect | Planted in content the agent reads later — a page, email, or document | Any agent that reads untrusted content on its own |
Indirect prompt injection is the more dangerous version for an agentic system, because the attacker never has to talk to your agent directly. They just have to get their instruction somewhere the agent will read it — a support ticket, a résumé, a product review, a page it's asked to summarize — and wait.
How an indirect prompt injection kill-chain works
- An attacker plants an instruction inside content — hidden in white text on a page, buried in a document's metadata, worded to look like part of the content itself.
- The agent reads that content while doing a normal task, like summarizing a page or answering a question from a document.
- The model can't reliably separate "data to process" from "instructions to follow" — both arrive as the same stream of text.
- The hijacked instruction executes using the agent's own tools and credentials, not the attacker's.
- If nothing catches it, the action completes silently — the user only sees the agent's normal-looking output.
Where indirect prompt injection hides
The content types are ordinary — that's what makes this hard to catch. Web pages an agent browses or summarizes. Emails in a shared inbox. Documents uploaded by a customer. Search results the agent reads through. Comments inside code the agent reviews. Output from a third-party tool the agent calls. Anywhere your agent reads text it didn't generate itself is a place an instruction can hide.
Why traditional input validation doesn't catch it
A web app firewall or an input sanitizer looks for known-bad patterns — SQL syntax, script tags, command strings. A prompt injection is plain language. It doesn't look malicious to a filter; it looks like a paragraph. The problem isn't the words, it's that the model reading them has no built-in wall between "the task" and "the data for the task." That's a design gap, not a missing filter rule, which is why it needs its own gate rather than a patch on existing input validation.
Key insight: the question that actually matters isn't "can an injection exist" — assume it can. It's whether an injection that lands can also act, and whether that action would go uncaught. Gate the chain, not just the entry point.
What a prompt-injection gate does — and doesn't do
What it does
- Grades whether an injection can enter, act, and go uncaught
- Names the one control to fix first in the kill-chain
- Gives a deterministic, repeatable exposure verdict
What it isn't
- Not a content filter or output firewall
- Not a live scan of your running agent
- Not a guarantee no injection will ever land
Prompt injection rarely acts alone. If an injected instruction gets written into an agent's memory, it stops being a one-time event — see AI Agent Memory Poisoning. And a poisoned or untrusted MCP server is one of the most common ways an injection reaches the agent in the first place — see MCP Security.
Grade your agent's injection exposure
The Indirect Prompt-Injection Exposure Gate scores whether a hidden instruction can enter, act, and go uncaught — with the one control to fix first.
Get the Injection Exposure Gate — $79 →If your agent also installs third-party tools, keeps memory, or holds its own credentials, the injection gate is one of four surfaces worth covering together. See the Agentic AI Security pillar and the Agentic AI Security Bundle for all four.
Decision Guide
Gate this now if: your agent browses the web, reads email, processes uploaded documents, or reads output from any tool you don't fully control.
Lower priority if: your agent only responds to typed input from a known, trusted user with no content-reading step.
Best first step: run the Indirect Prompt-Injection Exposure Gate against your actual workflow and fix the first control it names.
FAQ
What is prompt injection?
An attack that gets an AI model to follow a hidden instruction instead of its real user's request — either typed directly at the model or planted in content it reads later.
What's the difference between direct and indirect prompt injection?
Direct injection is typed straight into the chat. Indirect injection is planted in content the agent reads on its own — a page, email, or document — which is the version that matters most for agents.
Can prompt injection steal data or take actions?
Yes, if the hijacked instruction can use the agent's tools or credentials. That's why the gate checks whether an injection can act, not just whether it can enter.
How do I know if my agent is exposed to prompt injection?
Any agent that reads content it didn't generate — web pages, emails, documents, tool output — has some exposure. Grade it with a dedicated exposure gate rather than assuming.
Does output filtering stop prompt injection?
It can catch some obvious cases, but it checks the result after the fact. The stronger fix is grading whether an injection can act and go uncaught in the first place.
Is prompt injection the same as jailbreaking?
No. Jailbreaking tries to get a model to ignore its own safety rules. Prompt injection tries to get an agent to follow an attacker's instructions instead of its real user's — a different goal, often using similar techniques.
What should I do first if my agent reads untrusted content?
Grade the exposure with the Indirect Prompt-Injection Exposure Gate and fix the single control it names before adding more content sources.
The gate this post refers to, drawn from the tool’s own logic. See the tool.