A caution before the tables. Mappings like these are useful for conversation and dangerous for assurance. A tick in a row means the mechanism addresses part of that category, not that the category is closed. Nothing here is a certification and no framework in this list has a control that prompt injection cleanly satisfies.
| # | Category | Addressed by | Coverage |
|---|---|---|---|
| LLM01 | Prompt Injection | The whole book. Directly: the gate (ch 9), quarantine (ch 7) | Contained, not prevented. Ch 4 and ch 20 explain why prevention is not on offer |
| LLM02 | Sensitive Information Disclosure | Egress (ch 10), capability scoping (ch 8), quarantine (ch 7) | Substantial for agent-mediated disclosure. Says nothing about disclosure through other paths |
| LLM03 | Excessive Agency | The gate (ch 9), capability (ch 8), human-in-the-loop (ch 14) | The book's strongest coverage. Chapter 9 turns this from a prompt instruction into an architectural property |
| LLM04 | Data and Model Poisoning | Memory and retrieval provenance (ch 12) | Retrieval and memory only. Training-time poisoning is out of scope |
| LLM05 | Improper Supply Chain | Tool register, pinning, description hashing (ch 13) | Tool and agent supply chain. Not your general dependency programme |
| LLM06 | Insecure Output Handling | The renderer and URI policy (ch 10) | Good, for the exfiltration case. Other output-handling risks unaddressed |
| LLM07 | Vector and Memory Flaws | Provenance on memory writes and retrieval (ch 12) | Partial. Embedding inversion is not covered |
| LLM08 | Misinformation | — | Not addressed. A contained agent can still be confidently wrong |
| LLM09 | Hidden Context Exposure | Quarantine (ch 7), the two-reason verdict (ch 9) | Partial |
| LLM10 | Unbounded Consumption | Egress budgets (ch 10), capability expiry (ch 8) | Incidental. This book is not about cost control |
Two rows have no coverage and it is worth being direct about them. Misinformation is a model-quality problem that containment does nothing for. Unbounded consumption is touched only because budgets happen to bound it.
| Function | Relevant artifact from this book |
|---|---|
| Govern | The policy shape and tool register (ch 18, ch 13); the boundary of what is out of scope, stated in the front matter |
| Map | The trifecta audit (ch 3, Appendix A). This is the closest thing in the book to a risk assessment and is what to hand over when asked for one |
| Measure | The injection suite and coverage metrics (ch 15); red team findings (ch 16). Note: coverage, not a pass rate. Ch 15 explains why a pass rate misleads |
| Manage | The gate, capability, egress and approval mechanisms (ch 8-10, 14); incident response (ch 17) |
The framework asks for measurement, and this book's honest position is that the available measurements are coverage counts and regression results rather than an assurance figure. Say that plainly rather than producing a percentage.
Status as of September 2026, per Regulation (EU) 2026/1744 (Digital Omnibus on AI), adopted 8 July 2026, in force 27 July 2026.
| Obligation | Date | Relevance |
|---|---|---|
| Prohibited practices | Enforceable since Feb 2025 | Unlikely to bite an internal agent |
| GPAI model obligations | Since Aug 2025 | Applies to model providers, not to you as a deployer |
| Article 50 transparency | 2 August 2026 — this date held | The one most likely to apply. If your agent talks to people, tell them it is an agent |
| High-risk, Annex III | Deferred to 2 December 2027 | A genuine compliance project if you are in scope |
| High-risk, Annex I (product-embedded) | Deferred to 2 August 2028 | As above |
Artifacts this book produces that a high-risk assessment will want: the trifecta audit (risk assessment), the tool register (component inventory), capability issuance (access control), the approval surface (human oversight), the injection suite (testing evidence), and the four log records (record-keeping).
This is not legal advice. The dates are cited from the Official Journal. Which annex you are in is a question for counsel.
Neither has a control that names prompt injection, so the mapping runs through existing control families.
| Family | What to point at |
|---|---|
| Logical access | Capability issuance derived from user authority, per-task, expiring (ch 8) |
| Change management | Tool register with pinned hashes and review dates (ch 13) |
| Monitoring | Gate verdict log including denials (ch 9, ch 17) |
| Incident response | The three questions and the four records (ch 17), plus the rehearsal |
| Vendor management | The six procurement questions (ch 18) |
The useful framing with an assessor is that an agent is a privileged automated actor, and the controls you would apply to any such actor apply here. That conversation goes better than one that starts with the word "AI".
Three things this book treats as central that no mainstream framework will request. Expect to explain them.
Provenance tracking. No control anywhere asks whether your system knows the origin of the values it acts on. It is the most important property in this book and there is no box for it.
Irreversibility classification. Frameworks ask about access control. None ask which of your operations cannot be undone, which is the axis chapter 14 argues should drive human oversight.
Approval fatigue. Every framework counts whether human oversight exists. None measure whether it is real. An organisation rubber-stamping a thousand prompts a day passes the control and has no oversight at all.
If you are writing internal standards, these three are worth adding. They are where the actual risk sits, and the absence of a box does not make them optional.
Download the full PDF for free?
Free download — no account required