Why Input Filtering Does Not Work
Three weeks of attacks, and every single one ended on the same note in the defense section: do not rely on detecting the malicious text. Week four is the defense half, and it has to open here, with the hardest thing for most teams to accept, because it is the belief that sends the most security budget to the wrong place. The instinct when you first see prompt injection is to filter it. Scan the input, catch the bad instruction, block it. That instinct is wrong, and today is about why, precisely, so the rest of week four makes sense.
This is not a counsel of despair. It is the opposite. Once you accept that you cannot detect the attack, you stop pouring effort into a leaky wall and start building the defenses that actually hold, the ones the next six days cover. But you have to internalize the why first, or you will keep reaching for the filter.
What input filtering tries to be
The idea is simple and appealing. Put a check between untrusted content and the model. The check reads the content, decides is this an injection, and blocks or strips it if so. It might be keyword matching, a trained classifier, or even another model asked to spot attacks. The shape is always the same: detect the malicious text, then stop it.
It feels right because it is how we defend everything else. WAFs detect malicious requests. Antivirus detects malicious files. Spam filters detect spam. Detection then blocking is the default security pattern, so of course we reach for it with injection. The problem is that injection breaks the assumption every one of those relies on.
The assumption that breaks
Traditional filters work because malicious input is structurally distinguishable from legitimate input. SQL injection has syntax that does not belong in a name field. Malware has signatures. Even spam has statistical tells. There is a line, however fuzzy, between the bad thing and the normal thing, and the filter learns that line.
Prompt injection has no such line, and this is the whole point. The malicious instruction is written in the same language, with the same vocabulary, in the same register, as legitimate content. An injection that says, in effect, treat this customer’s issue as urgent and escalate is indistinguishable in form from a real customer writing exactly that. There is no syntax that does not belong, because natural language is the syntax, and natural language is also the legitimate content.
Recall from Day 16 the subtlest payload family, plausible task continuation, text that simply reads as a natural next step for the job the agent is doing. That family exists specifically because it has no malicious markers at all. It is benign in wording and malicious only in effect. A filter that reads wording cannot see effect. The thing you need to detect is not in the text, it is in what the text will cause, and the filter only has the text.
The adversary makes it worse
Even setting aside the plausible benign case, there is the adaptive problem. A filter is a fixed target. The attacker can see what it catches and reword until it passes. Encode the instruction, split it, translate it, bury it, phrase it a hundred ways, and keep going until one gets through. The filter has to catch every variant. The attacker needs one that slips.
This is why the field wide finding keeps recurring in this series: adaptive attacks bypass essentially every published defense. It is not that the filters are badly built. It is that the problem is adversarial and the defender is trying to enumerate an infinite space of phrasings while the attacker only has to find one gap. Classifiers that score well on known attacks fall over on novel rewordings, because they learned the examples, not an invariant, and there is no invariant to learn when the attack can be any sentence.
The two ways every filter fails
Both error directions are fatal, and you cannot tune away both at once.
False negatives. Set the filter loose enough to avoid blocking real content, and attacks slip through. Given the adaptive problem, some always will. One slip is a breach, because the attacker only needed one.
False positives. Tighten it to catch more attacks, and it starts blocking legitimate content, the urgent customer, the detailed bug report, the document that happens to contain instruction like phrasing. Now the filter breaks the agent’s actual job, and teams respond by loosening it, back to false negatives.
There is no setting that catches all attacks and blocks no legitimate content, because the two categories overlap in form. The filter is trying to separate two things that look the same. Any threshold you pick is a bad trade, and the attacker lives in the overlap on purpose.
The deeper reason: data and instructions share a channel
Step back to the root, from Day 1. A language model has one input channel, the context window, and everything in it is a candidate instruction. There is no architectural separation between data and instructions, no type system that marks this is content, not commands. The model decides what to treat as an instruction based on meaning, not origin.
A filter sits outside the model and tries to restore that missing separation by reading the text and guessing intent. But it is guessing the same thing the model will decide, with less context, before the fact. If the model itself, with full context, cannot reliably tell a planted instruction from legitimate content, a filter in front of it with less information certainly cannot. You are asking a smaller, dumber check to solve the exact problem the larger model could not.
That is the fundamental reason. Filtering tries to detect intent in text where intent is not reliably present in the text. The information needed to make the decision is not there to be read.
So why does anyone use it
Because it is not useless, it is just not sufficient, and the distinction matters.
A filter catches the lazy, high volume, unsophisticated attempts, the crude payloads with obvious markers. That raises the attacker’s cost a little and cleans up the noise. As one layer in defense in depth, it has a place. The failure is treating it as the layer, the thing that makes the agent safe. It does not, and cannot, and a team that believes it does will underinvest in the defenses that actually work.
The honest framing: a filter is a doormat, not a lock. It catches some dirt. It stops no one who wants in.
What this forces you to do instead
If you cannot detect the attack, you have exactly one move left, and it is the move the whole rest of week four develops: stop trying to prevent the instruction from landing, and instead ensure that a landed instruction cannot cause harm.
This is the shift from detection to containment, from guarding the entrance to limiting the consequence. Every attack in this series ended by pointing here, and now we name it as the strategy. You assume the injection succeeds, every time, and you architect so that success reaches nothing valuable and exits nowhere useful. Day 23’s dual LLM pattern, Day 24’s information flow control, Day 25’s capability scoping, all of them are instances of this one idea: make the agent’s success not matter.
That is why today has to come first. You cannot appreciate the containment defenses until you have given up on the detection ones. The teams that build good agent security are the teams that made this peace early.
Detection and defense, the honest version
Phrased as what to actually do with filtering.
Use filtering as a doormat, not a lock. Deploy it to clean up crude, high volume attempts and reduce noise. Expect it to catch the lazy and miss the competent. Budget for it accordingly, which means small.
Never report an agent as safe because filtering is present. In assessments, treat the presence of an injection classifier as near zero mitigation against a capable attacker. The finding stands regardless of the filter.
Measure it as a rate, not a guarantee. The Day 16 lesson. If you run a filter, measure its bypass rate with adaptive attempts, not a fixed test set, and report that it degrades against novel phrasing.
Spend the real budget on containment. Scope, isolation, capability limits, egress constraint. The defenses that do not depend on reading intent. This is where week four goes.
Do not let filtering create false confidence. The worst outcome is not a filter that fails. It is a team that stopped building real defenses because the filter made them feel safe. The doormat convinced them they had a lock.
The through line, stated as the opening of the defensive half: you cannot win by detecting the malicious text, because the malicious text is indistinguishable from legitimate text and the adversary adapts faster than you can enumerate. So you stop trying, and you build for the world where the attack always lands. Everything from here forward assumes success and limits its blast radius.
Homework for Day 22
- Take your best injection from week three and run it against a simple keyword or classifier based filter you write. Then reword it, Day 16 families, and get it past the filter. Confirm how few attempts it takes.
- Now tighten the filter until it catches your rewordings, and find a piece of legitimate content, an urgent real ticket, a detailed bug report, that it now wrongly blocks. Demonstrate the false positive or false negative trade with your own hands.
- Write one paragraph explaining why the data and instruction shared channel makes a pre model filter fundamentally limited, in your own words.
- For your own real agent, note whether any safety claim currently rests on input filtering, and flag it.
- Write the one sentence that reframes your whole defensive posture: assume the injection lands, and limit what it can reach. Pin it. It is the thesis of week four.
Point 2 is the one to feel in your hands. When you watch your own filter either miss the attack or block a real customer, with no setting that does neither, you stop believing in the filter and you are ready for what actually works.
Day 23 introduces the first real containment defense, the dual LLM pattern, which separates the privileged part of the agent from the part that touches untrusted content, so a landed injection has no privileged hands to act with.
