Prompt injection sits at number one on OWASP’s Top 10 for Agentic Applications. What makes that worth your attention is the combination behind it: agentic applications now join authenticated access, untrusted content ingestion, and the ability to act inside a single system.
This is a strategic risk discussion. By the end you’ll hold one mental model you can apply before exposing anything as part of the agent-ready web: indirect prompt injection, through to the lethal trifecta, exposure mapping, and deterministic-first controls. The industry is standardising before the risks are settled.
Why is prompt injection ranked the top OWASP risk, and how does indirect prompt injection work against browser agents?
OWASP ranks prompt injection first because it is foundational: it maps to six of the ten categories. Indirect prompt injection never touches the prompt. Attackers plant instructions in content the agent ingests, and browser agents are the most exposed class because every page they read becomes an untrusted instruction channel the model cannot separate from data.
The root is architectural. An LLM processes the system prompt, your request, and retrieved text as one undifferentiated token stream, so you can’t parameterise natural language the way you parameterise a SQL query, and the flaw cannot simply be fixed. Direct injection needs the attacker to reach the prompt; indirect injection rides through a page the agent browses or a document it summarises, and that untrusted content becomes an instruction source the agent is built to trust.
WebMCP compounds this: it gives in-browser agents structured tools to act on, so injection becomes an action problem. Zscaler ThreatLabz documented two in-the-wild campaigns, a fake-API payment scam and a typosquatted DeBank page, both hiding instructions in JSON-LD and CSS.
The gap between a number one ranking and a thin breach list is a warning period, a detection-and-reporting lag. One contested datapoint, a third-party evaluation of Opus 5 in Auto Mode, claims a 0.00% indirect prompt-injection success rate; treat that figure as contested. The ranking is a symptom; the conditions that turn a single injection into exfiltration come next.
What is the “lethal trifecta” for AI agents, and why does it matter?
The lethal trifecta, coined by Simon Willison, describes an agent that simultaneously has access to private data, exposure to untrusted content, and the ability to act externally. Any agent holding all three can be turned into an exfiltration tool by one injected prompt. Remove any leg and the exfiltration risk collapses, so containment is the realistic strategy.
The legs only become dangerous together. A single injected instruction weaponises all three at once, converting the agent into a channel for data exfiltration that can leave invisibly, through an image URL, a Markdown link, or a DNS query. Meta’s Agents Rule of Two restates it as a limit: satisfy at most two of untrusted input, sensitive access, and external action, or add a human in the loop.
You can map each leg onto browser-agent capabilities: a logged-in session is the private-data leg, page content and retrieved documents are the untrusted-input leg, and tool calls and form submissions are the action leg. In a WebMCP context the agent runs inside your authenticated session, which is why the guidance centres on authenticated state. The framing moves you to managing the conditions that make it capable of harm: the same permissions that make an agent useful are the ones that make it exploitable, an access-control contradiction between capability and control.
The trifecta is what you audit when you expose an application as a tool.
How do you evaluate the security and privacy risks of exposing your application as agent tools?
Treat readiness as a risk review. You are mapping three things: what data an exposed tool can reach, what untrusted content flows into the agent, and what actions become reachable the moment you declare a tool. Then you ask where persistence creeps in, and you restrict whatever the map shows you can’t justify exposing.
WebMCP makes this concrete: every declared tool is an action surface, and every page an agent reads is an untrusted input channel. Memory poisoning writes a malicious item into an agent’s long-term context, so the compromise outlives the session that introduced it and the agent later trusts the planted item.
Tool supply-chain compromise injects risk through the dependencies your agent trusts. The LiteLLM PyPI backdoor was downloaded nearly 47,000 times in three hours, and your own tools usually mean third-party libraries and SDKs. Agents are also a new traffic source, so the traffic your business is now exposing carries security obligations alongside cost. The point is a decision: which capabilities to restrict, which to leave autonomous, and which to gate behind human approval.
Deterministic controls versus probabilistic controls: which should lead?
Deterministic controls, sandboxing and least privilege, should lead, because they constrain what a hijacked agent can touch regardless of what the model does. Detection is a useful complement but can be routed around. Human-in-the-loop approval is the escape hatch for consequential or irreversible actions.
Start from an assume-breach position: treat the LLM layer as already compromised, and rely on the controls that operate outside it. Least privilege scopes what an agent is authorised to touch, and sandboxing isolates where it can operate. Their value is that they sit outside the model’s reasoning loop.
Probabilistic controls belong in second place. Injection classifiers and critics add useful signal, but a meta-analysis of 78 studies put adaptive attack success rates above 85% against state-of-the-art defences. Detection buys time and visibility; it does not set the boundary.
Human approval is for the irreversible. Auto-approve the safe and frequent, and put a person in front of the rare and consequential, because approval fatigue is real. Human-in-the-loop fits actions that are high-impact, hard to reverse, or legally consequential, and pairing it with memory-write logging stops a contained compromise from persisting. That step is consent as the last line of defence.
Containment as the baseline
The number one ranking is a warning about conditions, and the lethal trifecta makes those conditions explicit. You can act on them directly by designing each agent so it never holds private data, untrusted content exposure, and external action at the same time.
Readiness then becomes an exposure map of what data, inputs, and actions become reachable. The controls that should lead are the deterministic ones, sandboxing and least privilege, with probabilistic detection as a complement and human approval reserved for the irreversible.
The end state is containment, a posture you can adopt before exposing any application as part of the agent-ready web. Securing agent access is the broader discipline: the defaults have not calcified yet, so moving early makes blast-radius containment the expected baseline.
Frequently Asked Questions
Is prompt injection the same as jailbreaking?
No. Jailbreaking aims to bypass a model’s own safety guardrails, while prompt injection aims to hijack an application’s instructions, and the real target is your agent’s privileges rather than the model’s behaviour. Jailbreaks usually affect output; injection affects action. A model can resist every jailbreak and still be injected through a poisoned web page, because the instruction arrives disguised as trusted content.
Can’t I just filter or sanitise the content my agent reads?
Filtering helps but will not settle the problem, because indirect injection hides instructions in perfectly ordinary content, including structured data like JSON-LD and styling like CSS. There is no reliable signature to strip, and adaptive attackers tune payloads to slip past static filters. Treat filtering as one useful layer, not as the control that contains the risk.
Isn’t prompt injection something the model providers will eventually fix?
Unlikely to be fixed outright, because the flaw is architectural. A model processes system prompts, user requests, and retrieved content as one undifferentiated token stream, so it cannot reliably separate trusted instructions from untrusted data. Better models reduce some attacks but not the underlying confusion. That is why the sound strategy leans on containment rather than waiting for a patch.
What happens if an agent reads untrusted content but holds no private data?
The risk drops sharply. Without the private-data leg, a successful injection can still waste compute, post unwanted content, or trigger nuisance actions, but it cannot exfiltrate what the agent never had access to. This is the practical payoff of the trifecta: removing one leg does not make the agent invulnerable, it makes the worst outcome recoverable.
How do I tell whether my agent sits inside the lethal trifecta?
Answer three questions honestly. Does the agent hold credentials or reach private data? Does it ingest content you do not control? Can it act or communicate beyond your environment? Three yeses means it sits inside the trifecta. Two or fewer means you already have a leg to remove, which is usually the cheapest security work available.
Can I keep an agent useful if I remove a leg of the trifecta?
Usually yes, and the trick is scoping rather than disabling. A research agent can read the open web in one context and reach your private data in another, with no shared session linking the two. Narrow tools, short-lived credentials, and one-task-one-authority designs let the agent stay capable while ensuring no single run holds all three properties.
What does memory poisoning actually look like, and how long does it last?
Memory poisoning is when a malicious instruction is written into an agent’s long-term context, so the compromise outlives the session that introduced it. The agent may then trust the planted item in later runs, quietly steering actions weeks afterwards. It matters because it breaks the assumption that closing a session resets the risk, which is why containment must extend across sessions.
Do I need to worry about tool supply-chain compromise if I only use my own tools?
Possibly, because your own tools usually mean tools wired to third-party libraries, SDKs, and services. A compromised dependency can inject risk through a surface your agent has been told to trust, bypassing the injection question entirely by attacking the tool itself. Inventory what your tools depend on, and apply least privilege to the credentials each one carries.
Is human-in-the-loop approval practical, or does it cancel out the point of automation?
It is practical if you reserve it for the irreversible. Approving every action destroys the value of an agent, but gating the handful of consequential ones (a payment, a deletion, a message sent to a customer) caps the blast radius at almost no cost. Let routine reads and reversible steps run unattended; put a human in front of what cannot be undone.
Should I just block all AI agents from my site to stay safe?
Blocking is a blunt instrument that trades a manageable, mapped risk for lost relevance. If you serve users who want agents to act on their behalf, refusing them hands the traffic to competitors while doing nothing about the agents you do not control. The stronger move is to expose a narrow, intended surface and map the exposure it creates.
What is the difference between sandboxing and least privilege?
They are complementary deterministic controls. Least privilege scopes what an agent is authorised to touch, so a hijacked run cannot exceed its task’s authority. Sandboxing isolates where it can operate, containing process, filesystem, and network reach. Least privilege limits what the agent may do; sandboxing limits where it may do it. Together they cap damage without depending on the model behaving.
Are detection tools like injection classifiers worth using at all?
Worth using as a complement, not as a boundary. Classifiers catch known patterns and add useful signal, but adaptive red-team studies achieved near-total bypass against static defences, so a detection layer alone will eventually be routed around. Run them to buy time and improve visibility, while letting sandboxing and least privilege, not detection, set the limit on what a hijacked agent can reach.
