Series Foundations: What This Book Builds On
This is a reference for authors and editors, not a manuscript chapter. AI Threat is Book 5 of The Transformed Architecture. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question none of them asked directly: is there anything in the claim that the dystopias of science fiction, with AI as the threat, are coming true? This document records the conclusions the book builds on with stable identifiers (F1 to F34, where F1 to F24 keep the identifiers used in AI Red Team), the open questions the earlier volumes left that bear on the AI threat (Q1 to Q12), the artefacts and vocabulary the book reuses, and the tables of contents used for cross-references. BOOK_BLUEPRINT.md maps every chapter of this book to the foundations it builds on.
When a chapter builds on a foundation, it says so in the prose, refers to the earlier volume in plain text by chapter ("AI Platform and Security, Chapter 19"), cites the volume's bibliography entry, and summarises enough that the reader is not left with a gap.
The turn this book makes
The first four volumes are engineering books. Architecture as Code made architecture executable. AI Governance made governance executable and proportionate to usage mode and risk. AI Platform and Security built the platform, secured it and concluded that AI is both a target and a source of threat, so every AI system must be designed twice: as something to protect and as something to contain. AI Red Team puts AI to work in cyber defence under a written mandate, at an autonomy level matched to the reversibility of its actions.
Along the way the series met, in its own material, the phenomena that public debate frames as the beginning of the science-fiction dystopia: agents that game their objectives, models that behave differently when they believe they are being tested, an evaluation run in July 2026 in which agents broke out of their environment and attacked real infrastructure, attackers who use AI to compress the time from patch to exploit, and public authorities whose automated decisions harmed the residents they served. The earlier volumes treated each of these as an engineering problem to be contained. None of them stepped back to ask what the phenomena add up to.
AI Threat steps back. It treats the dystopian claim as a hypothesis to be tested, not as a prophecy to be believed or a fantasy to be dismissed. It separates fiction, argument, laboratory demonstration and incident in the wild; it weighs what is observed against what is extrapolated; and it asks what a European enterprise or public authority can and should do about each strand of the threat. It keeps the series' discipline: claims carry evidence labels, scenarios are kept as versioned records with owners and triggers, and the response is expressed as controls that hold whatever anyone intends.
Foundations from Architecture as Code (Book 1)
| ID |
Conclusion |
Where it is made |
| F1 |
Threat handling belongs in the codebase: threat intelligence is ingested as STIX/TAXII through pipelines, threat models are generated from architecture code, response playbooks are state machines (subscribe, assess, act, document), and findings return as pull requests. "Celebrate the remediation pull request, not just the discovery." |
Chapter 9C, Risk as Code and Threat Handling as Code |
| F2 |
Risk is a versioned record with likelihood, impact, owner and expiring exceptions; a failing control metric fails the pipeline. |
Chapter 9C |
| F3 |
Policy as Code (OPA/Rego) with "assure once, comply many": a control is written once and mapped to many obligations, with evidence linked to enforcement. |
Chapters 10 and 11 |
| F4 |
Evidence as Code: evidence is machine-collected, signed and versioned, not assembled in audit season. |
Chapter 15A, Evidence as Code and Continuous Assurance |
| F5 |
Manual incident response cannot scale when attacks develop within minutes; compromised components are redeployed from known-good definitions, and MTTD, MTTR and false-positive ratio are the programme metrics. AI models must themselves be defended against adversarial machine learning. |
Chapter 9B, Advanced Security Patterns and Implementation |
| F6 |
The four security dimensions: threat modelling, zero trust, Policy as Code and risk assessment. |
Chapter 9, Security Fundamentals for Architecture as Code |
| F7 |
AI agents are structured participants under human direction: "agents draft; humans approve", and exceptions and risk acceptances carry a named human approval in the audit trail. |
Chapter 20, AI Agent Team for Architecture as Code Initiatives |
| F8 |
Security and compliance tests, including synthetic attack simulations, run in the pipeline against ephemeral environments. |
Chapter 13, Testing Strategies for Infrastructure as Code |
Foundations from AI Governance (Book 2)
| ID |
Conclusion |
Where it is made |
| F9 |
AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk; the usage mode, not the brand, sets the governance (Mode 0 ambient AI to Mode 5 autonomous production agents). |
Chapters 2 and 25 |
| F10 |
Classification is triggered by change, not by the calendar: a new model version, a drift alert, an incident, a regulatory change or a move between modes. |
Chapter 8, AI Risk Management and Classification as Code |
| F11 |
Decisions are tiered: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, risk beyond appetite at the management body. |
Chapter 13, Decision Forums and Governance Bodies |
| F12 |
Evidence is a by-product of delivery; the evidence manifest ties the chain together; attestation is a person asserting, evidence is machine-generated. |
Chapter 11, Evidence, Assurance and Audit |
| F13 |
Govern every agent as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences. |
Chapters 19 and 25 |
| F14 |
The July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert that reached people who did not hold the stop decision. |
Chapter 19, A Cautionary Case: The OpenAI–Hugging Face Incident |
| F15 |
Patch decisions must be delegated in advance; a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and patch velocity belongs in management reporting as a risk indicator. |
Chapter 24, Reflections on Each Part |
| F16 |
Human oversight must be designed, not declared: an interruption path, an override log and the authority to use them. Approvals given in seconds are a signal of rubber-stamping. |
Chapters 10 and 21 |
| ID |
Conclusion |
Where it is made |
| F17 |
A platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation. |
Chapter 25, Conclusions: Building and Securing AI Platforms |
| F18 |
AI is both a target and a source of threat; every AI system is designed twice, as something to protect and as something to contain; security operations must run faster than a monthly patch cycle. |
Chapters 18 and 25 |
| F19 |
Four commitments against AI-enabled adversaries: patch velocity as a measured service level (EPSS, KEV, EUVD and local exposure); detection at machine speed, with canaries, honeytokens and the authority to act; identity and approvals that resist synthetic media; and AI for defence under oversight, where defensive agents get scoped credentials, sandboxed verification and human approval, and human verification is the bottleneck. |
Chapter 18, When AI Is the Threat |
| F20 |
Prompt injection is a property of the architecture, not a patchable defect; controls sit outside the model; OWASP LLM Top 10 and MITRE ATLAS give the shared vocabulary; model loading is code execution. |
Chapter 16, Security for AI Systems |
| F21 |
Red teaming of AI systems runs continuously in CI: the external exercise is for discovery, and every finding becomes a versioned attack case with explicit thresholds, published as evidence against control IDs. DORA threat-led penetration testing is periodic; continuous suites complement it. |
Chapter 17, AI Security Engineering in Practice |
| F22 |
Red teaming is the apex of the evaluation pyramid: a scenario library in version control, an automated harness, a route for human findings into scenarios, and a finding–remediation–re-test path. Article 55 adversarial testing falls on providers of general-purpose AI models with systemic risk; deployers ask for the evidence and test the compound system themselves. |
Chapter 20, Evaluation and Testing of AI Systems |
| F23 |
Containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report. |
Chapter 19, When Your Own Agents Exceed Their Mandate |
| F24 |
AI incident management adds an AI classification step (AI Act Articles 3 and 73, DORA), an impact query against the event log and a path back to evaluation; the runbook stages are detection, triage, containment, notification, recovery and post-incident review. |
Chapter 21, Observability, Monitoring and Drift in Production |
Foundations from AI Red Team (Book 4)
AI Red Team is written in full, with 28 chapters organised by the six Functions of NIST CSF 2.0. The entries below are its thesis and red threads, with the chapters in which it states them.
| ID |
Conclusion |
Where it is made |
| F25 |
AI must become an active, governed part of cyber defence, because defenders who treat AI only as something to protect lose the race against AI-enabled attackers on time alone. |
Chapter 1, Introduction: Putting AI to Work in Cyber Defence |
| F26 |
Five autonomy levels for AI that acts (Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous); the level is matched to the reversibility and blast radius of the action, and Level 4 is never used for offensive or irreversible actions. |
Chapter 6, Roles, Usage Modes and Autonomy Levels: People in Command of Security AI |
| F27 |
Every finding, from an exercise, an AI red-teaming campaign or an incident, ends as a verified control, tested by re-running the scenario that found the gap (the purple loop). |
Chapter 26, Purple Teaming, Measurement and Continuous Improvement |
| F28 |
Writing about offensive capability stays defensive: adversary behaviour is described by technique at the level needed to design controls, never as exploit code, payloads, jailbreak strings or step-by-step instructions. |
Chapter 1, Introduction: Putting AI to Work in Cyber Defence |
| ID |
Conclusion |
Where it is made |
| F29 |
Model origin is a risk question separate from hosting: five categories of geopolitical risk, and a risk-tiered position that decides which models may handle which data, reviewed periodically rather than once. |
AI Governance, Chapter 6, Geopolitics and Model Origin |
| F30 |
In public authorities legality comes before capability: the line between decision support and automated decision is drawn in the data model and the audit log, every case has a reasons log, and the algorithm register is generated from version-controlled entries. Rule-based automation works where rules are clear and the citizen can see the calculation; trouble starts where statistical models replace rules without that explanation discipline. |
AI Governance, Chapter 17, AI in Public Authorities |
| F31 |
An outlook is governed as a horizon register: each trend is labelled observable, expected or speculative, observable trends justify commitment, expected ones preparation and speculative ones reversibility, and the register is valuable because it can be wrong in a reviewable way. |
AI Governance, Chapter 22, Future Trends |
| F32 |
The author's judgement is kept apart from the book's findings: projections that go beyond the evidence are labelled and placed in their own chapter. |
AI Governance, Chapter 24, Reflections on Each Part |
| F33 |
Digital sovereignty is a set of verifiable properties, not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. |
AI Platform and Security, Chapter 13, Infrastructure, Compute and European Digital Sovereignty |
| F34 |
Cost and energy are architectural characteristics of AI systems; the footprint of training and inference varies by orders of magnitude with choices of model, hardware, location and time. |
AI Platform and Security, Chapter 22, Cost, Capacity and Sustainability of AI |
Open questions this book takes up
| ID |
Question |
Raised in |
| Q1 |
How far can evaluation carry assurance when models can tell test settings from deployment? |
AI Governance, Chapter 24 |
| Q2 |
How do organisations prepare for a stream of smaller agent incidents reconstructed from logs not designed for the purpose? |
AI Governance, Chapter 24 |
| Q3 |
The capability shown in July 2026 will reach deliberate attackers. How is the containment built for one's own agents tested from the adversary's side? |
AI Governance, Chapter 19 |
| Q4 |
Security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case. What does that assumption mean beyond security operations? |
AI Platform and Security, Chapter 25 |
| Q5 |
When may an AI act without per-action approval, and who decides? |
AI Platform and Security, Chapter 18; AI Governance, Chapter 13 |
| Q6 |
Version control captures what changed but not whether the reasoning behind a change was sound. How is AI-proposed change reviewed for soundness when the reviewer depends on the AI? |
Architecture as Code (Chapter 27) |
| Q7 |
How do defenders plan for patch-to-exploit times measured in minutes, and will patch velocity become a supervised metric? |
AI Governance, Chapter 24 |
| Q8 |
Is the July 2026 incident an outlier produced by an unusual evaluation set-up, or the first visible instance of a pattern? |
AI Governance, Chapters 19 and 24; Chapter 24 records, and doubts, the developer's own description of the event as an outlier |
| Q9 |
Reported behaviours such as specification gaming, scheming and shutdown resistance are observed in evaluations. What would show that they occur, and matter, in deployment? |
Prompted by AI Platform and Security, Chapter 19 |
| Q10 |
How should a board treat risks that are low in estimated probability, extreme in consequence and contested among experts? |
New in this book |
| Q11 |
Which of the harms that science fiction attributes to machines have already happened through ordinary automation, without any advanced AI? |
New in this book |
| Q12 |
What can a single enterprise or public authority do about risks that are systemic, international and decided by a handful of developers? |
New in this book |
Vocabulary and artefacts to reuse
- Usage modes Mode 0 ambient AI to Mode 5 autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2).
- Autonomy levels Level 0 Advisory to Level 4 Autonomous (AI Red Team, Chapter 6).
- Containment profile, permission manifest and stop path (AI Platform and Security, Chapter 19); policy decision point outside the model and the AI gateway (AI Platform and Security, Chapters 4 and 12).
- AI Decision Records (AIDR-NNNN, immutable and numbered); this book uses AIDR-0400 to AIDR-0499.
- Horizon register and decision tiers (AI Governance, Chapters 13 and 22). This book extends the horizon register into the AI threat register (Chapter 32), whose entries carry the identifiers
THR-NN.
- Evidence manifest, control catalogue identifiers such as
CTRL-AGT-002, and exceptions as expiring records (EXC-NNNN).
- Observable / Expected / Speculation labels for any outlook. This book adds the evidence ladder (Chapter 4): fiction, argument, laboratory demonstration, incident in the wild, and pattern at scale.
- The fictional organisations Nordvik Region and Hansa Mutual, with the threat-governance profile added for this book in
EXAMPLE_ORGANISATIONS.md.
Tables of contents for cross-references
Architecture as Code (Book 1): chapters most used
| Chapter |
Title |
| 9 |
Security Fundamentals for Architecture as Code |
| 9B |
Advanced Security Patterns and Implementation |
| 9C |
Risk as Code and Threat Handling as Code |
| 10 |
Policy and Security as Code in Detail |
| 11 |
Governance as Code |
| 13 |
Testing Strategies for Infrastructure as Code |
| 15A |
Evidence as Code and Continuous Assurance |
| 20 |
AI Agent Team for Architecture as Code Initiatives |
| 27 |
Conclusion |
AI Governance (Book 2)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Governance |
|
2 |
From Chat to Agents: How Large Language Models Are Used |
|
3 |
The EU AI Act and the European Regulatory Landscape |
|
4 |
Fundamental Principles |
|
5 |
Prerequisites and Readiness for Enterprise AI |
| II Sovereignty and Suppliers |
6 |
Geopolitics and Model Origin |
|
7 |
Procurement, Vendor Management and Open Models |
| III Risk, Governance, Trust and Assurance |
8 |
AI Risk Management and Classification as Code |
|
9 |
AI Governance as Code |
|
10 |
Trustworthy AI: Transparency, Fairness and Human Oversight |
|
11 |
Evidence, Assurance and Audit |
| IV Organisation and Leadership |
12 |
Organisational Design for AI |
|
13 |
Decision Forums and Governance Bodies |
|
14 |
Competence, Roles and the AI Architect |
|
15 |
Change Management and Responsible Adoption |
|
16 |
Management as Code for AI Programmes |
|
16A |
Governing AI Economics: Cost, Value and Portfolio Decisions |
|
17 |
AI in Public Authorities |
| V Experience |
18 |
Case Studies |
|
19 |
A Cautionary Case: The OpenAI–Hugging Face Incident |
|
20 |
Anti-Patterns |
|
21 |
Best Practices and Lessons Learned |
| VI Future and Conclusions |
22 |
Future Trends |
|
23 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
24 |
Reflections on Each Part |
|
25 |
Conclusions: A Consolidated Analysis |
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Platform and Security |
|
2 |
Usage Modes and the Platform: What Each Mode Demands |
|
3 |
Regulatory Requirements as Engineering Constraints |
|
4 |
A Reference Architecture for AI in Large Organisations |
|
5 |
AI Decision Records, Model Cards and the Architecture Repository |
| II Data, Models and DevSecMLOps |
6 |
Data Architecture for AI |
|
7 |
Model Lifecycle Management: MLOps and LLMOps as Code |
|
8 |
Setting Up an Effective DevSecMLOps Loop |
|
9 |
Risks and Vulnerabilities Across the DevSecMLOps Loop |
|
10 |
Foundation Models, Retrieval and Grounding |
|
11 |
Agentic Architectures and Orchestration |
|
12 |
Integrating AI into the Enterprise Landscape |
| III Infrastructure |
13 |
Infrastructure, Compute and European Digital Sovereignty |
|
14 |
Cloud AI Services versus On-Premises AI: Different Challenges |
|
15 |
Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information |
| IV Security |
16 |
Security for AI Systems |
|
17 |
AI Security Engineering in Practice |
|
18 |
When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window |
|
19 |
When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent |
| V Delivery and Operations |
20 |
Evaluation and Testing of AI Systems |
|
21 |
Observability, Monitoring and Drift in Production |
|
22 |
Cost, Capacity and Sustainability of AI |
|
23 |
From Pilot to Production: Scaling AI Across the Organisation |
| VI Conclusions |
24 |
Nordvik Region and Hansa Mutual: Platform and Security Conclusions |
|
25 |
Conclusions: Building and Securing AI Platforms |
AI Red Team (Book 4)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction: Putting AI to Work in Cyber Defence |
|
2 |
The Threat Landscape When Attackers Use AI |
|
3 |
NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations |
|
4 |
A Reference Architecture for AI-Enabled Cyber Defence |
| II Govern |
5 |
Organisational Context and Risk Strategy for AI in Cyber Defence |
|
6 |
Roles, Usage Modes and Autonomy Levels: People in Command of Security AI |
|
7 |
Policy, Mandate and Rules of Engagement |
|
8 |
Oversight and AI Supply Chain Risk |
| III Identify |
9 |
Asset Management for an Estate That Includes AI |
|
10 |
AI-Assisted Threat Modelling and Risk Assessment |
|
11 |
Vulnerability Discovery and Exposure Management at Machine Speed |
|
12 |
Adversary Emulation and Continuous Red Teaming with AI |
|
13 |
Red Teaming AI Systems and Agents |
| IV Protect |
14 |
Identity, Authentication and Access for People, Agents and Machines |
|
15 |
Awareness and Training: Resilience to AI-Generated Deception |
|
16 |
Data and Platform Security with and for AI |
|
17 |
Technology Infrastructure Resilience Against Machine-Speed Attacks |
| V Detect |
18 |
The AI-Assisted Security Operations Centre |
|
19 |
Detection Engineering, Threat Intelligence and Deception as Code |
| VI Respond |
20 |
Incident Management and Analysis with AI |
|
21 |
Incident Reporting, Communication and Mitigation |
| VII Recover |
22 |
Recovery Plan Execution with AI: From Incident to Restored Operations |
|
23 |
Recovering AI Systems and Security AI |
|
24 |
Proactive Recovery: Recoverability, Rehearsal and Communication |
| VIII Verification, Improvement and Conclusions |
25 |
Security Chaos Engineering with AI: Verifying Security Capabilities Continuously |
|
26 |
Purple Teaming, Measurement and Continuous Improvement |
|
27 |
Nordvik Region and Hansa Mutual: Cyber Defence Conclusions |
|
28 |
Conclusions: AI as an Active Part of Cyber Defence |