A book that ends by declaring the problem handled would be the same book as the guardrail vendor's landing page, with more pages.
So here is what the architecture in this book does not do.
Nothing here made the model more resistant. It reads an instruction in a document and follows it, exactly as it did in chapter 1. Every mechanism operates after that point.
This has a consequence people find uncomfortable once they notice it: your agent may be under successful attack continuously and you may not know. The gate denies, the egress policy drops, the capability does not cover it, and none of that necessarily surfaces as an alert. Absence of incidents is not evidence of absence of attacks.
The partial answer is chapter 17's logging. Denials are a pattern, and a system that never looks at its denial log is discarding its only signal about how often it is being probed.
Chapter 8 works because the task declares what it needs and the capability matches it. Some agents cannot work that way.
An engineering agent expected to investigate any part of a large codebase, an operations agent expected to respond to any incident, a research agent expected to follow any lead: these need wide authority by construction, and narrowing it to a task envelope removes the capability that justified building them.
For these, the honest position is that the architecture reduces to the gate and the human, and the human is doing most of the work. That is a weaker posture and it should be stated as one rather than dressed up. If your agent needs broad standing authority, you have a privileged access management problem wearing an AI costume, and the mature literature on that subject is more useful than this book.
Everything here assumes one agent with one planner, and that assumption is dissolving.
When agent A calls agent B, provenance has to cross a process boundary, and there is no widely-adopted standard for carrying it. Capability delegation raises questions this book did not answer: does B act with A's authority, or with the user's, or with some intersection? If B is compromised by content A passed it, whose gate decides?
The current practical answer is to treat every other agent as an untrusted external service. Its outputs are tainted. Its requests are proposals subject to your own gate. Do not accept its claims about provenance.
That works and it does not scale, and it forfeits most of what multi-agent architectures are supposed to buy. This is open work, and anyone claiming to have solved it in 2026 is selling something.
The five primitives are a quarter of engineering work that produces no visible feature. Chapter 18 covered how to argue for it. What that section did not say is that the argument sometimes fails for good reasons.
A three-person company shipping an internal tool over a trusted corpus should probably close the egress leg, mark their irreversible actions, and stop. The full architecture is not proportionate, and telling them otherwise is the kind of advice that gets security teams ignored.
The proportionality question is genuine and this book has an interest in answering it one way. Weigh it yourself.
Chapter 4 argued hard that filtering cannot be the boundary. That argument gets misread as saying detection is worthless, and the misreading is mine to prevent.
Run the detectors. They raise the cost of casual attacks, they catch the copy-pasted payloads that make up most real traffic, and they generate the signal chapter 17 needs. The claim was never that they do not work. It was that they cannot be the thing standing between an injected model and your database.
A team that reads chapter 4 and turns off their guardrails has taken the wrong lesson from it.
Not everything here is permanent. Four developments would move it, and they are worth watching for, partly so you can tell them apart from marketing.
Provenance inside the model. Today the origin of a token is metadata the model never sees. A model architecture that carried trust labels through attention, and could be trained to weight them, would attack the problem at its root rather than around it. Nothing production-ready exists. This is the one that would matter most.
A standard for provenance between systems. The multi-agent problem above is mostly an interoperability gap. A widely-adopted way to carry taint and capability across a service boundary would do for agents what mutual TLS did for service identity. There are proposals. There is no standard.
Capability primitives in the frameworks. Today every team writes chapter 8 themselves. When per-task, user-derived, expiring capabilities are a first-class concept in the agent frameworks the way tool calling is now, most of this book becomes configuration. Microsoft shipping approval primitives is a step in that direction and it took until 2026.
Formal guarantees on quarantine. CaMeL is the serious attempt and its authors are careful about what they claim. A design with a proof that no attacker-controlled token can influence a privileged decision, rather than an argument that it should not, would change how much trust the pattern deserves.
Three of those four are engineering rather than research, which is mildly encouraging. The first one is research and nobody should hold their breath.
Download the full PDF for free?
Free download — no account required