Prompt Injection Protection: Detection, Prevention and Runtime Blocking for AI Agents
Your agent reads untrusted text, then acts. Prompt injection protection sits in that path and blocks the action at execution time, so a poisoned page, ticket or tool response cannot turn your agent against you.
Direct answer
Prompt injection is an attack where instructions hidden in text an LLM reads override the instructions you gave it. It comes in two forms: direct injection, typed straight into the prompt by a user, and indirect injection, buried in a document, web page, support ticket or tool response the agent retrieved by itself. Indirect injection causes most real incidents, because the payload arrives through a source the system already treats as legitimate. Prompt injection cannot be eliminated at the model level, since a model has no reliable way to tell your text from an attacker's text in the same context window. It can be contained at runtime. Agentshield runs layered detection on every untrusted input, then does the part detection alone cannot: it gates the action the injection was trying to cause, so a flagged input is blocked or held rather than merely logged, and every verdict is written to an immutable audit trail.
Inspects untrusted input
Every web page, email, document, and tool output the agent reads is treated as untrusted and scanned for injection before the agent acts on it.
Blocks at execution time
Detection happens inline on the action path, not as a pre-launch eval, so a hijacked instruction is stopped at the moment it would execute.
Covers the full attack set
Instruction override, data exfiltration, jailbreaks, and tool-poisoning patterns are caught, mapped to the OWASP Top 10 for LLM Applications.
How do you detect prompt injection?
You detect prompt injection by inspecting every piece of text a model reads before it acts on it, and scoring that text for instructions that try to override the system prompt, redirect the agent, or exfiltrate data. No single technique catches everything, so production detection layers several approaches and treats all external input, not just the user message, as suspect.
| Detection method | What it catches | Where it falls short |
|---|---|---|
| Heuristics and pattern rules | Known phrasings like "ignore previous instructions" | Trivially reworded or encoded attacks |
| Classifier models | Novel injection framed as legitimate text | False positives on benign edge cases |
| Retrieved-content scanning | Indirect injection hidden in documents and tool output | Needs to run on every source, not just user input |
| Action-level policy | The dangerous tool call the injection triggers | Not detection on its own, it is the enforcement layer |
The last row is the one most tools skip. Detecting the prompt matters, but the thing you actually care about is the action: the email that gets sent, the row that gets deleted, the secret that gets read. Treating detection and enforcement as one control is what turns a score into a defense.
It is worth being blunt about the ceiling here, because vendors in this market rarely are. OpenAI, which defines the attack as happening when "untrusted text or data enters an AI system, and malicious contents in that text or data attempt to override instructions to the AI," also states plainly that "guardrails alone are not foolproof." LangChain puts it as "No security technique is perfect." Anyone promising complete prompt injection detection is selling you a number, not a control. Plan for the detector to miss, and make the miss survivable.
What is the difference between direct and indirect prompt injection?
Direct prompt injection is when a user types malicious instructions straight into the prompt. Indirect prompt injection is when the instructions are hidden in content the agent retrieves on its own, such as a web page, a support ticket, a PDF, a code repository or a tool response. Indirect injection is the more dangerous of the two because the payload arrives through a trusted-looking source, so detection has to run on retrieved content rather than only on the user turn.
The distinction is not academic, and it decides which controls help. A jailbreak is a user trying to make a model misbehave toward themselves, which is largely a content-safety problem. Indirect injection is a third party making your agent misbehave toward you, which is an access-control problem. We separate the two in detail on prompt injection vs jailbreak, and walk through how the payload reaches your agent through its own sources on indirect prompt injection.
One structural gap deserves naming because it surprises teams who believe they are covered. OpenAI documents that "Input guardrails run only for the first agent in the chain. Output guardrails run only for the agent that produces the final output." In a multi-agent workflow with handoffs, the middle of the chain has no guardrail coverage at all, and it is usually the middle of the chain that holds the tools. The consequences are on multi-agent security.
When prompt injection becomes remote code execution
The common mental model is that prompt injection makes a chatbot say something embarrassing. In 2026 the published record says otherwise: in agent products, injection has repeatedly been the first step in a chain that ends with code running on a machine. These are not hypotheticals, they are CVEs with fixed versions.
| Product | What injection led to | Severity |
|---|---|---|
| Cursor, CVE-2026-50548 and CVE-2026-50549, named DuneSlide by Cato AI Labs | Injection arriving through a connected MCP server or a web search result escaped the agent sandbox and wrote arbitrary files outside the workspace under the user's privileges. Cato's summary: "There is no click to fall for and no approval box to ignore" | Both CVSS 9.8 critical. Fixed in Cursor 3.0 |
| Cursor, CVE-2026-26268 | NVD, verbatim: "A malicious agent (ie prompt injection) could write to improperly protected .git settings, including git hooks, which may cause out-of-sandbox RCE next time they are triggered. No user interaction was required as Git executes these commands automatically" | Scored 9.9 by NIST and 8.0 by the CNA. Fixed in Cursor 2.5 |
| MCP tool poisoning, documented by Invariant Labs | Malicious instructions embedded in an MCP tool description, invisible to the user but read by the model as authoritative. The proof of concept exfiltrated the developer's own SSH private key | Not a single CVE. A design property of trusting third-party tool descriptions |
Two lessons follow. First, the injection surface is wherever untrusted text reaches a component that can act, which in practice means repositories, search results, tickets, documents and tool descriptions, not the chat box. Second, and more important for how you spend budget: every one of these was contained by constraining what the agent could reach, not by better detection of the hostile text. That is why we argue for containment over classification, and why the honest version of this page says our own detection will miss things.
Product-specific breakdowns are on Cursor AI security, n8n security for workflow agents holding live credentials, and MCP server security for the tool-description problem.
Prompt injection detection vs prevention
Detection tells you an input is probably malicious. Prevention stops the malicious input from doing anything. Buyers often shop for one and discover in an incident that they needed both, because a detector that raises an alert while the agent goes ahead and acts has not actually protected anything.
| Capability | Detection only | Detection plus prevention (Agentshield) |
|---|---|---|
| Flags suspicious prompts | Yes | Yes |
| Scans retrieved documents and tool output | Sometimes | Yes |
| Blocks the triggered action in real time | No | Yes |
| Holds high-risk actions for human approval | No | Yes |
| Records verdict for audit | Log line | Immutable, attributed record |
If you already run a detection model or an open-source scanner, keep it. Agentshield can sit behind it as the enforcement layer that turns a detection signal into a blocked action, and it also runs its own detection so you are not depending on a single classifier. The enforcement half is described on tool permissions, and the approval pattern on human in the loop AI agents.
What to look for in prompt injection detection tools
Most prompt injection detection tools are libraries or hosted classifiers you call from your own code. That is fine for a research prototype and rarely enough for a production agent, because the agent still has to decide what to do with the score. When you evaluate options, weigh five things.
- Coverage of indirect injection. Direct injection in the chat box is the easy case. The attacks that cause real incidents come from documents, web pages, and tool responses. Make sure detection runs on retrieved content, not just the user turn.
- Enforcement, not just scoring. Ask what happens after a prompt is flagged. If the answer is "you get a score and decide," the tool is a detector, and you still own prevention.
- Latency budget. Detection sits on the request path. It has to be fast enough to run on every input without wrecking response time.
- Framework neutrality. You should not have to rebuild your agent to add detection. A control plane in front of any model and framework beats an SDK you weave through your code.
- Evidence. When something is blocked, you need the input, the verdict, and the rule, kept immutably, so you can explain it to a security reviewer. See agent audit trail.
For the deeper mechanics of the attacks these tools face, see real prompt injection attack examples and the practical controls in how to prevent prompt injection. If you are comparing vendors rather than techniques, our survey of the market is in AI agent security companies.
FAQ
Prompt-injection firewall: common questions.
What is prompt injection?
Prompt injection is an attack where instructions hidden in text an LLM reads override the instructions its developer gave it. OpenAI defines it as happening when untrusted text or data enters an AI system and malicious contents in that text attempt to override instructions to the AI. It works because a model processes your instructions and attacker text in the same context window with no reliable way to tell them apart.
Can prompt injection be prevented?
Not fully at the model level, because an LLM cannot reliably separate instructions from data in the text it reads. It can be contained at runtime. You detect injection in every input, then constrain what the agent is allowed to do so that even a successful injection cannot trigger a harmful action. That combination of detection plus least-privilege enforcement is what prevention means in practice.
What is the difference between direct and indirect prompt injection?
Direct prompt injection is when a user types malicious instructions straight into the prompt. Indirect prompt injection is when the instructions are hidden in content the agent retrieves on its own, such as a web page, a support ticket, a PDF, or a tool response. Indirect injection is more dangerous because the payload arrives through a trusted-looking source, so detection has to run on retrieved content, not just user input.
How do you detect prompt injection?
Layer several methods and run them on every untrusted input rather than only the user message. Pattern rules catch known phrasings, classifier models catch novel injection framed as legitimate text, and retrieved-content scanning catches payloads inside documents and tool output. Then add action-level policy, which is not detection but is what stops the tool call the injection was written to trigger.
What is the best prompt injection detection tool?
It depends on whether you need a detector or a defense. Open-source scanners and hosted classifiers are good at labeling suspicious text. A runtime firewall adds the enforcement layer, blocking or holding the action a detected injection tries to cause and recording it for audit. Teams shipping agents that take real actions generally need enforcement, not just a score.
Can prompt injection lead to remote code execution?
Yes, and it has. Three critical CVEs published against Cursor in 2026 all started as prompt injection and ended with code running outside the sandbox, two of them scored CVSS 9.8 with no user interaction required. Injection arriving through an MCP server or a web search result was enough. Patching fixed those, but the pattern generalizes to any agent that can execute commands.
Does prompt injection detection slow down my agent?
Well-built detection adds a small, fixed cost on the request path, typically a few milliseconds to tens of milliseconds depending on how many layers run. The bigger latency risk is holding an action for human approval, which is a deliberate trade you apply only to high-risk actions. Low-risk actions clear automatically, so most requests see negligible overhead.
Do guardrails stop prompt injection?
They reduce it and they do not stop it. OpenAI states that guardrails alone are not foolproof, and that input guardrails run only for the first agent in a chain while output guardrails run only for the agent producing the final output. In a multi-agent workflow the middle of the chain, which usually holds the tools, has no guardrail coverage at all.
Where it is used
Prompt-injection firewall in the field.
Snowflake Cortex agent security
Snowflake built a real guardrail layer for Cortex Agents and turned it on with one account setting. The gap that matters is narrow and specific: an agent inherits the privileges of the person who called it, and no role grant can express whether the action it just proposed should happen.
Read more →Gemini Enterprise security
Gemini Enterprise ships more platform security than most teams switch on. The gap is narrower than the internet suggests, and it sits in one place: deciding whether an agent should be allowed to take the action it just proposed.
Read more →Bedrock AgentCore security
AgentCore gives you microVM isolation, agent identity and Cedar policy on the gateway. What it does not do, in AWS own words, is inspect what a prompt means or constrain how an agent behaves once it is inside.
Read more →Azure AI Foundry security
Microsoft Foundry, still searched for as Azure AI Foundry, ships more platform security than most teams use. The gap is not the platform. It is the row in Microsoft own responsibility matrix that never moves off your side of the table.
Read more →The rest of the plane