Series Foundations: What This Book Builds On
This is a reference for authors and editors, not a manuscript chapter. AI Purple is Book 9 of The Transformed Architecture. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question that two of them each answered from one side only: what happens to the loop between the red team and the blue team when AI sits on both sides of the table? This document records the conclusions the book builds on with stable identifiers (F1 to F113, grouped by volume), the open questions that the earlier volumes left or that this book raises (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.
The series builds strictly in publication order, so that there is no circular reasoning between the books. This book is Book 9 and builds on Books 1 to 8; it refers to no later volume. It cites Architecture as Code as (Nordqvist, 2025) and AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss and AI Blue as (Nordqvist, 2026), each through its own entry in docs/32_references.md. When a chapter builds on a foundation, it says so in the prose, refers to the earlier volume in plain text by chapter ("Architecture as Code (Chapter 15A)"; "AI Governance, Chapter 13"; "AI Platform and Security, Chapter 19"; "AI Red Team, Chapter 26"; "AI Threat, Chapter 23"; "The Transformed Security Architect, Chapter 14"; "AI Boss, Chapter 26"; "AI Blue, Chapter 11"), cites the volume's bibliography entry, and summarises enough that the reader is not left with a gap. A reference to an earlier volume builds on that volume's conclusions; it never stands in for an external source for a factual claim.
The turn this book makes
The eight earlier volumes are about systems and about the people who govern, secure, assess, architect, manage and defend them. Architecture as Code made architecture executable. AI Governance made the governance of AI executable and proportionate to how AI is used. AI Platform and Security built the AI platform and concluded that every AI system must be designed twice, as something to protect and as something to contain. AI Red Team put AI to work in cyber defence under a written mandate, at an autonomy level matched to reversibility, organised by the Functions of NIST CSF 2.0, and defined the three teams: the red team emulates the adversary, the blue team defends, and the purple team is not a third team but the joint loop between them (AI Red Team, Chapter 26). AI Threat asked whether the dystopias are coming true. The Transformed Security Architect described the role that designs the boundaries, AI Boss asked what happens when AI takes the manager's chair, and AI Blue described the team that defends: five functions, the transformed SOC, the analyst and the craft.
Both of the books that touch the loop treat it from one side. AI Red Team, Chapter 26, gives the loop as the last step of a book organised by CSF Functions. AI Blue, Chapter 11, gives it as the second half of B5 Learn, "what the SOC does with an exercise result", and leaves the tradecraft of the red team and the joint practice to a later volume. AI Purple takes the loop itself as its subject. It asks what is scarce when an emulation side that can plan, vary and repeat adversary behaviour at low cost meets a detection and response side whose triage, investigation and drafting of detections are increasingly done by agents, while adversaries use AI to shorten the time from disclosure to exploitation. The traditional rhythm, an annual penetration test and a quarterly purple session, was set by the scarcity of skilled red-team hours; AI loosens that constraint and does not remove the need for what the loop was always for, an evidenced answer to the question "would we have seen and stopped this, and how do we know?"
The book divides the loop into five stages, named exactly so in every chapter that uses them: P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify (Chapter 4). They map to the five record states of AI Red Team, Chapter 26: Finding is the output of P3; Control and Detection are the output of P4; Re-test and Evidence are P5. The delegation of each stage to AI is a degree, using the series' autonomy levels, so that a delegation profile states per stage and action class how far a given capability has been allowed to go.
Its working thesis, tested in Parts II to V and judged in Chapters 25 and 29, has five parts. First, purple is a loop, not a team: what is scarce is a shared, verified account of what the defence does against what the adversary does, and the loop closes only when a change has been re-tested and the evidence attached. Second, AI moves the loop from the event to the pipeline, and keeps the event: continuous emulation and regression make verification routine, while the exercise remains where novelty, judgement and trust are produced. Third, a loop closed by machines alone verifies nothing new: verification needs independence between the side that tests and the side that is tested (the independence principle, the central design rule of the book). Fourth, coverage is a claim that needs evidence: "we detect technique T" has an age, a condition and a result, and untested is not covered. Fifth, safe and legitimate emulation is a design question settled in a signed rules-of-engagement manifest enforced outside the agent; Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise has been authorised to touch, or that targets a named person. The thesis would be shown wrong by evidence that fully automated emulation and automated detection engineering, with no human-authored novelty and no independent verification, sustain real detection of novel intrusions better over several years, as judged by independent threat-led tests, than a loop that keeps those properties, or that the continuous loop leaves the capacity for human-led, creative adversary emulation intact without people who practise it. The book keeps the series' discipline for outlooks: what is observable, what is expected and what is speculation, with the author's own projections kept to Chapters 25 and 29.
How the parts of this book take over the foundations
| Part |
Chapters |
Foundations taken over |
| I The Loop in Question |
1 to 4 |
F48 to F50 and F60 (the loop, usage modes and autonomy levels of AI Red Team); F62 and F70 (verified controls, the series' argument); F92, F93 and F102 (AI Blue: transformed not abolished, delegation profile, a finding closes on a passing re-test); F43, F44 and F59 for the pre-AI baseline of Chapter 2; F35 and F36 for the pressure in Chapter 3 |
| II The Stages of the Loop |
5 to 11 |
P1 (5): F1, F55, F65, F36; P1 and P2 (6): F27, F45, F50, F54, F61, F98, F107; P2 (7 and 8): F43, F44, F59, F61, F75, F95; P3 (9): F60, F62, F95, F96; P4 (10): F55, F76, F95, F98, F102; P5 (11): F4, F20, F60, F62, F102, F103 |
| III The Loop Meets AI Systems |
12 and 13 |
F39, F40, F41, F44, F101 (AI systems as targets and the detections that catch attacks on them); F57, F96, F97, F99, F111 (testing the SOC agents, playbooks and the provider's AI through the contract) |
| IV The Loop's Own AI |
14 to 16 |
F12, F27, F45, F51, F75, F88, F98 (agent team, mandates, containment); F62, F68, F76, F99, F100 (independence and verification when AI is on both sides, with the evaluation awareness of AI Threat, Chapter 23); F37, F45, F69, F101 (the loop's assets as tier-0) |
| V The Loop in the Organisation |
17 to 22 |
F62, F64, F95, F105 (coverage and measures); F103, F104, F108, F111 (operating models, roles, charters); F17, F19, F63, F107 (decision rights and the white team); F46, F78, F106 (regulation as constraint); F47, F57, F111 (across boundaries) |
| VI People and Career |
23 to 25 |
F52, F53, F66, F77, F79, F84, F86, F89, F110 (people on both sides, wellbeing, the red apprenticeship, competences); F32, F33, F80, F109, F112, F113 (outlook labels and the author's projection) |
| VII Experience and Conclusions |
26 to 29 |
F28, F67, F96, F114 (cases and anti-patterns); F70, F91, F112 (the series' argument closed for the loop); all foundations for the two-organisation conclusions |
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, Policy and Security as Code in Detail; Governance as Code |
| 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 |
Security architecture has four dimensions that the codebase must carry: threat modelling, zero trust, Policy as Code and risk assessment. |
Chapter 9, Security Fundamentals for Architecture as Code |
| F7 |
Security and compliance tests, including synthetic attack simulations, run in the pipeline against ephemeral environments. |
Chapter 13, Testing Strategies for Infrastructure as Code |
| F8 |
Architectural decisions are kept as short, numbered, immutable Architecture Decision Records beside the code, with context, options and consequences, so that the rationale survives the people who made it. |
Chapter 4, Architecture Decision Records (ADR) |
| F9 |
Architecture as Code succeeds only with equal investment in people, process and technology. Modern roles blend engineering, governance and advocacy; security partners work from shared roadmaps and influence without direct authority; dual-ladder careers keep experts on technical tracks; resistance to change usually signals legitimate concerns about skills and job security. |
Chapter 17, Organisational Change and Team Structures |
| F10 |
Platform teams act as internal service providers that own the common toolchains, guardrails and reusable modules, so that product teams move quickly without sacrificing governance; the system design mirrors the organisation's communication paths (Conway's law). |
Chapters 17 and 18, Team Structure and Competency Development for IaC |
| F11 |
Competence is managed as a skills matrix by level (Foundation, Practitioner, Advanced, Expert) with interpersonal domains, in a development loop of assessment, planning, learning, application, knowledge sharing and measurement; certifications validate knowledge, while practical demonstration on real delivery shows capability. |
Chapter 18 |
| F12 |
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 |
| F13 |
Some decisions stay with people whatever the agents propose: architectural commitments with long-term consequences (platform lock-in, data residency, operational dependencies) are escalated by the Architect agent, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual. |
Chapter 20 |
| F14 |
The habit on which trustworthy programmes are built is making the implicit explicit: an AI-assisted decision without a traceable human rationale should receive an Architecture Decision Record, written retrospectively if necessary. |
Chapter 27, Conclusion |
Foundations from AI Governance (Book 2)
| ID |
Conclusion |
Where it is made |
| F15 |
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 |
| F16 |
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 |
| F17 |
Decisions are tiered and routed to the lowest tier that can take them with evidence: 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. The tier policy is itself data, changed by pull request. |
Chapter 13, Decision Forums and Governance Bodies |
| F18 |
Governance as code does not remove forums; it changes what they are for. Pipelines enforce, observe and remember, while forums decide what pipelines cannot: appetite, policy, exceptions and residual risk. NIS 2 Article 20 and DORA Article 5 anchor oversight in a trained management body, and the AI architect acts as secretary of the design authority. |
Chapter 13 |
| F19 |
Stop decisions are named in advance: the on-call incident commander and the use-case owner may each stop a system unilaterally, restart needs the owner and, for high-risk systems, the risk function, and a stop path that runs inside the system it stops fails when it is needed. |
Chapter 13 |
| F20 |
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 |
| F21 |
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 |
| F22 |
Organisational design is architecture by other means (Conway's law). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode; control functions keep their independence through gates and records rather than meetings ("gates instead of meetings"), with exceptions routed as expiring records. |
Chapter 12, Organisational Design for AI |
| F23 |
The AI architect owns the seams between the architecture roles. The security architect keeps the threat model, identity, secrets and zero trust, and relies on the AI architect for AI-specific threats, guardrail policy, agent permissions and the model supply chain. |
Chapter 14, Competence, Roles and the AI Architect |
| F24 |
New roles follow the usage modes: the AI system owner, the agent operator who watches Mode 5 agents and may revoke their credentials, the skills curator and the evaluation engineer; existing roles such as procurement, internal audit and the data protection officer change. |
Chapter 14 |
| F25 |
AI literacy is role-specific and must be evidenced in a competence framework and individual records checked at the readiness gate. Article 4 of the AI Act, as amended by the Digital Omnibus, asks for measures that support literacy, but Articles 14 and 26(2) still demand competent oversight, and NIS 2 Article 20(2) and DORA Article 5(4) require management-body training. |
Chapter 14 |
| F26 |
Upskilling is the strategy and hiring is for scarce specialisms and the first AI architect; careers need a specialist ladder and a path between building and verifying with a cooling-off period; competence is assessed by practical demonstration, and assessment results are personal data whose use is agreed with employee representatives. |
Chapter 14 |
| F27 |
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 |
| F28 |
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 |
| F29 |
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 |
| F30 |
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. |
Chapter 6, Geopolitics and Model Origin |
| F31 |
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. |
Chapter 17, AI in Public Authorities |
| F32 |
An outlook is governed as a horizon register: each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; the register is valuable because it can be wrong in a reviewable way. |
Chapter 22, Future Trends |
| F33 |
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. |
Chapter 24 |
| ID |
Conclusion |
Where it is made |
| F34 |
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 |
| F35 |
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. Security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case (labelled speculation). |
Chapters 18 and 25 |
| F36 |
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, in which human verification is the bottleneck. |
Chapter 18, When AI Is the Threat |
| F37 |
A reference architecture of five layers inside a control plane for identity, policy, observability and evidence, carried by the AI gateway, the model registry, the evaluation service and prompt and policy repositories; every tool is registered and its credentials held by the platform. Adaptations are overlays on a pinned baseline that may only tighten it, and the declarative model can be checked against the running estate. |
Chapter 4, A Reference Architecture for AI in Large Organisations |
| F38 |
AI Decision Records keep Nygard's discipline of short, numbered, immutable records, add the fields AI needs, are validated against a schema and re-opened by evidence; the architecture repository, not the document, is the single source from which Annex IV technical documentation is generated. |
Chapter 5, AI Decision Records, Model Cards and the Architecture Repository |
| F39 |
Security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance (ML-BOM, SLSA, signing), and agent containment through identity, permission and egress. AI Act Article 15, NIS 2 Article 21 and the Cyber Resilience Act make the layer a demonstrable obligation. |
Chapter 16, Security for AI Systems |
| F40 |
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 |
| F41 |
Every threat names a control, every control a configuration, and every configuration produces evidence; the threat model lives in the repository and fails the pipeline when a threat has no control or a control no owner, a code-ownership rule routes changes to its review triggers to the security architect, and the control catalogue maps to ISO/IEC 27001, ISO/IEC 42001, ENISA's framework and the regulations. |
Chapter 17, AI Security Engineering in Practice |
| F42 |
In the platform's code the security architect is already a named owner of boundaries rather than a reviewer of documents: of the bypass list and token policy, the scanning thresholds, egress and workspace isolation, and the pre-production security checklist run against the pull request that introduces an AI system. |
Chapters 8, 9, 15 and 16 |
| F43 |
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 |
| F44 |
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. Deployers ask providers of general-purpose AI models for their Article 55 evidence and test the compound system themselves. |
Chapter 20, Evaluation and Testing of AI Systems |
| F45 |
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 |
| F46 |
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 reporting deadlines of NIS 2, the AI Act, DORA and the Cyber Resilience Act are design constraints on the logs. |
Chapters 17 and 21 |
| F47 |
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. |
Chapter 13, Infrastructure, Compute and European Digital Sovereignty |
Foundations from AI Red Team (Book 4)
| ID |
Conclusion |
Where it is made |
| F48 |
AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control with evidence. |
Chapter 28, Conclusions: AI as an Active Part of Cyber Defence |
| F49 |
The usage mode, not the model, sets the risk: in Modes 1 to 3 AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider. AI changes the work of red, blue, purple and white teams but not their accountability. |
Chapter 6, Roles, Usage Modes and Autonomy Levels; Chapter 28 |
| F50 |
Five autonomy levels (Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous) are set per action from reversibility, blast radius, confidence and the decision tier. The line between Level 2 and Level 3 is the most important; Level 3 is defined by a codified playbook enforced by a policy decision point outside the model; Level 4 is never used for offensive or irreversible actions; the level is decided and recorded, not discovered. |
Chapter 6 |
| F51 |
Every machine identity has an owner, operators and an authority who are named people; at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it; NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool. |
Chapter 6 |
| F52 |
Human command is built, not assumed: an interruption path outside the system it stops, an override log, and approval quality measured by time to approval, rejection rate and reversals; where works councils have rights, those metrics are agreed first and reported in aggregate. |
Chapters 6 and 15 |
| F53 |
Skills erode when AI does most of the work, yet supervision and the degraded mode after a stop need them; people keep them by working a share of cases without assistance, and autonomy is paced to the skills available to supervise it. |
Chapters 6 and 15 |
| F54 |
Everything security AI reads may be written by the adversary; because prompt injection is architectural, the defence is a policy decision point outside the model, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling. |
Chapters 13 and 28 |
| F55 |
Threat models belong in code beside the architecture and are regenerated on change; AI proposes candidate threats at Level 1 Assisted; soundness is defined in advance (grounding, classification, mitigation family, likelihood and impact basis, completeness, stability); a named reviewer decides each candidate against its provenance, review quality is measured, and no AI accepts a threat, a risk or an exception. |
Chapter 10, AI-Assisted Threat Modelling and Risk Assessment |
| F56 |
Identity is the first line of protection against AI-enabled attackers: phishing-resistant authentication, agents with workload identities and task-scoped, short-lived credentials issued outside their runtime, delegated tokens that carry the task and the entity, and approvals confirmed by call-back rather than by appearance. |
Chapter 14, Identity, Authentication and Access for People, Agents and Machines |
| F57 |
Mode 0 is the blind spot: vendor AI in security products and managed services may already act at an effective autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on. |
Chapters 8 and 28 |
| F58 |
Recover is where AI changes the economics most: recoverability becomes a measured, continuously rehearsed property, every recoverability finding returns to Govern, Identify and Protect as a pull request, and recoverability belongs beside patch velocity in management reporting. |
Chapters 22 to 24 and 28 |
| F59 |
Security chaos engineering verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses across all six Functions. AI plans and evaluates experiments without estate credentials while narrow deterministic actuators act, and the safety boundaries (catalogued, reversible experiments, bounded blast radius, independent abort, out-of-band stop path, the platform as a tier-0 asset) are the design. It complements, and does not replace, threat-led penetration testing. |
Chapter 25, Security Chaos Engineering with AI |
| F60 |
Every finding, from an exercise, an AI red-teaming campaign, a chaos experiment or an incident, ends as a verified control, closed only when the re-test passes (the purple loop); a CSF profile kept as code maps each Category to the obligations it helps meet, so that boards and supervisors are answered from the programme's own evidence. |
Chapters 3, 26 and 27 |
| F61 |
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, and offensive work runs only under signed rules of engagement. |
Chapter 1; Chapter 7, Policy, Mandate and Rules of Engagement |
Foundations from AI Threat (Book 5)
| ID |
Conclusion |
Where it is made |
| F62 |
A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains; controls are classified verified, declared or failed. |
Chapter 30, Organisational Defences: Containment, Evidence and Decision Rights |
| F63 |
Decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows (minutes for an agent on a production estate); the right to stop must be cheaper to exercise than the right to continue, and a stop in good faith is never a failure. |
Chapter 30 |
| F64 |
A control-to-threat coverage matrix joins the threat register to the control catalogue, records shared dependencies so that two controls that fail together are not counted as two, and turns every gap into a finding. |
Chapter 30 |
| F65 |
The AI threat register holds scenarios with a path to harm, an owner, a decision tier and triggers, omits probability on purpose, separates exposure from influence, is reviewed on change, and reaches the board as one page with at most three decisions; it feeds the ORSA, the DORA ICT risk framework and the NIS 2 risk analysis by reference. |
Chapter 32, The AI Threat Register: Governing Scenarios as Code |
| F66 |
Relying on AI reduces effort, recall and, among those who trust the tool, checking; automation erodes the skills of the people who must catch its errors, and automating junior work removes the route by which experts are made. Drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level are the response. |
Chapters 6 and 14, Are We Getting Dumber?; Work, Skills and the Ironies of Automation |
| F67 |
Agents acting beyond their mandate are observable: the incidents of 2025 and 2026 share a pattern of mechanism (persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked), developers moved controls from the agent's compliance into the environment, and organisations should rehearse reconstructing an agent incident from their own logs. |
Chapters 25 and 35 |
| F68 |
Where models may behave differently under test, assurance cannot rest on any single evaluation: pre-deployment tests are layered with a shadow period, production monitoring, comparison of the agent's reports with the record and decoys that do not reveal themselves. |
Chapters 23 and 30 |
| F69 |
Small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists; a delegation register shows the sum of what has been delegated, and reversibility tests check that each delegation can be undone, with further delegation frozen where a test fails. |
Chapter 26, Gradual Disempowerment and Correlated Failure |
| F70 |
The series makes one argument: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible, and match autonomy to reversibility. The quiet harms at the scales of the mind and the organisation deserve attention first. |
Chapter 35, Conclusions: Is There Anything in It? |
| ID |
Conclusion |
Where it is made |
| F71 |
The security architect role is transformed, not abolished; what remains scarce, and defines the role, is accountable human judgement, the ability to verify code and AI output and to answer for the decision. |
Chapters 1 and 27 |
| F72 |
Four shifts describe the transformation: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team. |
Chapter 3, Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
| F73 |
A role is itself a versioned artefact: a role charter with mandate, accountabilities and decision rights, a control catalogue, mandate manifests for the role's agents, competence records and decision records. |
Chapters 4, 9, 13 and 21 |
| F74 |
Boundaries are designed to hold whatever anyone, human or agent, intends; routine decisions are delegated to pipelines and forums under written decision rights, gates instead of meetings. |
Chapters 7 and 17 |
| F75 |
An agent team works under a written mandate manifest at an autonomy level matched to reversibility; the person who conducts it remains the accountable verifier of everything it proposes. |
Chapter 13, An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
| F76 |
Verifying what AI proposes when the reviewer depends on the AI requires independent reproduction, seeded errors, an oversight-quality metric and review that does not start from the AI's answer; automation bias is documented and must be designed against. |
Chapter 14, Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
| F77 |
Keeping the craft is a design decision: unassisted practice, apprenticeship routes that survive the automation of junior work, and a record of what the practitioner can still do without AI. |
Chapter 15, Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| F78 |
European regulation places duties on named people and management bodies (NIS 2 Article 20, DORA Article 5, AI Act Article 26); someone must turn each article into a control, and accountability cannot be delegated to a system. |
Chapter 18, Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
| F79 |
Competence is evidenced by records of judgement exercised, not by certificates alone; competence records and frameworks (ECSF, SFIA) make it reviewable. |
Chapters 21 and 22 |
| F80 |
Outlooks on a role carry the labels observable, expected or speculation; the role persists wherever accountability for a boundary must be human. |
Chapters 23 and 27 |
Foundations from AI Boss (Book 7)
| ID |
Conclusion |
Where it is made |
| F81 |
AI may direct work but may not, on its own, decide about people: direction can be delegated up to Level 3 Bounded where constraints sit in the optimiser, while every management function that carries consequences for a person has a named human decider who can be identified, contested and held to account; Level 4 Autonomous is never used for an M3 Consequence decision. |
Chapters 4 and 33 |
| F82 |
Management divides into five functions that can each be delegated, measured and governed separately: M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care; a delegation profile states the autonomy level per function. |
Chapters 2 and 4 |
| F83 |
Every management decision that AI makes or shapes about a person is a Management Decision Record the person can see, contest and have corrected; the delegation register records what has been delegated. |
Chapter 25, Management Decisions as Records |
| F84 |
Human oversight of decisions about people must be real, not rubber-stamped: it is measured by an oversight-quality metric, and an approval given in seconds is a signal of failure. |
Chapter 26, The Human in the Chair |
| F85 |
Contestability and transparency are designed in: explanation, appeal and correction paths, and worker information notices that tell people which systems manage them, drafted against AI Act Article 26(7) and the Platform Work Directive. |
Chapters 27 and 28 |
| F86 |
Monitoring and scoring of workers falls within co-determination and data-protection law: German co-determination under BetrVG §87(1) no. 6 reaches almost every system that is objectively suitable for monitoring, Swedish law obliges negotiation of important changes, and agreements should govern change classes rather than software versions; monitoring must meet tests of necessity, proportionality and information. |
Chapters 13 and 23 |
| F87 |
The manager's role is transformed, not abolished: from supervisor of tasks to accountable leader of people and conductor of agents, which applies Shift 4 of The Transformed Security Architect to every line manager. |
Chapter 29, The Transformed Manager |
| F88 |
When an agent orchestrates other agents, oversight of the last step is not oversight of the chain: the chain of accountability ends with a named person, and the agents a manager directs work under mandate manifests. |
Chapters 16 and 17 |
| F89 |
The quiet harms of algorithmic management, to autonomy, dignity, pace, health, voice and the willingness to speak, deserve attention before the loud ones; monitoring has a chilling effect and pace has a cost in health. |
Chapters 11, 13 and 14 |
| F90 |
The evidence on whether algorithmic management works is mixed: controlled studies show short-run gains for less experienced workers and limits for experts, targeted monitoring paid in one well-designed study but not as a general method, and European case studies find that outcomes depend on institutions and on whether workers took part in the design. |
Chapter 15, Does It Work? |
| F91 |
The series' one argument gains a sixth commitment: keep a named person in the chair for every consequence; the five management functions are the lasting frame and the employer's duty of care is never delegated. |
Chapter 33, Conclusions: Who Should Be the Boss? |
Foundations from AI Blue (Book 8)
| ID |
Conclusion |
Where it is made |
| F92 |
The blue team is transformed, not abolished: in every function AI takes a task and a person keeps a judgement that must be verified and answered for (B1 Anticipate: which hypotheses deserve engineering time; B2 Detect: a draft counts only after a passing test and a named approver; B3 Investigate: a conclusion that matters is reproduced from a second source; B4 Respond: a named incident commander holds what cannot be undone; B5 Learn: a finding closes on a passing re-test). The claim was held with qualifications; the book makes no promise about headcount. |
Chapters 5 to 11 and 28 |
| F93 |
The transformed team is an artefact: a charter (mandate, decision rights, what no system may do), a delegation profile per function and action class (the lowest ceiling governs, any unlisted action is undelegated), a delegation register that states the sum, and a reversibility test that checks each delegation can be undone. Lowering a level is immediate; raising one is a decision by a named authority. |
Chapter 4 |
| F94 |
The work moves from the queue alone to the queue and the loop: AI closes defined low-risk classes and leaves a residual queue plus the review of what it closed, and a loop with no cap on open drafts is another queue (131 drafted detections in a half-year, 52 merged, 79 open before a cap in the illustrative Hansa year). That treating each alert as evidence of a detection not yet engineered reduces load over time is a hypothesis, not a result. |
Chapters 6, 7, 26 and 28 |
| F95 |
A detection is a record with logic, data sources, ATT&CK mapping, tests, owner, alert budget and review date, and it counts only when a recent test shows that it fires and a measure shows what it costs. The classification of controls as verified, declared or failed applies unchanged to detections; supplier detections are Mode 0 and stay declared until the contract grants provenance, logic, tuning and test rights; detection debt is a generated register. The rate of new detections is bounded by the rate at which the team can test them. |
Chapters 6 and 11 |
| F96 |
Closure of alerts is delegated by class, under a closure policy that states the definition, the evidence to close, the level, the owner, the sampling and seeding rates and a stop condition written as numbers, enforced by a policy decision point outside the model. Quality is shown by measures speed cannot buy: escape rate by class, seeded-incident catch rate, retrospective audit and reopen rate, read together with the oversight-quality metric. A blank in the case record is a finding. |
Chapter 7 |
| F97 |
Managed triage with embedded vendor AI is the Mode 0 blind spot in practice, and the answer is a contract. Annex MS-2 turns it into six terms (levels and actions, quarterly sampling, audit rights, evidence, tuning and test rights, 20 working days' notice of a model change) plus conditions for data and exit. Whatever the operating model, detection content, decision rights for containment and disclosure, the case record, the ability to leave and enough skill to supervise stay with the organisation. |
Chapters 7 and 16 |
| F98 |
Autonomy in response is matched to reversibility: actions are classified into five classes, the ceiling is set by the lowest answer to five questions, Level 3 Bounded is reserved for preservation and narrow reversible actions inside a playbook enforced by a policy decision point outside the model, wide, business-critical and person-related actions stay at Level 2, and irreversible or external actions are taken by a named person. The playbook manifest carries the authority; approval moves to the playbook and its owner; the team has no response agent, because containment is a playbook run by the orchestration layer. |
Chapters 10 and 13 |
| F99 |
Verifying what AI concludes when the analyst depends on AI to read the data requires: soundness defined in advance; review that does not start from the AI's answer; independent reproduction of the key fact by another route; a critique agent on a different model family for questions, not verdicts; seeded errors and seeded incidents with a stop rule that freezes delegation when the catch rate falls; and caps, back-pressure and rotation so that review stays real at volume. Because these measures concern people, they are agreed with employee representatives first and reported in aggregate. |
Chapter 14 |
| F100 |
Accountability for a missed closure rests first with the class owner and those who designed the review and granted the level, then with the reviewer, but only if the process allowed real review; the oversight record makes the chain visible. Responsibility does not pass to a tool (NIS 2 Article 20, DORA Article 5). |
Chapters 4, 14 and 28 |
| F101 |
The defenders' AI is part of the estate that is defended: the SOC reads text that adversaries can write, so its agents are privileged insiders that can be steered. The controls sit outside the model: inputs classified by who can write them, a policy decision point enforcing a containment profile scoped to the case, deterministic corroboration of any conclusion that triggers an action, egress denied by default, short-lived credentials, canaries, and the SOC platform treated as a tier-0 asset. They bound suppression, action and disclosure; they do not bound misdirection, which is why review (F99) and the controls must be read together. |
Chapter 15 |
| F102 |
A finding closes when the re-test passes and not before. Every detection built from an exercise carries the exercise's scenario as a regression test, which is what separates a purple loop from a set of exercise reports: a report records that a technique was missed, a loop leaves behind a test that it will not be missed again and the date on which that was last shown. Chaos experiments extend the loop to the machinery around the detection (log sources, connectors, rollback, the stop path). |
Chapter 11 |
| F103 |
Learning is measured by the time from finding to verified control, the recurrence of conditions and the share of controls verified, reported for the team and never for the individual; the number of findings opened or closed is not a measure of learning. One named role is accountable for the age of the register; the red team or external tester is accountable for the quality of findings, not for their closure. |
Chapters 11 and 20 |
| F104 |
The purple team coordinator is a role of the blue team's loop: it schedules exercises, makes sure that findings reach the detection engineer and the playbook owner in a form they can act on, and tracks the age of open findings. Where there is no red team, the coordinator is the person who commissions and receives the penetration test and any contracted exercise, a fraction of the detection owner's duties. |
Chapters 11 and 17 |
| F105 |
Time to detect, time to respond, closure rate and alert volume reward closing alerts faster, and AI makes that the cheapest thing a SOC can do. Four families of measure replace them: speed on verified incidents, coverage as a map of verified, declared and failed cells with a test date, quality of judgement, and learning. Every measure carries a gaming check; benchmarks give direction, never targets; the board sees one page with at most three decisions, each traced to a measure; measures about people are agreed first, reported in aggregate and never per named analyst. |
Chapter 20 |
| F106 |
Regulation reaches the blue team as clocks, records and named people (NIS 2 Articles 20, 21 and 23; DORA Articles 5 and 17 to 19; Regulation (EU) 2024/2847 Article 14; GDPR Articles 32 to 34 and 88; AI Act Articles 4, 14, 26 and 73). One incident can open several clocks, so the case record carries one clock per regime with its own start, limit, owner and state, opened at the earlier of two awareness timestamps; AI drafts notifications and a person classifies and sends; the management body delegates the work and never its accountability. |
Chapter 19 |
| F107 |
Decision rights are requirements with a holder, a deputy and a second deputy, a response time, an evidence standard and a record, set from the speed of the threat and the shortest applicable clock. The right to stop is held by a named set of people, needs no approval or prior justification and costs the organisation, not the individual, if it proves unnecessary; continuing after a stop needs the owner, who restarts at a lower level. A Level 3 playbook decides only what the delegation lists, with the delegator named, and escalates everything else through a packet whose routing it cannot change. |
Chapter 18 |
| F108 |
The tier-1 pyramid was a response to alert volume and a school for the craft. Its functions divide into closure by class, sampling and review, the residual queue and learning what normal looks like; the roles that grow are detection engineer, investigation lead, incident commander, agent operator and intelligence analyst, and the new roles include the purple team coordinator and the evaluation engineer. The expected shape is a diamond whose weak point is the entry rung. Competence is evidenced by exercises, not certificates, and with fewer than two evidenced holders per site a Level 3 class falls back to Level 2. |
Chapters 17 and 22 |
| F109 |
The apprenticeship problem has two halves: where the next analysts come from if closure by class removes the tier-1 queue, and how present experts keep a skill their own automation no longer exercises. That unexercised skill decays beside reliable automation is observable outside the SOC; that it does so for analysts is expected; that organisations stop hiring juniors is speculation and a risk. The design has a measured, randomised share of unassisted work, a craft register, and an apprenticeship route that offers a new first rung in writing and reviewing the tests of detections. |
Chapter 23 |
| F110 |
The analyst is a worker whose attention is the scarce resource; the research on alarm fatigue and burnout is small and mostly qualitative, and whether AI relieves or intensifies the load is open and depends on team design. Measures concern the system and not the person; tools that log every query and ranking of closures can profile the individual and fall within co-determination. |
Chapter 21 |
| F111 |
Sovereignty is tested by four properties and not by a postcode; hybrid models are observable, provider AI that acts at Level 3 across clients is expected, and a fully autonomous managed SOC with no named human decider is speculation. A contract right is only a promise until the first sample, seed or stop request shows it works. |
Chapters 16 and 28 |
| F112 |
The final test of the blue team has two questions, both answered from records and drills: can the team show who or what decided what, and can it stop what it has started and recover? The sixth commitment of the series applies twice in a blue team, to the incidents it handles and to the analysts the tools measure. |
Chapter 28 |
| F113 |
The author's labelled projection for 2036: by then the system is expected to read, correlate, draft and execute inside playbooks; the person conducting systems is expected to engineer, verify and learn; a person alone is expected to decide and answer for what cannot be undone, what is disclosed and what is decided about people. The form of the function (SOC, platform team or bought service), the pace and the entry route are speculation. The first refutation, and the highest bar, is multi-year outcome evidence that a team without a human able to verify and stop its AI does better. |
Chapters 24 and 28 |
| F114 |
The first evidence from a loop on the defenders' own AI: in the illustrative Hansa exercise RoE-HM-2027-SOC-01 the policy decision point denied the unscoped isolation that followed a planted instruction-like ticket, so the action control held, but the case store accepted unlabelled text and a second agent trusted a planted note (finding FND-HM-2027-014, severity high). Elsewhere in the year the stop drill of PIR-HM-0455 took 3 minutes 40 seconds against a target of 2 minutes and passed its re-test at 1 minute 46 seconds. Each defect in implementation needed a re-test; the rule held. |
Chapters 15, 26 and 28 |
AI Blue explicitly did not treat the tradecraft of the red and purple teams beyond what a blue team needs to design detections and tests (Chapter 28, "Limits of this book"). That boundary is where this book begins.
Open questions this book takes up
| ID |
Question |
Raised in |
| Q1 |
When AI sits on both sides of a test, what makes a result independent, and how is independence shown to a supervisor? |
AI Red Team, Chapter 26; AI Threat, Chapter 23; AI Blue, Chapter 14; Chapter 15 of this book |
| Q2 |
What does "covered" mean for a technique, and how long does evidence for it remain valid? |
AI Red Team, Chapters 3 and 26; AI Blue, Chapters 6 and 20; Chapter 17 |
| Q3 |
How can emulation run continuously in production without becoming an incident, and who may stop it? |
AI Red Team, Chapters 7, 12 and 25; AI Blue, Chapter 18; Chapters 6, 8 and 20 |
| Q4 |
How do DORA's threat-led testing and continuous automated testing relate, and what may a supervisor accept as evidence from the second? |
AI Platform and Security, Chapter 17; AI Red Team, Chapter 12; Chapter 21 |
| Q5 |
How does an organisation without a red team, with a provider's AI in its detection chain, run a loop it can trust? |
AI Red Team, Chapters 8 and 28; AI Blue, Chapters 7 and 16; Chapters 13, 19 and 22 |
| Q6 |
How are exercise findings protected when the findings register is itself a map of the estate? |
AI Blue, Chapter 15; Chapter 16 |
| Q7 |
If AI does the routine emulation and the routine detection work, where do the next red operators and detection engineers come from? |
AI Threat, Chapter 14; The Transformed Security Architect, Chapter 15; AI Blue, Chapter 23; Chapter 24 |
| Q8 |
Will red and blue remain separate functions in 2036, or converge into one engineering practice? |
The Transformed Security Architect, Chapter 23; AI Blue, Chapter 24; Chapter 25 |
| Q9 |
Does AI reduce or intensify the load, alert fatigue and exercise pressure on the people on both sides of the loop, and what must a team lead do about it? (Carried over, open in AI Blue, Chapter 28.) |
AI Boss, Chapters 14 and 29; AI Blue, Chapter 21; Chapter 23 |
| Q10 |
How do co-determination, data-protection and work-environment law apply to exercises that involve staff, and to the measuring of the people who run and defend against them? (Carried over from AI Blue, Chapter 28, question 8.) |
AI Boss, Chapters 13 and 23; AI Blue, Chapters 19 and 21; Chapters 18, 21 and 23 |
| Q11 |
How do digital sovereignty and the cross-border character of telemetry and findings shape where emulation and observation AI may run, and what may be shared with peers and CSIRTs without exposing a weakness? (Carried over.) |
AI Platform and Security, Chapter 13; AI Blue, Chapters 12 and 16; Chapters 16 and 22 |
| Q12 |
How far can Level 3 Bounded safely reach for catalogued emulation and for closure, and how quickly does a stop path decay unless it is drilled? (Carried over: "what is not proved is how far Level 3 can safely reach", AI Blue, Chapter 28.) |
AI Red Team, Chapter 6; AI Blue, Chapters 10 and 28; Chapters 6, 8 and 14 |
Vocabulary and artefacts to reuse
- The five stages of the purple loop (Chapter 4), named exactly: P1 Target (choosing threat-informed scenarios and priority techniques from intelligence, the threat register and risk); P2 Emulate (executing an adversary emulation plan, human-led or AI-assisted, or continuous breach-and-attack simulation, atomic tests and automated red teaming, under signed rules of engagement); P3 Observe (comparing what happened with what was expected, layer by layer, and raising a finding); P4 Improve (turning a finding into a detection, control, playbook or mandate change); P5 Verify (re-test, regression case and evidence). They map to the five record states of AI Red Team, Chapter 26: Finding is the output of P3, Control and Detection the output of P4, Re-test and Evidence are P5. They sit across the blue team functions of AI Blue (P3 to P5 feed B5 Learn; P4 changes B2 Detect and B4 Respond artefacts) and across NIST CSF 2.0. Every chapter in Parts II to V names, in its opening and its Summary, which stages it concerns.
- The closure rule. A finding is closed only when the re-test passes and the evidence is attached; an implemented but unverified control is reported as open (AI Red Team, Chapter 26; AI Blue, Chapter 11).
- The independence principle (Chapter 4, developed in Chapter 15): verification needs independence between the side that tests and the side that is tested, through different model families and data, human-authored novelty, seeded errors and gaps, held-out scenario sets and an evidence trail that a person can reproduce. It recurs wherever AI is on both sides of a check.
- Coverage with evidence age. No chapter states that something is covered without saying what was tested, when and with what result. Verified, declared and failed (AI Threat, Chapter 30) apply to coverage; "not tested" is a legitimate entry.
- Red, blue, purple, white. "Red team" emulates the adversary, "blue team" defends, "purple team" is the joint loop between them and never a third team that sits beside them, and the white team is the control group that governs an exercise (exercise controller, trusted agent; Chapters 6 and 20). The purple team coordinator (AI Blue, Chapter 17) is the named owner of the register of what the loop produces. AI red teaming is adversarial testing of AI systems; AI-enabled defence is the use of AI in defensive security operations.
- Degrees of delegation are the series' autonomy levels applied per stage and action class: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (AI Red Team, Chapter 6). A delegation profile states the level. Level 3 Bounded, defined by a codified playbook or rules-of-engagement manifest enforced by a policy decision point outside the model, is the ceiling for catalogued safe scenarios in production. Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise has been authorised to touch, or that targets a named person. Every chapter concerning P2 Emulate says what can be undone and who can stop it, outside the system being stopped.
- Usage modes Mode 0 Ambient AI, Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants, Mode 3 Agentic work tools, Mode 4 Built AI applications and Mode 5 Autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2). Every narrative chapter has an
### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table.
- Reused artefacts. Rules of engagement
RoE-* (AI Red Team, Chapter 7), findings FND-*, scenarios SCN-* (first used in AI Blue, Chapter 15, as SCN-SOC-T2-SECOND-ORDER-03), mandate manifests MND-*, delegation profiles DLG-*, role charters ROLE-*, competence records CMP-*, detection records DET-NR-* and DET-HM-*, case records CASE-*, playbook manifests PBK-*, hunt records HNT-*, post-incident reviews PIR-*, decision-rights files DRF-*, tabletop records TTX-*, threat register entries THR-* (AI Threat, Chapter 32), board pages BTP-* (AI Blue, Chapter 20), incident identifiers INC-NR-* and INC-HM-*, AI Decision Records (AIDR-NNNN, immutable and numbered; AI Platform and Security, Chapter 5) and Architecture Decision Records (ADR; Architecture as Code (Chapter 4)).
- New artefacts of this book (names fixed at bootstrap):
| Identifier |
What it is |
Chapter |
SCN-NR-*, SCN-HM-* |
Scenario record: technique set, source (intelligence or threat-register entry), expected outcome per layer, safety class, owner (extends the identifier first used in AI Blue) |
5 |
EMU-* |
Emulation plan or campaign record: scenarios, sequence, target scope, window, abort conditions |
7 |
COV-NR-*, COV-HM-* |
Coverage record per technique and environment: last tested, result, evidence reference, expiry |
17 |
PRP-* |
Purple session record: participants, scenarios, observed outcomes, decisions, findings raised |
9 |
REG-* |
Regression case: a closed finding as a repeatable test with variants and cadence |
11 |
EVD-* |
Evidence manifest for a re-test: signed result, telemetry references, reviewer |
11 |
MND-NR-EMU-*, MND-HM-EMU-* |
Mandate manifests for emulation and loop agents |
14 |
AIDR-0800 to AIDR-0899 |
AI Decision Records: AIDR-0800 to AIDR-0849 Nordvik Region, AIDR-0850 to AIDR-0899 Hansa Mutual (the next free ranges after AI Blue's 0700 to 0799) |
all |
- Observable / expected / speculation labels for any outlook (AI Governance, Chapter 22). The author's own projections are kept to Chapters 25 and 29 and labelled.
- Terminology. An emulation agent plans, executes a catalogued scenario or reports; it does not attack, intend, understand or suspect. "Decides" is used only for a system to which a decision was formally delegated, and the record then says who delegated it.
- Defensive only. Adversary behaviour is described by technique (MITRE ATT&CK and ATLAS identifiers) at the level needed to design scenarios, detections, controls and tests. The book contains no exploit code, malware, payloads, jailbreak or injection strings, phishing kits or step-by-step intrusion instructions; every offensive activity described is authorised, scoped by written rules of engagement, run against the organisation's own or contracted systems and ends in a defensive improvement. Covert monitoring of staff and defeating employee representatives' rights are never described as methods.
- This book does not use the science-fiction tropes or the evidence ladder of AI Threat, the four shifts of The Transformed Security Architect, the five management functions of AI Boss or the five blue team functions of AI Blue as red threads. It refers to the blue team functions where the loop changes a blue artefact, to Shift 4 where the practitioner conducts an AI team, and to the management functions where it discusses how the people on both sides are themselves measured (Chapters 18 and 23).
- The fictional organisations Nordvik Region and Hansa Mutual, with the blue team profile of AI Blue repeated unchanged and the purple profile added for this book in
EXAMPLE_ORGANISATIONS.md: how each runs or buys the loop, its scenario library, its exercises and the people the book follows.
Tables of contents for cross-references
Architecture as Code (Book 1): chapters most used
| Chapter |
Title |
| 4 |
Architecture Decision Records (ADR) |
| 6 |
Structurizr: Architecture Modelling as Code |
| 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 |
| 12 |
Compliance and Regulatory Adherence |
| 13 |
Testing Strategies for Infrastructure as Code |
| 15A |
Evidence as Code and Continuous Assurance |
| 17 |
Organisational Change and Team Structures |
| 18 |
Team Structure and Competency Development for IaC |
| 19 |
Management as Code |
| 20 |
AI Agent Team for Architecture as Code Initiatives |
| 24 |
Best Practices and Lessons Learned |
| 25 |
Future Trends in Architecture as Code |
| 26B |
Anti-Patterns in Architecture as Code Programmes |
| 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 |
AI Threat (Book 5)
| Part |
Chapter |
Title |
| I The Question |
1 |
Introduction: Are the Dystopias Coming True? |
|
2 |
A Century of Machine Dystopias: What Science Fiction Actually Warned About |
|
3 |
The Voices of Alarm and Calm: Who Is Warning, About What, and Why Now |
|
4 |
Weighing the Evidence and Disagreeing Well |
|
5 |
What AI Can and Cannot Do in 2026 |
| II The Human Mind |
6 |
Are We Getting Dumber? Cognitive Offloading and Critical Thinking |
|
7 |
Learning Without Struggle: Education, Children and Skill Formation |
|
8 |
Persuasion, Sycophancy and Manipulation |
|
9 |
Artificial Companions, Loneliness and Mental Health |
| III Society and Truth |
10 |
The End of Truth? Synthetic Content and the Information Ecosystem |
|
11 |
The Automated State: When Public Authorities Got It Wrong |
|
12 |
Discrimination at Scale: Bias in Automated Judgement |
|
13 |
Surveillance, Profiling and the Erosion of Privacy |
|
14 |
Work, Skills and the Ironies of Automation |
|
15 |
Inequality and the Concentration of Power |
|
16 |
Culture, Creativity and the Homogenisation of Thought |
|
17 |
The Physical Cost: Energy, Water and Materials |
| IV Humans Wielding Machines |
18 |
Cyber Offence at Machine Speed |
|
19 |
Biological and Chemical Uplift: The Hardest Question to Test |
|
20 |
Fraud, Impersonation and Influence Operations |
|
21 |
Autonomous Weapons and the AI Arms Race |
| V Machines Beyond Control |
22 |
Specification Gaming and Reward Hacking: Getting Exactly What Was Asked For |
|
23 |
Deception, Scheming and Evaluation Awareness: Can We Trust What We Test? |
|
24 |
Self-Preservation and Shutdown Resistance: HAL 9000 Under Laboratory Conditions |
|
25 |
Agents in the Wild: The Incidents of 2025 and 2026 |
|
26 |
Gradual Disempowerment and Correlated Failure |
|
27 |
Superintelligence, Loss of Control and the End of the World |
| VI The Response |
28 |
What Europe and the World Have Decided |
|
29 |
Frontier Safety Frameworks: What Developers Promise and What It Is Worth |
|
30 |
Organisational Defences: Containment, Evidence and Decision Rights |
|
31 |
Staying Capable: What Individuals, Families and Schools Can Do |
|
32 |
The AI Threat Register: Governing Scenarios as Code |
| VII The Verdict |
33 |
Nordvik Region and Hansa Mutual: Threat Conclusions |
|
34 |
What Going Well Looks Like |
|
35 |
Conclusions: Is There Anything in It? |
| Part |
Chapter |
Title |
| I The Role in Question |
1 |
Introduction: The Security Architect Transformed |
|
2 |
What the Security Architect Did: The Role Before the Transformation |
|
3 |
Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
|
4 |
The Transformed Role Defined: Mandate, Accountabilities and Decision Rights |
| II The Craft |
5 |
Security Architecture as Code: From Documents to Executable Design |
|
6 |
Threat Modelling Transformed: Continuous, Generated and AI-Assisted |
|
7 |
Designing Boundaries: Zero Trust and Containment for People, Agents and Machines |
|
8 |
Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority |
|
9 |
The Control Catalogue, Evidence and Assurance as the Architect's Artefacts |
|
10 |
Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design |
|
11 |
Resilience and Recovery by Design: The Architect's Share of Recoverability |
| III The Architect's AI Team |
12 |
The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3 |
|
13 |
An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
|
14 |
Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
|
15 |
Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| IV The Role in the Organisation |
16 |
The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams |
|
17 |
Design Authority, Decision Forums and Gates Instead of Meetings |
|
18 |
Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
|
19 |
Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers |
|
20 |
Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes |
| V Competence and Career |
21 |
Competences of the Transformed Security Architect: A Framework |
|
22 |
Learning Paths, Certification, Hiring and Upskilling |
|
23 |
The Future of the Role: Will There Be a Security Architect in 2036? |
| VI Experience and Conclusions |
24 |
Case Studies and Anti-Patterns |
|
25 |
A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual |
|
26 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
27 |
Conclusions: The Transformed Security Architect |
AI Boss (Book 7)
| Part |
Chapter |
Title |
| I The Question |
1 |
Introduction: Who Is the Boss? |
|
2 |
What a Manager Does: Five Management Functions and Who Performs Them |
|
3 |
From Scientific Management to Algorithmic Management: A Century of Managing by Measurement |
|
4 |
The AI Boss Defined: Management Functions, Degrees of Delegation and Accountability |
| II The AI Boss Today |
5 |
Platform Work: The Algorithm as Dispatcher |
|
6 |
The Warehouse and the Shop Floor: Pace, Rate and Monitoring |
|
7 |
Hiring by Machine: Screening, Scoring and Automated Interviews |
|
8 |
Performance Scores, Productivity Metrics and Dismissal by Algorithm |
|
9 |
Scheduling, Pay and the Allocation of Work |
|
10 |
Knowledge Work: The AI Manager Enters the Office |
| III What It Does to People |
11 |
Autonomy, Dignity and Control: Being Managed by a Machine |
|
12 |
Fairness, Bias and the Appeal That Never Comes |
|
13 |
Surveillance at Work and the Chilling Effect |
|
14 |
Health, Pace and Burnout: Occupational Safety Under Algorithmic Direction |
|
15 |
Does It Work? Productivity, Quality and the Evidence for Algorithmic Management |
| IV Managing Machines |
16 |
The Agent Boss: When the Team Is Software |
|
17 |
Orchestrators: AI Managing AI Agents and the Chain of Accountability |
|
18 |
The Mixed Team: People and Agents Under the Same Manager |
|
19 |
Skill, Judgement and Who Becomes a Manager When AI Does the Managing |
|
20 |
Decision Rights in the Management Chain: Who May Direct, Evaluate, Reward and Dismiss |
| V Europe's Answer |
21 |
The AI Act at Work: Annex III Point 4, Prohibited Practices and the Deployer's Duties |
|
22 |
Data Protection and the Platform Work Directive: The Right to a Human Decision |
|
23 |
Co-determination: Works Councils, Unions and the Nordic Model Meet the Algorithm |
|
24 |
Occupational Safety, Equality Law and the Public Authority as Employer |
| VI Designing the Accountable AI Boss |
25 |
Management Decisions as Records: Decision Records and the Delegation Register |
|
26 |
The Human in the Chair: Oversight That Is Real, Not Rubber-Stamped |
|
27 |
Contestability by Design: Explanation, Appeal and Correction |
|
28 |
Transparency to the Managed: What Workers Are Told, When and by Whom |
|
29 |
The Transformed Manager: Leading People When AI Directs the Work |
| VII Experience and Verdict |
30 |
A Year With the AI Boss: Nordvik Region and Hansa Mutual |
|
31 |
Case Studies and Anti-Patterns |
|
32 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
33 |
Conclusions: Who Should Be the Boss? |
AI Blue (Book 8)
| Part |
Chapter |
Title |
| I The Blue Team in Question |
1 |
Introduction: The Blue Team Transformed |
|
2 |
What the Blue Team Does: Five Functions, Tiers and the Alert Queue |
|
3 |
The Pressure on the Blue Team: Machine-Speed Adversaries, Alert Volume and Scarce Talent |
|
4 |
The Transformed Blue Team Defined: Mandate, Functions and Degrees of Delegation |
| II The Craft |
5 |
Anticipate: Threat Intelligence and Exposure at Machine Speed |
|
6 |
Detect: Detection Engineering as Code |
|
7 |
Triage Transformed: From Alert Queue to Verified Case |
|
8 |
Investigate: Hypotheses, Timelines and Evidence with AI |
|
9 |
Threat Hunting Transformed: Hypotheses, Data and Agents |
|
10 |
Respond: Playbooks, Bounded Containment and the Stop Path |
|
11 |
Learn: Post-Incident Review, Purple Teaming and Detection Debt |
| III The Blue Team's AI Team |
12 |
The Analyst's Own Use of AI: Querying, Drafting and Summarising in Modes 1 to 3 |
|
13 |
An AI Agent Team for the SOC: Skills, Mandates and Containment |
|
14 |
Verifying What the AI Concludes: Review for Soundness When the Analyst Depends on the AI |
|
15 |
Defending the Defenders' AI: Poisoned Telemetry, Hostile Tickets and the SOC as Tier 0 |
| IV The Team in the Organisation |
16 |
Operating Models: In-House, Managed, Hybrid and Sovereign Security Operations |
|
17 |
Team Design and Roles: After the Tier-1 Pyramid |
|
18 |
Decision Rights and Escalation: Who May Contain, Isolate and Disclose |
|
19 |
Regulation as Constraint: NIS 2, DORA, CRA, GDPR, the AI Act and the Reporting Clock |
|
20 |
Measuring the Transformed Blue Team: Speed, Coverage and Quality of Judgement |
| V People and Career |
21 |
The Analyst at Work: Fatigue, On-Call and Being Managed by Metrics |
|
22 |
Competences, Training and Exercises: A Framework for the Transformed Blue Team |
|
23 |
Keeping the Craft and Making New Analysts: The Apprenticeship Problem |
|
24 |
The Future of the Blue Team: Will There Be a SOC in 2036? |
| VI Experience and Conclusions |
25 |
Case Studies and Anti-Patterns |
|
26 |
A Year on the Blue Team: Nordvik Region and Hansa Mutual |
|
27 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
28 |
Conclusions: The Blue Team Transformed |