Series Foundations: What This Book Builds On
This is a reference for authors and editors, not a manuscript chapter. AI Operations is Book 10 of The Transformed Architecture. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question that each of them touched from the outside: what happens to IT operations, the function that keeps services running every day, when AI takes part in observing, diagnosing, changing and restoring them, and when the operator's own AI becomes one of the most privileged workloads in the estate? This document records the conclusions the book builds on with stable identifiers (F1 to F141, grouped by volume), the open questions that the earlier volumes left or that this book raises (Q1 to Q10), the artefacts and vocabulary the book reuses, a map from each chapter of this book to the foundations it takes over, and the tables of contents used for cross-references. BOOK_BLUEPRINT.md maps every chapter of this book to the foundations it builds on, and DISPOSITION.md fixes the design.
The series
| No. | Book | Repository | Website |
|---|---|---|---|
| 1 | Architecture as Code | Geonitab/architecture_as_code | https://aac.geon.se |
| 2 | AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities | Geonitab/AI-governance | https://aig.geon.se |
| 3 | AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities | Geonitab/AI-platform-security | https://aips.geon.se |
| 4 | AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities | Geonitab/Ai-red | https://aired.geon.se |
| 5 | AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities | Geonitab/Ai-threat | https://aithreat.geon.se |
| 6 | The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities | Geonitab/Transformed-security-architect | https://tsa.geon.se |
| 7 | AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities | Geonitab/Aiboss | https://aiboss.geon.se |
| 8 | AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities | Geonitab/Ai-blue | https://aiblue.geon.se |
| 9 | AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities | Geonitab/Ai-purple | https://aipurple.geon.se |
| 10 | AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities (this book) | Geonitab/Ai-operations | https://aiops.geon.se |
The series builds strictly in publication order, so that there is no circular reasoning between the books. This book is Book 10 and builds on Books 1 to 9; 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, AI Blue and AI Purple as (Nordqvist, 2026), each through its own entry in docs/34_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 14"; "The Transformed Security Architect, Chapter 14"; "AI Boss, Chapter 26"; "AI Blue, Chapter 11"; "AI Purple, Chapter 15"), 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 nine earlier volumes are about systems and about the people who govern, secure, assess, architect, manage, defend and verify 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, and treated recovery as a property to be rehearsed (Chapters 22 to 25). AI Threat asked whether the dystopias are coming true and found the quiet harms, including the erosion of skill beside reliable automation, the most deserving of attention. The Transformed Security Architect described the role that designs the boundaries, AI Boss asked what happens when AI takes the manager's chair, AI Blue described the team that defends, and AI Purple described the loop that verifies the defence and gave the series its independence principle.
None of them takes as its subject the function that keeps services running every day. Operations is where AI is arriving fastest and with the least ceremony: observability platforms correlate events and propose root causes, incident assistants summarise and draft, coding agents author the change that operations must approve, remediation agents restart, scale, roll back and fail over, and operations is also where the organisation's AI systems themselves are run, with models updated by their providers without notice. AI Operations takes operations as its subject. Its premise is that operations has long been the place where loops are closed without a person in them, auto-remediation being the first widely accepted form of delegated machine action, so the lessons of delegation can be tested against decades of experience of what automated operations does to the operators who supervise it.
The book divides operations into five functions, named exactly so in every chapter that uses them: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain (Chapter 4). They sit across the traditional service management processes and across the Respond and Recover Functions of NIST CSF 2.0. The delegation of each function to AI is a degree, using the series' autonomy levels, so that a delegation profile states per function and action class how far a given capability has been allowed to go, and the budget of that autonomy is consumed by errors in the way an SRE error budget is.
Its working thesis, tested in Parts II to V and judged in Chapters 27 and 31, has five parts. First, operations is transformed, not abolished: the work moves from the queue to the control loop, from handling tickets and alerts to designing, bounding and verifying closed loops. Second, autonomy is matched to reversibility and blast radius and has a budget; Level 4 Autonomous is never used for an irreversible action on production data, for an action outside an authorised change window or freeze on a critical function, for an action that disables the observation or the stop path itself, or for an action that decides about a named person's access to work. Third, the operator's AI is part of the estate it operates: remediation agents, observability pipelines, runbook libraries and configuration maps are Tier 0 assets. Fourth, a loop closed by machines alone can hide its own failure, so what verifies an operations action must be independent of what performed it (the observer principle, the operations form of the independence principle of AI Purple). Fifth, resilience is a claim that needs evidence, as does the operator's competence: untested is not recoverable, and a skill not exercised decays. The thesis would be shown wrong by independent incident data over several years showing that fully autonomous remediation, with no human exercise of manual operation and no independent verification, yields fewer and shorter customer-impacting incidents and less severe tail events than a loop that keeps those properties, or that operators who do not practise manual recovery handle novel failures as well as those who do. 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 27 and 31.
"DORA" in this book means Regulation (EU) 2022/2554, the Digital Operational Resilience Act. The research programme of the same abbreviation is written "the DevOps Research and Assessment (DORA) programme" at first use in Chapter 20 and "the four key metrics" thereafter.
How the parts of this book take over the foundations
| Part | Chapters | Foundations taken over |
|---|---|---|
| I The Operations in Question | 1 to 4 | F34, F48 to F50, F93, F115 to F118 (mandate, delegation profile, autonomy levels, the observer principle from the independence principle); F5, F10, F59, F66 for the pre-AI baseline of Chapter 2; F35, F36, F47, F94 for the pressure in Chapter 3 |
| II The Craft | 5 to 12 | O1 (5, 6): F4, F20, F54, F76, F95, F99, F119, F125; O2 (7): F76, F84, F99, F100, F125; O3 (8, 9): F3, F7, F12, F29, F37, F121, F124; O4 (10): F50, F58, F98, F121, F122, F127; O5 (11, 12): F47, F69, F102, F103, F116, F126, F140 |
| III Operating AI Systems | 13 to 15 | F15, F16, F44, F46, F57, F97, F111, F128, F129 (operating AI as the operated; incidents; economics) |
| IV The Operator's Own AI | 16 to 18 | F12, F27, F45, F51, F75, F88, F98, F130 (agent team, mandates, containment); F62, F63, F68, F118 (the observer principle); F39, F40, F54, F56, F101, F131 (the operator's AI as Tier 0) |
| V Operations in the Organisation | 19 to 24 | F58, F59, F62, F119, F127 (resilience as a claim); F105, F132 (measures); F10, F22, F97, F133 (operating models); F17, F18, F19, F107, F134 (decision rights); F46, F78, F106, F135 (regulation); F47, F57, F111, F136 (across boundaries) |
| VI People and Career | 25 to 27 | F52, F53, F66, F86, F89, F110, F137 (people on call); F77, F79, F108, F109, F138 (competence and the craft); F32, F33, F80, F113, F139 (outlook labels and the author's projection) |
| VII Experience and Conclusions | 28 to 31 | F28, F67, F114, F140, F141 (cases and anti-patterns); F70, F91, F112 (the series' argument closed for operations); 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 |
Foundations from AI Platform and Security (Book 3)
| 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? |
Foundations from The Transformed Security Architect (Book 6)
| 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 |
Foundations from AI Purple (Book 9)
| ID | Conclusion | Where it is made |
|---|---|---|
| F115 | Purple is a loop, not a team: five stages, P1 Target, P2 Emulate, P3 Observe, P4 Improve and P5 Verify, each producing a record (scenario, emulation plan, finding and purple session record, change, regression case with evidence manifest). AI moves the loop from the event to the pipeline and keeps the event. The five states of AI Red Team, Chapter 26, map to P3 to P5, and P3 to P5 are the exercise-driven half of B5 Learn. The same shape, a loop with named stages and records, is what this book gives operations. | Chapters 1 and 4 |
| F116 | The closure rule has four clauses: a finding is closed only when the re-test passes, the evidence is attached, a named person signs and the closure carries an age. Five states keep it auditable (open, implemented but unverified, re-test failed, closed and verified, risk accepted); an implemented but unverified change is reported as open, and an accepted risk is reported apart from closure. | Chapters 4 and 11 |
| F117 | Before AI the six forms of testing (penetration test, red team engagement, threat-led test, tabletop, purple session, breach-and-attack simulation) were strong at Target, Emulate and Observe and weak at Improve and Verify; the report was the end of the loop and closure had no owner. The rhythm assumed that exploitation took longer than the interval between tests; time-to-exploit measured 63 days, then 32, then 5, and AI changes the cost of variation and repetition, not of novelty, judgement, independence or safety. | Chapters 2 and 3 |
| F118 | The independence principle: a check counts as verification only when its failure modes are shown not to be those of the thing it checks. Independence has several dimensions (model, data, authorship, vendor, time) and is shown by held-out scenarios written by people, seeded gaps and seeded errors, layering against test-aware behaviour, and reproduction by a person from the evidence manifest. A loop closed by machines alone can show that something known to work still works; it cannot by itself show that its coverage is real. The statement of independence is quarterly and carries an expiry. | Chapters 4 and 15 |
| F119 | Coverage is a claim with five parts (a technique, an environment, a result at a named layer, a date and an expiry); a heat map without age and evidence is not a coverage statement. The coverage record is derived, with six statuses computed by rule (verified, expired, implemented but unverified, failed, asserted, untested), and only a verified record counts as covered. Evidence expires by clock and by condition (a change in a log source, connector, parser, agent model or provider model); "not tested" is counted in the denominator; the board sees the denominator, five counts, the age distribution and at most three decisions. Resilience in this book takes the same form. | Chapter 17 |
| F120 | Rules of engagement are the first design question of emulation: authorisation by a named authority in a signed manifest separate from the agent's mandate; scope as code enforced by a policy decision point that fails closed; safety classes (S1 benign and reversible, S2 reversible with bounded side effects, S3 may disturb service and never in production, S4 irreversible or involving staff or third parties and range only). Production and pre-production are different evidence; third parties consent through contracts and notices the manifest records. | Chapter 6 |
| F121 | The stop path runs outside the system it stops, is held by named people who need no approval, is timed (seconds for a pipeline, minutes for a human-led exercise) and drilled, and restart is a separate decision at a lower level. A stop in good faith is never a failure, and a stop path decays unless it is exercised. | Chapters 6, 13 and 20 |
| F122 | Delegation is a degree per stage and action class: ceilings of Level 2 Supervised for P1 and P4, Level 3 Bounded for catalogued S1 scenarios at P2, read-only observation at P3 and codified re-tests at P5. Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond the authorisation or that targets a named person. Authorisation, the stop, the closure of a finding and the authorship of novelty are not delegated at any level. | Chapters 4, 7 and 14 |
| F123 | The loop's roles are separate on purpose: the red team emulates, the white team governs and holds the stop path, the trusted agent answers "is this ours?", the purple team coordinator and the closure owner hold the register, and nobody marks their own work. The coordinator is a role and not a team; where a small team cannot keep the pairs apart it uses countersignature, sampling and a contract. | Chapters 4, 7, 19 and 20 |
| F124 | A pipeline is exposed to Goodhart's law: detections converge on the scenarios that test them. The responses are variation on purpose, a held-out share hidden from detection engineers, a telemetry tag detections cannot see and the generalisation gap as the honest number. Continuous regression is observable, AI-generated variants at scale are expected, replacement of the human red team is speculation; a protected share of human-led, novel work remains. | Chapters 8, 24 and 25 |
| F125 | Observation is comparison with a written expectation sealed before the result is shown; the ground truth is tagged, time-stamped from a trusted source and held outside the system observed. Each step ends in one of seven outcomes ordered by layer, "detected" demands the whole chain through triage and action, a telemetry gap is recorded at the layer where the event disappeared, and an agent that runs a scenario does not also grade it. | Chapter 9 |
| F126 | A finding becomes a change by a recorded decision (layer that failed, routes considered, route chosen, owner, reviewer, cost, expiry, regression case). AI drafts every kind of change and the bottleneck is review: caps on open drafts, a reviewer who is a named person and not the drafter, seeded errors, and the tester who authored a scenario does not tune the detection that answers it. The cost of a change is counted, and findings that cannot be fixed end in a compensating control, a recorded risk acceptance or a transfer, never in silence. | Chapter 10 |
| F127 | The exact re-test is necessary and insufficient: variants of path, context and rate, a held-out variant written by someone other than the fix author and a negative control turn a re-test into evidence about the technique. Regression cases run on change, on schedule and on intelligence and cannot be quietly removed (the ratchet); evidence is code, generated by the run, hashed, signed by a person, minimised, and reproducible by a person who was not in the room. | Chapter 11 |
| F128 | An AI system is watched as a compound system, by correlation across model, tools, data and identity. Scenarios target four classes (model and instructions, retrieval, tools, data and outputs); prevention and detection are recorded separately per layer; a control that held but was not seen is a finding; a passing evaluation is not a running detection; detections cover an agent acting beyond its mandate but not an agent steered within it. | Chapter 12 |
| F129 | A delegation to the defenders' AI is a standing claim that has to be re-shown after every change and lost quickly on failure. Six subjects (triage, investigation, drafting, playbook, stop path, provider's AI) are tested on correctness, grounding, restraint and robustness to hostile input, with restraint first wherever an action is delegated; the agent's own account is not the record; a provider's AI is tested through an injected-test clause that makes a contract right usable. | Chapter 13 |
| F130 | The loop's own AI is a team of up to eight narrow functions under per-agent mandate manifests: an identity of its own, tokens issued outside the agent, a catalogue binding, a separation list that implements independence, a never list that closes the routes by which an agent could change its own governance, budgets, circuit breakers and a drilled stop. Containment is judged by what the agent can reach whatever it intends, and shared dependencies are listed so that controls that fail together are not counted twice. | Chapter 14 |
| F131 | The loop's own assets (findings register, scenario library, emulation plans, coverage records, agent credentials) are tier 0: an adversary's best map of the estate and the records on which claims rest. The controls sit outside the agent: a register of record in its own store, handling classes FC-1 to FC-4 attached to content, access policy as code at a decision point, agents without standing access to open findings, a deterministic redaction gateway before any hosted model, scenario content pinned and signed as supply chain, canaries, and insider scenarios handled by separation of duties and attributable records, not by covert monitoring of staff. | Chapter 16 |
| F132 | Six measures describe the loop and none can be improved by running more scenarios (finding-to-control cycle time, finding half-life, first-attempt re-test pass rate, verified share within expiry, yield per exercise, detection debt); activity counts and a green percentage without a denominator mislead. Goodhart's law applies in four forms and AI makes the adversarial form faster; all measures are of the system, never per person, with a minimum group size and the catalogue agreed with representatives first. | Chapter 18 |
| F133 | Four operating models recur (in-house, contracted, hybrid, sovereign or sector) and an organisation runs a mixture, so the decision is made per stage and recorded with exit criteria. What must stay with the organisation is the coordinator, the closure owner, the white team, the register of record and the right to stop. Procurement buys the right to learn: the organisation owns the scenarios and findings, the supplier declares its AI, data are returned and destroyed, and the organisation can stop and leave. | Chapter 19 |
| F134 | A loop that decides more, and faster, needs a decision-rights file with a holder, a deputy, a time, an evidence standard and a record for each decision (ten in the loop). Position governs: the authoriser does not run, the acceptor neither authors nor closes, and nobody sets a coverage cell by hand. Risk acceptance is routed by severity with a reason, a compensating control and an expiry; an emulation that becomes an incident is stopped and handled like any other, and no alert is closed as an exercise without a match in the tag ledger. | Chapter 20 |
| F135 | Continuous emulation is not a threat-led test; its manifest, authority and evidence are kept apart from the test's, with a hold list that protects the test's secrecy. DORA Articles 24 to 27 and Delegated Regulation (EU) 2025/1190 specify testing and threat-led penetration testing; TIBER-EU is the framework behind it; an agent in a supervised test is the tester's tool and the supervisor is asked first. Agreements with staff govern classes of exercise, and a register that maps each obligation to a control, an evidence artefact with an age and an owner is re-verified against the live text every six months. | Chapter 21 |
| F136 | Crossing a boundary needs standing consent in the contract, notice before each run, and a stop held outside the system stopped on both sides; providers' published rules differ and change, so the protocol records the page, the date and the form. A log that cannot cross a border is a coverage gap; a change that belongs to a provider is a request proved by an injected test; sharing with peers is a choice of fields through a deterministic sanitiser and a person's release; disclosure routes are written in advance. | Chapter 22 |
| F137 | People on both sides of a loop are rewarded in opposite directions, so accountability is kept separate where independence needs it and the target is shared where learning needs it. A session is safe for the truth when the charter is written first, records name roles and not people, no result enters an appraisal and anyone may pause. Load is a design concern; staff exposed to exercises are protected by governance, and the large studies of phishing simulations found limited value in training individuals. | Chapter 23 |
| F138 | The evidence on skill beside automation is old in theory and recent in measurement (colonoscopy, school mathematics, a programming study), the effect depends on how the assistant is used and novices gain most. The question of erosion is open and the response is within the organisation's control: a protected human-led share, an apprenticeship route with rotation in both directions, a craft register tied to the agent's level and contracts that buy teaching with testing. | Chapter 24 |
| F139 | The future of the loop is kept as a horizon register in which every trend carries a label, a stage, evidence, a trigger, a posture and an owner. That independence is needed is expected; how it is provided (two teams with one loop, one engineering practice, a pipeline with a human verifier) is speculation; a vendor-run loop with no named human decider is speculation. The author's projection comes with five thresholds that would change it. | Chapter 25 |
| F140 | The loop fails in recognisable ways and each way is a step that looked reasonable: eight anti-patterns, among them the contract with no right to test, the emulation that leaves its scope, the coverage claim never tested, the register spread to many copies, the detection tuned until the scenarios pass, the session without a re-test, the verifier that shares the model and prompts of the thing it verifies, and the dashboard that hides evidence age. The controls are few: the closure rule, independence, evidence age, scope as code with an outside stop path, handling classes and a testing right. | Chapter 26 |
| F141 | The first year of the illustrative loop (labelled illustrative): at Hansa Mutual 27 of 34 priority techniques verified within expiry against 25 at the baseline, a finding half-life shortened from 46 to 37 days and a generalisation gap of 19 points; a restraint failure of a SOC agent lowered a level for 49 days; an independence re-test moved two cells to failed. At Nordvik Region 4 of 9 techniques tested within expiry, 14 of 15 seeded cases handled correctly by the provider and a stop that took 21 minutes against 15. The pattern is that the first honest numbers are lower than the first dashboards. | Chapters 13, 15 and 18 |
AI Purple explicitly took the loop between red and blue as its subject and the security function as its setting. IT operations as a whole, the observability, change, restore and capacity work that is not security, is where this book begins.
How AI Operations uses the foundations
Each chapter of this book (DISPOSITION.md, section 7) takes over the foundations below. O1 to O5 are the operations functions the chapter concerns.
| Chapter | Title | Functions | Foundations taken over |
|---|---|---|---|
| 1 | Introduction: Operations with AI | all | F15, F48, F49, F70, F115, F118, F119 |
| 2 | What Operations Did Before: Runbooks, ITIL, DevOps, SRE and AIOps | all | F5, F9, F10, F59, F66, F117 |
| 3 | The Pressure on Operations: Complexity, Dependency, Cost and Machine-Speed Change | all | F35, F36, F47, F58, F94, F110, F117 |
| 4 | The Operations Loop Defined: Five Functions, the Autonomy Budget and the Observer Principle | all | F34, F50, F51, F82 (as a pattern of functions), F93, F98, F115, F116, F118, F122 |
| 5 | Observe: Telemetry, Observability and Service Level Objectives | O1 | F4, F20, F37, F41, F95, F119, F125 |
| 6 | Observe with AI: Correlation, Anomaly Detection and Alert Noise | O1, O2 | F54, F76, F95, F96, F99, F105, F118, F125 |
| 7 | Diagnose: Triage, Root-Cause Analysis and the Incident Assistant | O2 | F21, F76, F84, F99, F100, F125, F127 |
| 8 | Change: Releases, Infrastructure as Code and AI-Authored Change | O3 | F3, F7, F12, F13, F29, F37, F75, F126 |
| 9 | Change Safely: Progressive Delivery, Freezes and Blast Radius | O3, O4 | F19, F29, F45, F59, F63, F121, F124 |
| 10 | Restore: Runbooks, Auto-Remediation and Recovery | O4 | F50, F58, F67, F69, F98, F121, F122, F127 |
| 11 | Sustain: Capacity, Cost, Energy and Lifecycle | O5 | F29, F47, F69, F105, F111, F132 |
| 12 | Sustain: Problem Management, Post-Incident Learning and Knowledge | O5, O2 | F2, F14, F102, F103, F116, F126, F140 |
| 13 | Operating AI Systems: Drift, Model Updates and Provider Change | O1, O3, O5 | F15, F16, F44, F46, F57, F97, F111, F128, F129 |
| 14 | Incidents Involving AI: Detection, Triage and Reporting | O2, O4 | F28, F46, F67, F106, F135, F136 |
| 15 | The Economics of AI Operations: Tokens, GPUs, Latency and Energy | O5, O1 | F30, F47, F67, F69, F111, F130 |
| 16 | An AI Agent Team for Operations: Skills, Mandates and Containment | O1 to O5 | F12, F27, F45, F51, F75, F88, F98, F101, F130 |
| 17 | The Observer Principle: Who Watches the Watcher | O1, O4 | F45, F62, F63, F67, F68, F76, F99, F118, F121, F129, F141 |
| 18 | Defending the Operator's AI: Remediation Agents, Credentials and the Control Plane as Tier 0 | O3, O4 | F37, F39, F40, F45, F54, F56, F101, F131 |
| 19 | Resilience as a Claim: Restore Tests, Game Days and Evidence Age | O4, O5 | F58, F59, F62, F116, F119, F127, F135 |
| 20 | Measuring Operations: The Four Key Metrics, SLOs, Toil and the Metrics That Mislead | all | F84, F89, F103, F105, F110, F132 |
| 21 | Operating Models: Platform Teams, SRE, Managed Services and Sovereign Operations | all | F10, F22, F97, F104, F108, F111, F133 |
| 22 | Decision Rights, Change Authority and the Incident Commander | O2, O3, O4 | F17, F18, F19, F63, F93, F100, F107, F134 |
| 23 | Regulation as Constraint: DORA, NIS 2, CER, the AI Act, the GDPR and the Data Act | all | F25, F46, F78, F86, F106, F135 |
| 24 | Across Boundaries: Cloud Providers, Managed Providers, Outages and Exit | O1, O4, O5 | F30, F47, F57, F97, F111, F136 |
| 25 | Operators as People: On-Call, Toil, Trust and Wellbeing | all | F52, F53, F66, F84, F86, F89, F90, F110, F137 |
| 26 | Competences and Keeping the Operator's Craft | all | F11, F26, F66, F77, F79, F108, F109, F138 |
| 27 | The Future of Operations: Will Anyone Be on Call in 2036? | all | F32, F33, F80, F113, F124, F139 |
| 28 | Case Studies and Anti-Patterns | all | F28, F67, F114, F140, F141 |
| 29 | A Year in Operations: Nordvik Region and Hansa Mutual | all | F102, F114, F141 |
| 30 | Nordvik Region and Hansa Mutual: Conclusions for Two Organisations | all | all foundations as needed; F33, F70, F91 |
| 31 | Conclusion | all | F70, F91, F112, F113, F139 |
Open questions this book takes up
| ID | Question | Raised in |
|---|---|---|
| Q1 | When AI both performs and verifies an operations action, what makes the verification independent, and how is it shown to a supervisor? | AI Purple, Chapter 15; AI Threat, Chapter 23; AI Blue, Chapter 14; Chapter 17 of this book |
| Q2 | What does "recoverable" mean for a service, how long does evidence of it remain valid, and how does it expire when the estate changes? | AI Red Team, Chapters 22 to 24; AI Purple, Chapter 17; Chapter 19 |
| Q3 | How far can Level 3 Bounded safely reach for restart, scale, roll back and fail over, how is the autonomy budget consumed, and how quickly does a stop path decay unless it is drilled? (Carried over: AI Purple, Chapter 13, and AI Blue, Chapter 28.) | AI Red Team, Chapter 6; AI Blue, Chapter 10; Chapters 4, 10 and 17 |
| Q4 | How are silent provider-side model updates operated as change, and what notice and test rights can a contract secure? | AI Platform and Security, Chapter 21; AI Blue, Chapter 16; Chapters 13 and 24 |
| Q5 | When an agent's action causes an incident, how do the reporting clocks of NIS 2, DORA, the AI Act and the GDPR apply, and who classifies? | AI Blue, Chapter 19; AI Purple, Chapter 20; Chapters 14 and 23 |
| Q6 | Does AI relieve or intensify the load of on-call, alert fatigue and toil, and what must a team lead do about it? (Carried over, open in AI Blue and AI Purple.) | AI Boss, Chapters 14 and 29; AI Blue, Chapter 21; AI Purple, Chapter 23; Chapter 25 |
| Q7 | How do co-determination, working-time and data-protection law apply to on-call rotas, operational metrics and the monitoring of the people who operate? (Carried over.) | AI Boss, Chapters 13 and 23; AI Blue, Chapter 21; Chapters 20 and 25 |
| Q8 | If AI does the routine operations work, where do the next site reliability engineers and incident commanders come from, and how is manual recovery kept in practice? | AI Threat, Chapter 14; The Transformed Security Architect, Chapter 15; AI Purple, Chapter 24; Chapter 26 |
| Q9 | How do digital sovereignty, concentration risk and the Data Act's switching rules shape who can operate a service when a provider fails, and what does an exit test show? (Carried over.) | AI Platform and Security, Chapter 13; AI Blue, Chapter 16; Chapter 24 |
| Q10 | Will anyone be on call in 2036, or will operations converge into provider-run autonomous operations with a human verifier? | The Transformed Security Architect, Chapter 23; AI Purple, Chapter 25; Chapter 27 |
Vocabulary and artefacts to reuse
- The five operations functions (Chapter 4), named exactly: O1 Observe (telemetry, service level objectives, detection of anomalies and of degradation); O2 Diagnose (triage, root-cause analysis, the incident assistant, "what changed"); O3 Change (releases, infrastructure as code, progressive delivery, freezes, AI-authored change); O4 Restore (runbooks, auto-remediation, rollback, failover, recovery); O5 Sustain (capacity, cost, energy, lifecycle, problem management, post-incident learning, knowledge). They sit across the service management practices of ITIL and ISO/IEC 20000-1 and across the Respond and Recover Functions of NIST CSF 2.0, and they are not a security taxonomy: security operations stays in AI Blue, and this book meets it at the boundary (incident roles, shared telemetry, joint exercises). Every chapter in Parts II to V names, in its opening and its Summary, which functions it concerns.
- The autonomy budget. Degrees of delegation are the series' autonomy levels applied per function and action class: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (AI Red Team, Chapter 6). The action classes are read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete and restore-overwrite (Chapter 4). A delegation profile (
DLG-*) states the level. The budget is consumed by errors in the way an SRE error budget is, and a stop path outside the system it stops is part of every design. Level 4 Autonomous is never used for an irreversible action on production data, for an action outside an authorised change window or freeze on a critical function, for an action that disables the observation or the stop path itself, or for an action that decides about a named person's access to work. - The observer principle (Chapter 4, applied in Chapter 17): what verifies an operations action must be independent of what performed it, the observer must not depend on the system observed, and the stop path must work when the platform does not. It is the operations form of the independence principle of AI Purple (Chapter 15).
- Resilience and competence as claims with evidence. No chapter says that a service is recoverable, a technique covered or an operator competent without saying what was tested, when and with what result. Verified, declared and failed (AI Threat, Chapter 30) apply to recoverability; "not tested" is a legitimate entry; evidence expires.
- 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 modesor### Across the degrees of delegationsubsection, normally a compact table. - Tier 0. The operator's AI (remediation agents, observability pipelines, runbook libraries, configuration maps, the control plane they use) is a Tier 0 asset (AI Platform and Security, Chapter 17): it holds the broadest credentials and the best map of the organisation.
- Reused artefacts. Mandate manifests
MND-*, delegation profilesDLG-*, role chartersROLE-*, competence recordsCMP-*, post-incident reviewsPIR-*, incident identifiersINC-NR-*andINC-HM-*, decision-rights filesDRF-*, tabletop recordsTTX-*, rules of engagementRoE-*, findingsFND-*, coverage recordsCOV-*, regression casesREG-*, evidence manifestsEVD-*, threat register entriesTHR-*, horizon registersHZN-*, 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 |
|---|---|---|
SVC-NR-*, SVC-HM-* |
Service record: owner, criticality, dependencies, SLOs, recovery objectives | 5 |
SLO-NR-*, SLO-HM-* |
Service level objective record with burn-rate alerts | 5 |
RBK-* |
Runbook manifest: level, preconditions, verification, rollback and stop path | 10 |
INC-NR-*, INC-HM-* |
Incident record with assistant contributions marked (identifier first used in earlier volumes) | 7, 14 |
CHG-NR-*, CHG-HM-* |
Change record, including AI-authored change with provenance and rollback plan | 8 |
PRB-* |
Problem record | 12 |
PIR-* |
Post-incident review with an action closure rule | 12 |
RST-NR-*, RST-HM-* |
Restore-test record: measured recovery time and point, date, result | 19 |
CAP-* |
Capacity and cost record with forecast, error and guardrail | 11, 15 |
OBS-* |
Observer manifest: independent probes, failure domains and the stop path | 17 |
MND-NR-OPS-*, MND-HM-OPS-* |
Mandate manifests for operations agents | 16 |
AIDR-0900 to AIDR-0999 |
AI Decision Records: AIDR-0900 to AIDR-0949 Nordvik Region, AIDR-0950 to AIDR-0999 Hansa Mutual (the next free ranges after AI Purple's 0800 to 0899) | all |
- Observable / expected / speculation labels for any outlook (AI Governance, Chapter 22). The author's own projections are kept to Chapters 27 and 31 and labelled.
- Terminology. An AI system in operations observes, correlates, flags, recommends, drafts, or executes a runbook; it does not suspect, intend, understand or judge. "Decides" is used only for a system to which a decision was formally delegated, and the record then says who delegated it.
- Defensive only. Failures are described by mechanism and outcome at the level needed to design controls and tests, never as step-by-step attack instructions. The book contains no exploit code, malware, payloads or injection strings. On-call, monitoring and performance measurement are discussed by what studies measured; 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, the five blue team functions of AI Blue or the five stages of the purple loop of AI Purple as red threads. It refers to the blue team functions and the purple loop stages where operations meets security operations or verification (incident roles, shared telemetry, game days and joint exercises), to Shift 4 where the operator conducts an AI team, and to the management functions where it discusses how operators are themselves measured (Chapters 20 and 25).
- The fictional organisations Nordvik Region and Hansa Mutual, with the blue team and purple profiles of the earlier volumes repeated unchanged and the operations profile added for this book in
EXAMPLE_ORGANISATIONS.md: how each runs or buys operations, its service catalogue, its providers, its on-call model 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 |
AI Platform and Security (Book 3)
| 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? |
The Transformed Security Architect (Book 6)
| 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 |
AI Purple (Book 9)
| Part | Chapter | Title |
|---|---|---|
| I The Loop in Question | 1 | Introduction: The Purple Loop with AI |
| 2 | What the Loop Did Before: Penetration Tests, Red Teams, Tabletops and Purple Sessions | |
| 3 | The Pressure on the Loop: Machine-Speed Adversaries, Detection Decay and the Annual Test | |
| 4 | The Purple Loop Defined: Five Stages, Evidence and the Independence Principle | |
| II The Stages of the Loop | 5 | Target: Threat-Informed Scenarios, Risk and Priority Techniques |
| 6 | Rules of Engagement and Safe Emulation: Scope, Blast Radius and the Stop Path | |
| 7 | Emulate: Adversary Emulation Plans, Human-Led and AI-Assisted | |
| 8 | Emulate Continuously: Breach-and-Attack Simulation, Atomic Tests and Automated Red Teaming | |
| 9 | Observe: Telemetry, Detection and Response Compared with Expectation | |
| 10 | Improve: From Finding to Change in Detections, Controls, Playbooks and Mandates | |
| 11 | Verify: Re-test, Regression and Evidence | |
| III The Loop Meets AI Systems | 12 | Purple for AI Systems and Agents: Attacks on Models and Detections That Catch Them |
| 13 | Testing the Defenders' AI: SOC Agents, Playbooks and Providers' AI under Emulation | |
| IV The Loop's Own AI | 14 | An AI Agent Team for the Loop: Skills, Mandates and Containment |
| 15 | Independence: Verifying the Loop When AI Is on Both Sides | |
| 16 | Defending the Loop's AI: Scenario Libraries, Findings and Emulation Agents as Tier 0 | |
| V The Loop in the Organisation | 17 | Coverage as a Claim: Technique Maps, Evidence Age and Detection Decay |
| 18 | Measuring the Loop: Cycle Time, Yield, Re-test Pass Rate and the Metrics That Mislead | |
| 19 | Operating Models and Team Design: In-House, Contracted, Hybrid and Sovereign Loops | |
| 20 | Decision Rights, Authorisation and the White Team | |
| 21 | Regulation as Constraint: DORA, TIBER-EU, NIS 2, the AI Act, the GDPR and Employee Rights | |
| 22 | Across Boundaries: Suppliers, Managed Providers, Sector Exercises and Authorities | |
| VI People and Career | 23 | Red and Blue as People: Trust, Incentives, Safety and Wellbeing |
| 24 | Competences, Training and Keeping the Red Craft | |
| 25 | The Future of the Loop: Will Red and Blue Be Separate Teams in 2036? | |
| VII Experience and Conclusions | 26 | Case Studies and Anti-Patterns |
| 27 | A Year in the Loop: Nordvik Region and Hansa Mutual | |
| 28 | Nordvik Region and Hansa Mutual: Conclusions for Two Organisations | |
| 29 | Conclusions: The Purple Loop with AI |