Why you can't filter your way out of prompt injection

You have probably been reassured at some point that your AI tool screens for malicious instructions. Something scans the web page, the email, the uploaded PDF, and blocks anything that looks like an attempt to hijack the assistant. It sounds like the right shape of defence. It is also the one that fails quietly, because the thing doing the scanning has a narrower job than the thing it is protecting, and that gap is where the attacks live.

That is not a complaint about any particular product. NIST’s January 2024 announcement of its taxonomy of attacks on AI systems said it plainly: there is no foolproof way as yet to protect AI from misdirection, and the available defences currently lack robust assurances that they fully mitigate the risks [2]. OWASP’s entry for prompt injection says the same, that given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention [1]. This guide is for people running a small business or working alone who have connected an assistant to their email, files, calendar or browser, and who want to know what actually reduces the risk. If you are securing a product that handles other people’s data at scale, this is the wrong document; you want threat modelling and the vendor security documentation directly.

The scanner is always weaker than the model it guards

An injection filter is a smaller model, or a set of rules, sitting in front of the assistant and reading everything the assistant is about to read. For browser use, Anthropic says it scans all untrusted content that enters the model’s context window and flags potential prompt injections with classifiers, detecting adversarial commands embedded in hidden text, manipulated images and deceptive interface elements [4]. OpenAI says it has developed multiple automated AI-powered monitors to identify and block prompt injection attacks [5]. Google describes input and output checks like classifiers as one layer inside a defence-in-depth approach that also includes model hardening and system-level guardrails [3]. These are real controls, and nothing here is an argument for switching them off.

They also share one structural weakness. The filter has to decide cheaply, in advance, whether a piece of content contains an instruction. The assistant behind it is a general-purpose interpreter that will read almost anything: an obscure language, an encoding, text rendered inside an image, two harmless-looking documents that only mean something when read together. Every gap in capability between the guard and the thing it guards is a gap an attacker can aim at. The filter is playing a blocklist game against a set of possible disguises with no upper bound, and it has to win every time.

The framing that makes this concrete for a non-specialist comes from Simon Willison, who points out that guardrail products almost always carry confident claims that they capture 95% of attacks or similar, and that in web application security 95% is very much a failing grade [8]. A spam filter at 95% is fine, because the cost of the 5% is an irritating email. An injection filter at 95% is not fine, because the cost of the 5% is somebody else briefly driving your assistant, with your access, on your account.

Adaptive attackers beat static defences

The strongest public evidence is Google DeepMind’s, which tested published defences against attackers that adapt rather than attackers running a fixed script. Its finding: successful baseline defences like Spotlighting or Self-reflection became much less effective against adaptive attacks learning how to deal with and bypass static defence approaches [3]. Both of those sit in the category Google labels prompt modifications applied in context, meaning they change what the model is told rather than what the model is [3]. That is the pattern. A defence that works by wording works against an attacker who does not know the wording, and the defences a commercial product ships are rarely secret; every vendor page cited in this guide describes its own [3][4][5].

Training the model itself to resist is more durable than bolting a scanner on the front, and it is where the labs are spending. Google reports that model hardening has significantly boosted Gemini’s ability to identify and ignore injected instructions, lowering its attack success rate, then adds that even with model hardening, no model is completely immune [3]. Anthropic’s November 2025 write-up on browser use says Claude Opus 4.5 sets a new standard in robustness to prompt injections, measured against an adaptive attacker given 100 attempts per environment, and then states the result without spin: a 1% attack success rate, while a significant improvement, still represents meaningful risk, no browser agent is immune to prompt injection, and the findings are shared to demonstrate progress rather than to claim the problem is solved [4]. OpenAI calls prompt injection a frontier, challenging research problem, and notes that robustness to adversarial attacks is a long-standing challenge for machine learning and AI, making this a hard, open problem [5].

Read those three together. The organisations with the strongest commercial reason to call this solved are all saying, in their own published material, that it is not. The number is going down. It is not going to zero, and you should not build anything on the assumption that it will.

Three conditions have to line up before an injection costs you anything

An injection on its own is just text that made an assistant behave oddly. It turns into a loss when three things are true at the same time. Willison’s shorthand is the lethal trifecta: the assistant has access to your private data, it is exposed to untrusted content, and it has the ability to externally communicate [8]. The underlying reason it works is that models do not just follow your instructions; they will happily follow any instructions that make it to the model, whether or not they came from their operator or from some other source [8].

Remove one leg and the attack has nowhere to land. An assistant summarising a public web page with no access to your files has untrusted content and an outbound path, but nothing worth stealing; the worst case is that it lies to you, which matters, but nothing leaves. An assistant reading a folder of documents you wrote yourself has private data and an outbound path, but no attacker input. An assistant with your inbox and the open web, but no ability to send, fetch a URL or write anywhere, can be fully hijacked and still achieve nothing.

The third leg is the one people leave open without noticing, because outbound paths do not look like outbound paths. A tool that fetches a URL is an outbound path. An assistant that renders an image from an address it chooses is an outbound path. A workflow step that sends a summary email, posts to a channel, updates a shared document or writes a row to a database an attacker can read is an outbound path. When you audit your setup, list every way data can leave, not every way it can be sent on purpose.

Set permissions to the worst outcome you can absorb

The defence that survives a novel attack is the one that does not depend on recognising the attack. You stop asking whether an input is trustworthy and start asking what happens if the assistant does the worst thing its permissions allow. Then you make that answer small. OWASP puts the same idea in its mitigation list as privilege control: restrict the model’s access privileges to the minimum necessary for its intended operations, and handle extensible functionality in code rather than providing it to the model [1].

Claude Code is a useful worked example because the controls are documented and adjustable. In Manual mode it starts with read-only permissions and asks before it edits files, runs tests or executes commands that modify your system [7]. Commands that fetch content from the web such as curl and wget are not auto-approved by default, and to block them entirely you add them to the deny rules [7]. Web fetch uses a separate context window to avoid injecting potentially malicious prompts [7]. Bash commands can be sandboxed with filesystem and network isolation [7]. In Anthropic-hosted cloud sessions, network access is limited by default and can be configured to be disabled or to allow only specific domains [7]. Every one of those is a limit on the action, not a judgement about the input, which is why each of them holds against an attack nobody has seen yet.

The same reasoning applies to accounts. Give an assistant its own credential rather than yours, scoped to the folder, mailbox or project it needs, and keep the credential that reads separate from the credential that acts. OWASP’s version of this is to provide the application with its own API tokens for extensible functionality [1]. The Claude Code documentation is blunt about where responsibility sits: it only has the permissions you grant it, and you are responsible for reviewing proposed code and commands for safety before approval [7].

Approval belongs on the irreversible step

Human-in-the-loop control for privileged operations is on OWASP’s mitigation list, and it is the control most people implement badly [1]. Put a confirmation on everything and you train yourself to click through them, which is worse than having none, because you now believe you are checking. This is a recognised failure mode rather than a personal weakness: Claude Code’s documentation lists prompt fatigue mitigation as a built-in protection, implemented by allowlisting frequently used safe commands per user, per codebase or per organisation [7]. Put confirmations only where the action cannot be undone and the volume stays low enough that you actually read them.

The short list of actions worth stopping for is money leaving an account, messages going to people who are not you, anything deleted, anything published, and anyone granted access. Everything else can usually run unattended, because the cost of a mistake is a redo.

This matters most in automation platforms, because a scenario runs whether or not you are watching. If you have flows in Zapier, n8n or Make that read incoming email, scrape pages or ingest form submissions, then feed that text into a model step, the model is reading attacker-controlled content by definition. Ask what the rest of that flow can do without you: which credential it holds, whether it can send as you, and whether any step writes somewhere the sender can later read. A pause-for-approval step before the sending step costs seconds and removes the entire exfiltration path.

Run that with your own numbers before you decide approvals are too annoying. Six a day at 20 seconds each is under an hour a month, which is a low price for the only class of defence that does not fail when the attack is new.

The strongest controls vendors ship are switches, not filters

Watch what the labs build rather than what they say. OpenAI introduced Lockdown Mode for ChatGPT in February 2026 and updated it in June, and when enabled it limits or turns off certain features that connect ChatGPT to the web or external services, including live web access, image support in responses, Deep Research including shopping research, Agent Mode, Canvas networking, live connectors and file downloads [6]. The stated reason is exactly the argument of this guide: it reduces the ways prompt-injection-style attacks could cause information to be shared outside the conversation [6]. Alongside it came a standardised Elevated Risk label, applied to a short list of existing capabilities across ChatGPT, ChatGPT Atlas and Codex so that users receive the same guidance wherever they encounter them [6]. OpenAI’s security write-up lists sandboxing, approval before certain links can be visited, a Watch Mode that alerts you when the agent is operating on sensitive sites, and an Atlas logged-out mode that lets the agent start tasks without being logged in to sites, in the same breath as its monitors [5].

None of those is a better scanner. Every one of them is a capability being taken away, or a human being inserted, on the theory that the model may be following someone else’s instructions. That is the vendors telling you where they think the real defence lives.

Practically, the version of this you can do today is boring and effective. Do not run a browser agent in a session where you are logged into your bank. Use a separate browser profile, or the logged-out mode, for anything that reads untrusted pages. Turn connectors off when a task does not need them rather than leaving everything wired up permanently. Treat the switch as the control and the filter as a bonus.

What still goes wrong

The honest limit is that removing a leg of the trifecta removes capability, and the capability is why you connected the tool. An assistant that cannot send email is safer and less useful, and every configuration below the maximum is a trade you are making on purpose. Willison’s own conclusion is uncomfortable for exactly this reason: the vendors are not going to save you, and avoiding the combination is left to the person who assembled the tools [8]. If you are the one wiring your own connectors together, that is you. There is no setting that gives you the full capability safely, and anyone selling you one is selling a filter.

Convenience erodes these controls over time. Claude Code documents an auto mode in which a separate classifier model reviews actions instead of you and blocks the ones it judges unsafe, which is a reasonable trade for speed and is also, structurally, a filter [7]. The documentation is straight about the ceiling: while these protections significantly reduce risk, no system is completely immune to all attacks [7]. Whatever you configure this month, check in three months whether you have quietly allowlisted your way back to where you started.

And the underlying problem may not be fixable on any schedule you can plan around. NIST’s assessment was that there are theoretical problems with securing AI algorithms that simply have not been solved yet [2]. Anthropic notes that human security researchers consistently outperform automated systems at discovering creative attack vectors, which is another way of saying that new categories of attack keep arriving from directions nobody had modelled [4]. Filtering is still worth having, and it sits in OWASP’s mitigation list alongside privilege control, output validation and human approval [1]. Just never let it be the reason you granted an assistant more access than you could afford to lose.

Prompts from this guide

agent-blast-radius-audit

I am going to describe an AI assistant or automation I have set up.
Audit it for prompt-injection blast radius. Do not tell me how to
detect malicious inputs; assume the assistant will at some point
follow an attacker's instructions.

The setup:
- What it reads: {data_sources}
- What it can do: {tools_and_actions}
- Which credential or account it uses: {credentials}
- Who else can put content in front of it: {untrusted_inputs}

Answer in four parts:
1. Which of these three is present: access to private data, exposure
   to attacker-controlled content, ability to communicate externally.
2. Every outbound path data could take, including indirect ones like
   URL fetches, rendered images and writes to shared documents.
3. The single worst outcome if the assistant follows hostile
   instructions with the access it currently has.
4. The smallest change that would remove one leg of the trifecta,
   and what capability I would lose by making it.

If the description is missing information you need, say what is
missing rather than assuming.