How to contain prompt injection in AI agents
You cannot filter prompt injection away. Here are the containment patterns, least privilege, bounded credentials, output validation, and halt conditions, that limit the blast radius when an injection lands.
The way to defend an AI agent against prompt injection is to contain it, not to filter it out, because filtering fails and containment holds. Prompt injection is not a bug you patch once; it is a property of how language models read text, so the realistic goal is not a perfect filter but a small blast radius when an injection lands. That reframing is the whole strategy: assume an injection will get through, and make sure it cannot do much when it does. The stakes are real because agents now take actions, not just produce text. When an agentic tool has real system access, a prompt injection can become remote code execution, as the Langflow agentic-workflow platform showed with an unauthenticated RCE flaw that carried a critical 9.8 severity score and landed in the US government’s catalog of actively exploited vulnerabilities (CVE-2025-3248, NVD1). I build agent security and containment tooling at RankShield, and the teams that get breached are almost always the ones who tried to filter injection away and trusted the filter. What most guidance leaves out is a defense-in-depth playbook for agents that take actions: least privilege, bounded credentials, output validation, and halt conditions, keyed to the failure the filter cannot stop. That is what this covers. One honest note: prompt injection is not solved, and anyone selling you a filter that eliminates it is selling you a false sense of security. What containment does is turn a landed injection into a contained event instead of a breach.
What is prompt injection, and why can’t you filter it out?
Prompt injection is when untrusted content the agent reads, a web page, an email, a document, a tool result, contains instructions that the model follows as if they came from you. You cannot reliably filter it out because the model processes instructions and data through the same channel: to the model, the malicious instruction in a web page looks like just more text to act on. There is no syntactic marker that separates trusted commands from untrusted content, so a filter that tries to catch injection is guessing, and attackers iterate faster than the guesser.
Indirect prompt injection makes this worse, because the attacker never talks to your agent directly. They plant instructions somewhere the agent will read, a README, a support ticket, a page the agent browses, and wait for the agent to ingest them. That is exactly how the vulnerabilities in Anthropic’s own Git MCP server were exploitable: through a poisoned README or issue, with no direct access to the victim’s system. When the attack surface is any content your agent reads, a content filter is defending an unbounded perimeter.
The reason this matters more every month is that agents are proliferating. Akamai reported that agentic AI traffic grew 7,851% year over year (Akamai4), so the number of agents reading untrusted content, and the number of ways an injection can reach one, is climbing steeply. The defensible response is not a better filter; it is containment, so a landed injection cannot cause harm.
What is the lethal trifecta?
The lethal trifecta, a term coined by security researchers to describe the dangerous combination, is an AI agent that has all three of: access to untrusted input, access to sensitive data or powerful tools, and a way to send information out. Any single one of these is manageable; all three together are what let a prompt injection become a real breach, because the attacker can inject instructions, reach something valuable, and exfiltrate it. The practical value of the trifecta is that it tells you exactly what to break.
Break any one leg and the injection loses its teeth. If an agent handling untrusted web content has no access to your secrets, an injection has nothing to steal. If an agent with database access never reads untrusted input, there is nothing to inject. If an agent can read untrusted input and reach sensitive data but cannot send anything to an external destination, the exfiltration path is closed. Designing your agents so no single agent holds all three legs is the highest-leverage containment decision you can make.
This is why architecture beats filtering. Instead of trying to sanitize every input to an all-powerful agent, split responsibilities so the agent that reads untrusted content is not the agent that holds credentials, and gate any outbound action. If you want that separation enforced with verifiable identity and bounded access per agent, that is what RankShield’s agent security layer is built to provide, so the trifecta is broken by design rather than by a filter you have to trust.
How do you contain an injection instead of preventing it?
You contain an injection by assuming it will land and layering controls that limit what it can do: least privilege on tools, bounded and time-limited credentials, validation of tool outputs before the agent acts on them, and halt-and-escalate conditions on consequential actions. Each layer is independent, so an injection that slips past one still meets the next. This is defense in depth applied to agents, and it is the opposite of betting everything on a single filter.
The containment layers below stack from the outside in. Input handling comes first: treat everything the agent reads as untrusted and never let raw untrusted content carry authority. Then privilege: scope each tool narrowly so the agent can only reach what its task requires. Then credentials: issue short-lived, tightly scoped tokens so a stolen credential expires fast and reaches little. Then output validation: check tool results before acting on them. Then halt conditions: require human confirmation or an escalation for anything consequential or hard to reverse.
The point of layering is that no single control has to be perfect. A filter has to be right every time or it fails; containment only needs enough layers that an injection cannot pass all of them and still cause harm. That is a far more achievable engineering target, and it is why the teams that contain injection sleep better than the teams still tuning a filter.
How does least privilege limit an agent’s blast radius?
Least privilege limits blast radius by ensuring an agent can only reach the specific resources its task requires, so a successful injection can only misuse that narrow set, not your whole environment. An agent that can read one mailbox cannot be steered into reading all of them; an agent that can query one table cannot be turned loose on the database. The size of what an injection can do is exactly the size of what you granted the agent, which is why over-permissioning is the single biggest amplifier of agent risk.
The Langflow case shows what over-broad access enables. Because the platform exposed an unauthenticated endpoint that executed user-supplied code, an attacker could achieve full remote code execution, a maximal blast radius, which is why it scored 9.8 and was added to the US catalog of actively exploited vulnerabilities (Horizon32). The lesson is not specific to Langflow: any agent or tool that can execute broadly is a maximal-blast-radius target, and narrowing what it can reach is the most effective single containment control.
Apply it by cutting tools you do not need and scoping the ones you keep. Every tool an agent can call is attack surface, so an agent offered ten tools when it uses three has seven unnecessary ways to be misused. Constrain arguments, allow-list operations, and separate high-privilege actions behind explicit gates. The goal is that even a fully successful injection finds a small, bounded set of things it can touch.
When should a human be in the loop?
Put a human in the loop for actions that are high-impact or hard to reverse: moving money, deleting data, sending external communications, changing access or configuration. For low-impact, easily reversible actions, let the agent run freely, because slowing everything down destroys the value of automation and trains people to rubber-stamp. The skill is drawing the line by consequence, not by discomfort, so the human is a meaningful check exactly where a mistake or an injection would hurt most.
Human-in-the-loop is a containment layer, not a filter, and that distinction matters. You are not asking the human to detect the injection; you are asking them to confirm a consequential action before it happens, which catches the injection’s effect even when no one spotted its cause. The confirmation should show what the agent is about to do in plain terms, so the reviewer is approving an action, not a prompt they cannot evaluate.
Make the gate reversible and evidenced. When a human approves or denies a consequential action, seal that decision as a tamper-evident record, so you can later prove what was authorized and by whom. That record is what turns a contained incident into an auditable one, and it is the difference between "we think it was fine" and "here is the proof of what the agent was allowed to do."
How do you validate tool outputs and set halt conditions?
Validate tool outputs by treating what a tool returns as untrusted input in its own right, because a tool result can carry an injection just as a web page can. Before the agent acts on a tool’s output, check it against what the workflow expects: the right shape, the right scope, no embedded instructions. An agent that blindly chains on whatever a tool returns has extended the injection surface to every tool it calls, so output validation closes a gap that input handling alone misses.
Set halt conditions on the signals that indicate something has gone wrong: an action outside the agent’s normal pattern, an argument no legitimate workflow would produce, a tool result that fails validation, or a consequential action reached without the expected approval. When a halt condition triggers, the agent should stop and escalate rather than proceed, because a halted agent is a contained agent. The MCP ecosystem’s exposure, roughly 200,000 instances found open with 38% lacking authentication (Infosecurity Magazine3), is a reminder that many agents run with no stopping mechanism at all.
Together, output validation and halt conditions are the inner containment layers, the ones that catch an injection that already passed input handling and privilege limits. They are also the layers most teams skip, because they require thinking about failure rather than function. Building them in is what lets you say honestly that a landed injection would be caught and contained, not just hopefully filtered before it arrived.
Is prompt injection solvable?
Prompt injection is not solved, and treating it as solvable is the mistake that leads to breaches. There is no known general filter that reliably separates trusted instructions from untrusted content, because the model reads both through the same channel, so anyone claiming to have eliminated prompt injection is overstating what is possible today. The honest framing is that injection is a durable property of how agents work, and the engineering goal is containment, not a cure.
That is not a counsel of despair; it is a counsel of design. The same way we do not eliminate the possibility of a stolen password but contain it with least privilege, short sessions, and monitoring, we contain prompt injection with the layers in this guide. A well-contained agent can read untrusted content all day and still not cause harm, because no single injection can acquire the untrusted input, the sensitive access, and the exfiltration path at once.
So the answer to "is it solvable" is: not with a filter, but yes with architecture. Break the lethal trifecta, scope privileges tightly, bound credentials, validate outputs, and halt on consequential actions. Do that, and you have not solved prompt injection, you have made it not matter, which is the outcome that actually protects your systems. If you want those controls enforced and evidenced per agent, that is what RankShield is built to do.
How do you keep agents safe as they take on more?
Stop trying to filter prompt injection and start containing it, because containment is the control that actually holds. Assume an injection will land, then make sure it cannot do much: break the lethal trifecta so no single agent reads untrusted input, holds sensitive access, and can send data out. Scope tools to least privilege, issue bounded and time-limited credentials, validate tool outputs before acting on them, and halt on consequential actions for human confirmation. Each layer is independent, so an injection that passes one still meets the next.
The Langflow case is the warning to keep in mind: when an agentic platform gave untrusted input a path to code execution, the result was a critical, actively exploited vulnerability. As your agents take on more, the answer is not a smarter filter but a smaller blast radius. If you want the lethal trifecta broken by design, with bounded access and a verifiable record per agent, see how RankShield secures AI agents so a landed injection stays contained.
Questions, answered.
Can prompt injection be prevented completely?
No. There is no known general filter that reliably separates trusted instructions from untrusted content, because a language model reads both through the same channel, so a malicious instruction in a web page looks to the model like ordinary text to act on. Anyone claiming to have eliminated prompt injection is overstating what is currently possible. The realistic and effective goal is containment: assume an injection will land and layer controls, least privilege, bounded credentials, output validation, and halt conditions, so it cannot cause harm. A well-contained agent can read untrusted content all day without it becoming a breach, which is a far stronger security position than trusting a filter that has to be right every single time.
What is the lethal trifecta?
The lethal trifecta is a term coined by security researchers for the dangerous combination that lets a prompt injection become a real breach: an AI agent that has access to untrusted input, access to sensitive data or powerful tools, and a way to send information out. Any one of these alone is manageable; all three together are what allow an attacker to inject instructions, reach something valuable, and exfiltrate it. The practical value is that it tells you what to break. If you design your agents so no single agent holds all three legs, for example by separating the agent that reads untrusted content from the agent that holds credentials, a prompt injection has no complete path to harm.
What is indirect prompt injection?
Indirect prompt injection is when an attacker plants malicious instructions in content the agent will read later, rather than typing them to the agent directly. The attacker poisons a source, a web page, a README, a support ticket, a document, and waits for the agent to ingest it during a normal task. Because the agent treats that content as data to act on, the hidden instructions can steer it. This is more dangerous than direct injection because the attacker never needs access to your systems; they only need to influence something your agent reads. It is exactly how the vulnerabilities in Anthropic’s Git MCP server were exploitable, through a poisoned README or issue, which is why treating every input as untrusted is the first containment layer.
How do I limit an AI agent’s blast radius?
Limit blast radius with least privilege: grant each agent access only to the specific resources its task requires, so a successful injection can only misuse that narrow set rather than your whole environment. Cut tools the agent does not need, since every tool is attack surface, and scope the ones you keep by constraining arguments and allow-listing operations. Pair that with short-lived, tightly scoped credentials so a stolen token expires quickly and reaches little, and gate high-impact or hard-to-reverse actions behind human confirmation. The size of what an injection can do is exactly the size of what you granted the agent, which is why over-permissioning is the single biggest amplifier of agent risk and narrowing access is the most effective containment control.
Do guardrails stop prompt injection?
Natural-language guardrails, instructions telling the model not to follow injected commands, help at the margins but do not stop prompt injection, because they rely on the same model that the injection is manipulating. An attacker can often craft input that overrides or talks around a guardrail, so treating guardrails as your primary defense is the mistake that leads to breaches. Guardrails are worth having as one thin layer, but the controls that actually contain injection are structural: breaking the lethal trifecta, least-privilege tools, bounded credentials, output validation, and halt conditions on consequential actions. Those work regardless of what the model can be talked into, because they limit what a manipulated agent is able to reach and do rather than trying to change its mind.
Are agentic platforms like Langflow safe to use?
Agentic platforms are useful but must be secured like any system that executes actions, because giving an agent tools turns prompt injection into potential real-world impact. Langflow, a popular agentic-workflow builder, carried an unauthenticated remote-code-execution vulnerability (CVE-2025-3248) that scored a critical 9.8 and was added to the US government’s catalog of actively exploited vulnerabilities, a reminder that an agent’s tools are the real attack surface. Using these platforms safely means keeping them patched, never exposing agent endpoints without authentication, scoping what each agent can reach, and applying the same containment layers, least privilege, bounded credentials, output validation, and halt conditions, that you would apply to any agent that can take consequential actions.
References
- NVD. CVE-2025-3248: Langflow unauthenticated remote code execution (CVSS 9.8; agentic-workflow builder; added to CISA Known Exploited Vulnerabilities catalog).
- Horizon3. Unsafe at any speed: abusing Python exec for unauthenticated RCE in Langflow AI.
- Infosecurity Magazine (OX Security disclosure). ~200,000 exposed MCP instances; 38% of scanned servers had no authentication.
- Akamai (via GlobeNewswire). Agentic AI traffic grew 7,851% year over year in 2026.
Jamie Kloncz
Founder & CEO, RankShield
Jamie Kloncz is the founder and CEO of RankShield, the verifiable AI and quantum security platform. He started the company after two attacks landed in a single week: his phone was cloned, and his business was hit by a click-fraud campaign. One targeted him as a person, the other his livelihood, and no single tool defended both. That experience, together with surviving an AI voice-clone scam, shaped RankShield’s core belief: the threats of the AI age are personal first, and trust should be something you can check, not just extend.
Make every AI action provable.
RankShield is the verifiable, quantum-safe AI security platform — protection you can check, not just trust.