Why the industry shipped anyway

Why the industry shipped anyway

A reasonable person might ask how an industry ships tens of thousands of agents on top of its own number-one unsolved vulnerability.

The answer is not recklessness. It is that the vulnerability does not look like a vulnerability from inside a sprint. There is no crash. No stack trace, no failing test, no scanner finding. The agent works. It works in the demo, it works in staging, and it works in production for months. The failure mode is not that the system breaks, it is that the system does exactly what it was asked to do by someone who was not supposed to be asking.

Traditional application security has a name for the class and forty years of practice at it. SQL injection is the same shape: data arriving in a channel that gets interpreted as instruction. The industry solved that one, and it solved it by separating the two channels at the interface, not by getting better at recognising malicious strings.

That solution is unavailable here. Parameterised queries work because SQL has a grammar, and a value slot is structurally distinct from a keyword. A language model has one channel. Everything arriving is tokens, and every token is eligible to be read as an instruction. There is no slot.

Which is why the useful question is not the one most teams ask.

The question to stop asking

The natural first question is: how do I detect an injection?

Chapter 4 spends its length on why that question has no satisfying answer, using the defenders' own strongest published results. The short version is that detection is a probabilistic classifier facing an unbounded input space and an adversary who can test offline, for free, forever.

Here is the better question, and the one this book answers:

Why does my system care what the model believes?

Sit with how strange that sounds. You built the agent so that its decisions would drive real actions. Of course the system cares what it believes. That was the feature.

But look at what you actually wanted. You wanted the agent to draft the refund, route the ticket, summarise the thread, propose the change. In almost no case did you want it to be the final authority on whether the refund should happen. That authority got attached by accident, because the framework made tool-calling easy and nobody wrote down where the decision should live.

A fooled model is not a breach. A fooled model holding credentials is.

The rest of this book takes that seriously as an engineering programme. Not detection. Not better prompts. A system in which the model's beliefs are an input to a decision made somewhere else, by code that cannot be argued with, that you can test, and that leaves a record.

Chapter 2 starts by clearing up the confusion that costs teams the most time: the difference between an attack on the model and an attack on your application.

Sources for this chapter

Rechecked 16 September 2026: OWASP's own pages still serve the 2025 edition, so the 2026 list and its methodology figures rest on secondary reporting. Two independent outlets now report the same three figures, which raises confidence without making them primary, and they disagree about the publication date. Both remain flagged in UNVERIFIED-CLAIMS.md (#12) for replacement with the primary when OWASP publishes it. The reading of the Replit incident as an agency failure rather than a demonstrated injection is the author's, and is the position the book takes throughout. The comparison to SQL injection and the argument that parameterisation has no equivalent here are the author's framing, not a research finding.