AI Engineering · Security
Free preview: the first part of this 13-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
AI Engineering
Unlock this lesson and the 199 other paid lessons
$49 once, by PayPal
See the AI Engineering courseread the rest of this lesson in
AI Engineering
Unlock this lesson and the 199 other paid lessons
$49 once, by PayPal
See the AI Engineering coursein Security
This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime AccessFoundation lessons of this course are free, no payment needed. Try them now
Put a real number on the table first. Suppose you build an injection filter and it is good, it catches 95 percent of attacks. An attacker who fails just rewords the payload and tries again, and each attempt is a fresh 5 percent chance of getting through. After twenty tries the chance that at least one landed is not 5 percent. It is 64 percent. After fifty tries it is 92 percent.
That is the whole problem in one calculation. A control that catches 95 percent of attempts sounds strong, and against an opponent who gets one shot it would be. Against an opponent who gets unlimited free shots it is a delay, not a wall. The breach is not a risk you carry, it is an event on a schedule. The chart below draws the two kinds of answer on the same axes: a filter is a score whose failure probability climbs toward certainty with every retry, while a removed capability is a property that stays pinned to zero forever.

This lesson is not about what is or how to write defenses. The lesson on prompt injection and the lethal trifecta covers the attack, and the lesson on defending against prompt injection covers the containment patterns. This lesson answers the question that sits underneath both: why is the combination of untrusted input, tool access, and private data called unsolved, and why does no better model, no stronger prompt, and no smarter classifier change that answer. The short version is that people keep trying to detect their way out of a problem that only architecture can close. The defender who relies on detection has to be right on every input, forever, across every phrasing natural language allows. The attacker has to be right once.
Run the compounding yourself. Notice the last row, where a leg of the trifecta has been removed so the per-attempt success is exactly zero. That row does not move, no matter how many attempts you allow, because zero times any number of tries is still zero. That is the difference between a filter and a property, in one table.
Even a 99.9 percent filter, run against a thousand tries, fails 63 percent of the time. helps and you should use it, but it lowers the number of tries, not the per-attempt success rate, so a bounded but still large n against any nonzero rate compounds to a high probability. Indirect injection does not even hammer one endpoint: every poisoned page, email, or document an attacker can plant is another independent attempt that no request throttle sees. You cannot buy your way to safety by pushing the percentage up, because the attacker buys attempts faster than you buy accuracy.