The "even-if" chain is the clearest walkthrough of defense in depth I've seen applied specifically to agents. What stands out is that the decisive layers are deterministic code, not model judgment, which lines up with something I keep coming back to: an agent can reason all it wants, but authority has to live outside the prompt entirely.
The confused-deputy point in section 8 is the one I'd flag as most likely to get skipped in practice. Teams scope the top-level agent carefully, then let every sub-agent it spawns inherit that scope by default, because narrowing it per hop feels like unnecessary friction, until the orchestrator delegates to something that reads untrusted content. Do you have a sense of what per-hop token minting actually costs teams running deep delegation chains, in latency or infra overhead?
"Never put a security decision inside the prompt" is the right one-liner, and framing it as four parties with trust boundaries teaches it better than a threat list does.
The MCP tool servers deserve extra weight: they are usually third-party code holding real credentials, and most builders inherit their permission model without reading it. Two additions. Tool output is an input, so a compromised or merely sloppy tool server can inject through its response, which means untrusted-data handling applies on the way back and not only on the way in. And an approval gate only works if the human sees the resolved action rather than the model's description of it. "Send a summary to the team" and the actual recipient list are different objects, and the gap between them is where the attack lives.