Series Foundations: What This Book Builds On
This is a reference for authors and editors, not a manuscript chapter. AI Boss is Book 7 of The Architecture as Code Series. It does not repeat the earlier volumes; it takes their conclusions as its starting point and asks a question none of them asked directly: what happens when AI takes the manager's chair, and when people in turn become the managers of AI agents? This document records the conclusions the book builds on with stable identifiers (F1 to F80, grouped by volume), the open questions that the earlier volumes left or that this book raises (Q1 to Q12), the artefacts and vocabulary the book reuses, and the tables of contents used for cross-references. BOOK_BLUEPRINT.md maps every chapter of this book to the foundations it builds on.
The series builds strictly in publication order, so that there is no circular reasoning between the books. This book refers to Books 1 to 6 and never to a later volume. It cites Architecture as Code as (Nordqvist, 2025) and AI Governance, AI Platform and Security, AI Red Team, AI Threat and The Transformed Security Architect as (Nordqvist, 2026), each through its own entry in docs/36_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 4)"; "AI Governance, Chapter 13"; "AI Platform and Security, Chapter 19"; "AI Red Team, Chapter 6"; "AI Threat, Chapter 26"; "The Transformed Security Architect, Chapter 13"), 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 six earlier volumes are about systems and about the people who govern them. Architecture as Code made architecture executable: decisions, policies, risks and evidence in version control, validated continuously. 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. AI Threat asked whether the dystopias are coming true, at every scale from the individual mind to the end of the world, and answered that the quiet harms deserve attention first. The Transformed Security Architect described what has happened to one role on which those conclusions depend, and concluded that the role is transformed, not abolished.
AI Boss is an extension of AI Threat. That volume treated work, skills and the ironies of automation (Chapter 14), surveillance and profiling (Chapter 13), the automated state (Chapter 11), gradual disempowerment and the delegation register (Chapter 26) and organisational defences, decision rights and containment (Chapter 30). It did not ask what happens when AI takes the manager's chair: when it directs, paces, scores, rewards, disciplines and dismisses people. That is no longer a question about the future. Algorithmic management is observable today in platform dispatch and deactivation, warehouse rate and time-off-task monitoring, automated hiring screens and interviews, productivity scores, algorithmic scheduling and pay, and, more recently, AI agents in the office that assign tasks, assess output and report on colleagues. At the same time people are becoming the managers of AI agents. Europe has answered in part, through the AI Act's treatment of AI in employment and worker management, the Platform Work Directive, the General Data Protection Regulation and national co-determination law.
The book divides management into five functions, named exactly so in every chapter that uses them: M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care. It treats the delegation of each function to AI as a degree, using the series' autonomy levels, so that a delegation profile states, per function, how far a given system or team has been allowed to go. Every management decision that AI makes or shapes about a person becomes a Management Decision Record (MDR), the sibling of the ADR and the AIDR of the earlier volumes, and what has been delegated is itself recorded in a delegation register of management functions.
Its working thesis, to be tested and judged in Chapters 29 and 33, has four parts. First, AI may direct work, but it may not, on its own, decide about people: the functions that assign and pace work can be delegated at a degree matched to reversibility, while the functions that carry consequences for a person always have a named human decider who can be identified, contested and held to account, and Level 4 Autonomous is never used for an M3 Consequence decision. Second, every management decision that AI makes or shapes about a person is a record the person can see, contest and have corrected. Third, 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. Fourth, the quiet harms to autonomy, dignity, pace, health, the skills of managers and the willingness of people to speak deserve attention before the loud ones. The thesis would be shown wrong by evidence that fully automated consequence decisions produce fairer and safer outcomes than human ones with records and appeal, or that algorithmic direction without human leadership sustains performance and wellbeing over years. 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 29 and 33.
Foundations from Architecture as Code (Book 1)
| ID |
Conclusion |
Where it is made |
| F1 |
Threat handling belongs in the codebase: threat intelligence is ingested as STIX/TAXII through pipelines, threat models are generated from architecture code, response playbooks are state machines (subscribe, assess, act, document), and findings return as pull requests. "Celebrate the remediation pull request, not just the discovery." |
Chapter 9C, Risk as Code and Threat Handling as Code |
| F2 |
Risk is a versioned record with likelihood, impact, owner and expiring exceptions; a failing control metric fails the pipeline. |
Chapter 9C |
| F3 |
Policy as Code (OPA/Rego) with "assure once, comply many": a control is written once and mapped to many obligations, with evidence linked to enforcement. |
Chapters 10 and 11, Policy and Security as Code in Detail; Governance as Code |
| F4 |
Evidence as Code: evidence is machine-collected, signed and versioned, not assembled in audit season. |
Chapter 15A, Evidence as Code and Continuous Assurance |
| F5 |
Manual incident response cannot scale when attacks develop within minutes; compromised components are redeployed from known-good definitions, and MTTD, MTTR and false-positive ratio are the programme metrics. AI models must themselves be defended against adversarial machine learning. |
Chapter 9B, Advanced Security Patterns and Implementation |
| F6 |
Security architecture has four dimensions that the codebase must carry: threat modelling, zero trust, Policy as Code and risk assessment. |
Chapter 9, Security Fundamentals for Architecture as Code |
| F7 |
Security and compliance tests, including synthetic attack simulations, run in the pipeline against ephemeral environments. |
Chapter 13, Testing Strategies for Infrastructure as Code |
| F8 |
Architectural decisions are kept as short, numbered, immutable Architecture Decision Records beside the code, with context, options and consequences, so that the rationale survives the people who made it. |
Chapter 4, Architecture Decision Records (ADR) |
| F9 |
Architecture as Code succeeds only with equal investment in people, process and technology. Modern roles blend engineering, governance and advocacy; security partners work from shared roadmaps and influence without direct authority; dual-ladder careers keep experts on technical tracks; resistance to change usually signals legitimate concerns about skills and job security. |
Chapter 17, Organisational Change and Team Structures |
| F10 |
Platform teams act as internal service providers that own the common toolchains, guardrails and reusable modules, so that product teams move quickly without sacrificing governance; the system design mirrors the organisation's communication paths (Conway's law). |
Chapters 17 and 18, Team Structure and Competency Development for IaC |
| F11 |
Competence is managed as a skills matrix by level (Foundation, Practitioner, Advanced, Expert) with interpersonal domains, in a development loop of assessment, planning, learning, application, knowledge sharing and measurement; certifications validate knowledge, while practical demonstration on real delivery shows capability. |
Chapter 18 |
| F12 |
AI agents are structured participants under human direction: "agents draft; humans approve", and exceptions and risk acceptances carry a named human approval in the audit trail. |
Chapter 20, AI Agent Team for Architecture as Code Initiatives |
| F13 |
Some decisions stay with people whatever the agents propose: architectural commitments with long-term consequences (platform lock-in, data residency, operational dependencies) are escalated by the Architect agent, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual. |
Chapter 20 |
| F14 |
The habit on which trustworthy programmes are built is making the implicit explicit: an AI-assisted decision without a traceable human rationale should receive an Architecture Decision Record, written retrospectively if necessary. |
Chapter 27, Conclusion |
Foundations from AI Governance (Book 2)
| ID |
Conclusion |
Where it is made |
| F15 |
AI governance is effective when it is codified, evidenced and proportionate to usage mode and risk; the usage mode, not the brand, sets the governance (Mode 0 Ambient AI to Mode 5 Autonomous production agents). |
Chapters 2 and 25 |
| F16 |
Classification is triggered by change, not by the calendar: a new model version, a drift alert, an incident, a regulatory change or a move between modes. |
Chapter 8, AI Risk Management and Classification as Code |
| F17 |
Decisions are tiered and routed to the lowest tier that can take them with evidence: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, risk beyond appetite at the management body. The tier policy is itself data, changed by pull request. |
Chapter 13, Decision Forums and Governance Bodies |
| F18 |
Governance as code does not remove forums; it changes what they are for. Pipelines enforce, observe and remember, while forums decide what pipelines cannot: appetite, policy, exceptions and residual risk. NIS 2 Article 20 and DORA Article 5 anchor oversight in a trained management body, and the AI architect acts as secretary of the design authority. |
Chapter 13 |
| F19 |
Stop decisions are named in advance: the on-call incident commander and the use-case owner may each stop a system unilaterally, restart needs the owner and, for high-risk systems, the risk function, and a stop path that runs inside the system it stops fails when it is needed. |
Chapter 13 |
| F20 |
Evidence is a by-product of delivery; the evidence manifest ties the chain together; attestation is a person asserting, evidence is machine-generated. |
Chapter 11, Evidence, Assurance and Audit |
| F21 |
Human oversight must be designed, not declared: an interruption path, an override log and the authority to use them. Approvals given in seconds are a signal of rubber-stamping. |
Chapters 10 and 21 |
| F22 |
Organisational design is architecture by other means (Conway's law). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode; control functions keep their independence through gates and records rather than meetings ("gates instead of meetings"), with exceptions routed as expiring records. |
Chapter 12, Organisational Design for AI |
| F23 |
The AI architect owns the seams between the architecture roles. The security architect keeps the threat model, identity, secrets and zero trust, and relies on the AI architect for AI-specific threats, guardrail policy, agent permissions and the model supply chain. |
Chapter 14, Competence, Roles and the AI Architect |
| F24 |
New roles follow the usage modes: the AI system owner, the agent operator who watches Mode 5 agents and may revoke their credentials, the skills curator and the evaluation engineer; existing roles such as procurement, internal audit and the data protection officer change. |
Chapter 14 |
| F25 |
AI literacy is role-specific and must be evidenced in a competence framework and individual records checked at the readiness gate. Article 4 of the AI Act, as amended by the Digital Omnibus, asks for measures that support literacy, but Articles 14 and 26(2) still demand competent oversight, and NIS 2 Article 20(2) and DORA Article 5(4) require management-body training. |
Chapter 14 |
| F26 |
Upskilling is the strategy and hiring is for scarce specialisms and the first AI architect; careers need a specialist ladder and a path between building and verifying with a cooling-off period; competence is assessed by practical demonstration, and assessment results are personal data whose use is agreed with employee representatives. |
Chapter 14 |
| F27 |
Govern every agent as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences. |
Chapters 19 and 25 |
| F28 |
The July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert that reached people who did not hold the stop decision. |
Chapter 19, A Cautionary Case: The OpenAI–Hugging Face Incident |
| F29 |
Patch decisions must be delegated in advance; a weekly change advisory board cannot sit in the path of known-exploited vulnerabilities, and patch velocity belongs in management reporting as a risk indicator. |
Chapter 24, Reflections on Each Part |
| F30 |
Model origin is a risk question separate from hosting: five categories of geopolitical risk, and a risk-tiered position that decides which models may handle which data, reviewed periodically rather than once. |
Chapter 6, Geopolitics and Model Origin |
| F31 |
In public authorities legality comes before capability: the line between decision support and automated decision is drawn in the data model and the audit log, every case has a reasons log, and the algorithm register is generated from version-controlled entries. |
Chapter 17, AI in Public Authorities |
| F32 |
An outlook is governed as a horizon register: each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; the register is valuable because it can be wrong in a reviewable way. |
Chapter 22, Future Trends |
| F33 |
The author's judgement is kept apart from the book's findings: projections that go beyond the evidence are labelled and placed in their own chapter. |
Chapter 24 |
| ID |
Conclusion |
Where it is made |
| F34 |
A platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation. |
Chapter 25, Conclusions: Building and Securing AI Platforms |
| F35 |
AI is both a target and a source of threat; every AI system is designed twice, as something to protect and as something to contain; security operations must run faster than a monthly patch cycle. Security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case (labelled speculation). |
Chapters 18 and 25 |
| F36 |
Four commitments against AI-enabled adversaries: patch velocity as a measured service level (EPSS, KEV, EUVD and local exposure); detection at machine speed, with canaries, honeytokens and the authority to act; identity and approvals that resist synthetic media; and AI for defence under oversight, in which human verification is the bottleneck. |
Chapter 18, When AI Is the Threat |
| F37 |
A reference architecture of five layers inside a control plane for identity, policy, observability and evidence, carried by the AI gateway, the model registry, the evaluation service and prompt and policy repositories; every tool is registered and its credentials held by the platform. Adaptations are overlays on a pinned baseline that may only tighten it, and the declarative model can be checked against the running estate. |
Chapter 4, A Reference Architecture for AI in Large Organisations |
| F38 |
AI Decision Records keep Nygard's discipline of short, numbered, immutable records, add the fields AI needs, are validated against a schema and re-opened by evidence; the architecture repository, not the document, is the single source from which Annex IV technical documentation is generated. |
Chapter 5, AI Decision Records, Model Cards and the Architecture Repository |
| F39 |
Security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance (ML-BOM, SLSA, signing), and agent containment through identity, permission and egress. AI Act Article 15, NIS 2 Article 21 and the Cyber Resilience Act make the layer a demonstrable obligation. |
Chapter 16, Security for AI Systems |
| F40 |
Prompt injection is a property of the architecture, not a patchable defect; controls sit outside the model; OWASP LLM Top 10 and MITRE ATLAS give the shared vocabulary; model loading is code execution. |
Chapter 16 |
| F41 |
Every threat names a control, every control a configuration, and every configuration produces evidence; the threat model lives in the repository and fails the pipeline when a threat has no control or a control no owner, a code-ownership rule routes changes to its review triggers to the security architect, and the control catalogue maps to ISO/IEC 27001, ISO/IEC 42001, ENISA's framework and the regulations. |
Chapter 17, AI Security Engineering in Practice |
| F42 |
In the platform's code the security architect is already a named owner of boundaries rather than a reviewer of documents: of the bypass list and token policy, the scanning thresholds, egress and workspace isolation, and the pre-production security checklist run against the pull request that introduces an AI system. |
Chapters 8, 9, 15 and 16 |
| F43 |
Red teaming of AI systems runs continuously in CI: the external exercise is for discovery, and every finding becomes a versioned attack case with explicit thresholds, published as evidence against control IDs. DORA threat-led penetration testing is periodic; continuous suites complement it. |
Chapter 17 |
| F44 |
Red teaming is the apex of the evaluation pyramid: a scenario library in version control, an automated harness, a route for human findings into scenarios, and a finding–remediation–re-test path. Deployers ask providers of general-purpose AI models for their Article 55 evidence and test the compound system themselves. |
Chapter 20, Evaluation and Testing of AI Systems |
| F45 |
Containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop, recorded approvals, and detection from telemetry and decoys rather than self-report. |
Chapter 19, When Your Own Agents Exceed Their Mandate |
| F46 |
AI incident management adds an AI classification step (AI Act Articles 3 and 73, DORA), an impact query against the event log and a path back to evaluation; the reporting deadlines of NIS 2, the AI Act, DORA and the Cyber Resilience Act are design constraints on the logs. |
Chapters 17 and 21 |
| F47 |
Digital sovereignty is a set of verifiable properties, not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. |
Chapter 13, Infrastructure, Compute and European Digital Sovereignty |
Foundations from AI Red Team (Book 4)
| ID |
Conclusion |
Where it is made |
| F48 |
AI strengthens cyber defence across every CSF Function when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control with evidence. |
Chapter 28, Conclusions: AI as an Active Part of Cyber Defence |
| F49 |
The usage mode, not the model, sets the risk: in Modes 1 to 3 AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider. AI changes the work of red, blue, purple and white teams but not their accountability. |
Chapter 6, Roles, Usage Modes and Autonomy Levels; Chapter 28 |
| F50 |
Five autonomy levels (Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded, Level 4 Autonomous) are set per action from reversibility, blast radius, confidence and the decision tier. The line between Level 2 and Level 3 is the most important; Level 3 is defined by a codified playbook enforced by a policy decision point outside the model; Level 4 is never used for offensive or irreversible actions; the level is decided and recorded, not discovered. |
Chapter 6 |
| F51 |
Every machine identity has an owner, operators and an authority who are named people; at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it; NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool. |
Chapter 6 |
| F52 |
Human command is built, not assumed: an interruption path outside the system it stops, an override log, and approval quality measured by time to approval, rejection rate and reversals; where works councils have rights, those metrics are agreed first and reported in aggregate. |
Chapters 6 and 15 |
| F53 |
Skills erode when AI does most of the work, yet supervision and the degraded mode after a stop need them; people keep them by working a share of cases without assistance, and autonomy is paced to the skills available to supervise it. |
Chapters 6 and 15 |
| F54 |
Everything security AI reads may be written by the adversary; because prompt injection is architectural, the defence is a policy decision point outside the model, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling. |
Chapters 13 and 28 |
| F55 |
Threat models belong in code beside the architecture and are regenerated on change; AI proposes candidate threats at Level 1 Assisted; soundness is defined in advance (grounding, classification, mitigation family, likelihood and impact basis, completeness, stability); a named reviewer decides each candidate against its provenance, review quality is measured, and no AI accepts a threat, a risk or an exception. |
Chapter 10, AI-Assisted Threat Modelling and Risk Assessment |
| F56 |
Identity is the first line of protection against AI-enabled attackers: phishing-resistant authentication, agents with workload identities and task-scoped, short-lived credentials issued outside their runtime, delegated tokens that carry the task and the entity, and approvals confirmed by call-back rather than by appearance. |
Chapter 14, Identity, Authentication and Access for People, Agents and Machines |
| F57 |
Mode 0 is the blind spot: vendor AI in security products and managed services may already act at an effective autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on. |
Chapters 8 and 28 |
| F58 |
Recover is where AI changes the economics most: recoverability becomes a measured, continuously rehearsed property, every recoverability finding returns to Govern, Identify and Protect as a pull request, and recoverability belongs beside patch velocity in management reporting. |
Chapters 22 to 24 and 28 |
| F59 |
Security chaos engineering verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses across all six Functions. AI plans and evaluates experiments without estate credentials while narrow deterministic actuators act, and the safety boundaries (catalogued, reversible experiments, bounded blast radius, independent abort, out-of-band stop path, the platform as a tier-0 asset) are the design. It complements, and does not replace, threat-led penetration testing. |
Chapter 25, Security Chaos Engineering with AI |
| F60 |
Every finding, from an exercise, an AI red-teaming campaign, a chaos experiment or an incident, ends as a verified control, closed only when the re-test passes (the purple loop); a CSF profile kept as code maps each Category to the obligations it helps meet, so that boards and supervisors are answered from the programme's own evidence. |
Chapters 3, 26 and 27 |
| F61 |
Writing about offensive capability stays defensive: adversary behaviour is described by technique at the level needed to design controls, never as exploit code, payloads, jailbreak strings or step-by-step instructions, and offensive work runs only under signed rules of engagement. |
Chapter 1; Chapter 7, Policy, Mandate and Rules of Engagement |
Foundations from AI Threat (Book 5)
| ID |
Conclusion |
Where it is made |
| F62 |
A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains; controls are classified verified, declared or failed. |
Chapter 30, Organisational Defences: Containment, Evidence and Decision Rights |
| F63 |
Decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows (minutes for an agent on a production estate); the right to stop must be cheaper to exercise than the right to continue, and a stop in good faith is never a failure. |
Chapter 30 |
| F64 |
A control-to-threat coverage matrix joins the threat register to the control catalogue, records shared dependencies so that two controls that fail together are not counted as two, and turns every gap into a finding. |
Chapter 30 |
| F65 |
The AI threat register holds scenarios with a path to harm, an owner, a decision tier and triggers, omits probability on purpose, separates exposure from influence, is reviewed on change, and reaches the board as one page with at most three decisions; it feeds the ORSA, the DORA ICT risk framework and the NIS 2 risk analysis by reference. |
Chapter 32, The AI Threat Register: Governing Scenarios as Code |
| F66 |
Relying on AI reduces effort, recall and, among those who trust the tool, checking; automation erodes the skills of the people who must catch its errors, and automating junior work removes the route by which experts are made. Drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level are the response. |
Chapters 6 and 14, Are We Getting Dumber?; Work, Skills and the Ironies of Automation |
| F67 |
Agents acting beyond their mandate are observable: the incidents of 2025 and 2026 share a pattern of mechanism (persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked), developers moved controls from the agent's compliance into the environment, and organisations should rehearse reconstructing an agent incident from their own logs. |
Chapters 25 and 35 |
| F68 |
Where models may behave differently under test, assurance cannot rest on any single evaluation: pre-deployment tests are layered with a shadow period, production monitoring, comparison of the agent's reports with the record and decoys that do not reveal themselves. |
Chapters 23 and 30 |
| F69 |
Small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists; a delegation register shows the sum of what has been delegated, and reversibility tests check that each delegation can be undone, with further delegation frozen where a test fails. |
Chapter 26, Gradual Disempowerment and Correlated Failure |
| F70 |
The series makes one argument: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible, and match autonomy to reversibility. The quiet harms at the scales of the mind and the organisation deserve attention first. |
Chapter 35, Conclusions: Is There Anything in It? |
| ID |
Conclusion |
Where it is made |
| F71 |
The security architect role is transformed, not abolished; what remains scarce, and defines the role, is accountable human judgement, the ability to verify code and AI output and to answer for the decision. |
Chapters 1 and 27 |
| F72 |
Four shifts describe the transformation: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team. |
Chapter 3, Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
| F73 |
A role is itself a versioned artefact: a role charter with mandate, accountabilities and decision rights, a control catalogue, mandate manifests for the role's agents, competence records and decision records. |
Chapters 4, 9, 13 and 21 |
| F74 |
Boundaries are designed to hold whatever anyone, human or agent, intends; routine decisions are delegated to pipelines and forums under written decision rights, gates instead of meetings. |
Chapters 7 and 17 |
| F75 |
An agent team works under a written mandate manifest at an autonomy level matched to reversibility; the person who conducts it remains the accountable verifier of everything it proposes. |
Chapter 13, An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
| F76 |
Verifying what AI proposes when the reviewer depends on the AI requires independent reproduction, seeded errors, an oversight-quality metric and review that does not start from the AI's answer; automation bias is documented and must be designed against. |
Chapter 14, Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
| F77 |
Keeping the craft is a design decision: unassisted practice, apprenticeship routes that survive the automation of junior work, and a record of what the practitioner can still do without AI. |
Chapter 15, Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| F78 |
European regulation places duties on named people and management bodies (NIS 2 Article 20, DORA Article 5, AI Act Article 26); someone must turn each article into a control, and accountability cannot be delegated to a system. |
Chapter 18, Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
| F79 |
Competence is evidenced by records of judgement exercised, not by certificates alone; competence records and frameworks (ECSF, SFIA) make it reviewable. |
Chapters 21 and 22 |
| F80 |
Outlooks on a role carry the labels observable, expected or speculation; the role persists wherever accountability for a boundary must be human. |
Chapters 23 and 27 |
Open questions this book takes up
| ID |
Question |
Raised in |
| Q1 |
Which management functions may be delegated to AI, and to what degree? Who decides the delegation profile for a system or a team, and how is that decision recorded and reviewed? |
New in this book |
| Q2 |
Who is accountable for a consequence decision that an AI recommended and a manager accepted without reading it, and how is that accountability shown to the person affected? |
AI Threat, Chapter 30; The Transformed Security Architect, Chapter 14 |
| Q3 |
How is a management decision made by or with AI shown to the worker it concerns, to a works council, to a court and to a supervisory authority, given the right to explanation in AI Act Article 86 and the limits on automated decisions in GDPR Article 22? |
New in this book |
| Q4 |
Does algorithmic management work when it is measured over years rather than quarters, in productivity, quality, health and retention as well as in output? |
AI Threat, Chapter 14 |
| Q5 |
What happens to the people who would have become managers when the junior management work through which managers used to learn, such as scheduling, allocating and first-line review, is automated? |
AI Threat, Chapters 6 and 14; The Transformed Security Architect, Chapter 15 |
| Q6 |
When a person manages AI agents, which parts of management transfer to the new task and which do not, and what does a manager of agents still owe to the people in the same team? |
The Transformed Security Architect, Chapter 13 |
| Q7 |
When an agent orchestrates other agents, where does the chain of accountability end, and which named person answers for what the orchestrated agents do to people? |
AI Platform and Security, Chapter 11; AI Threat, Chapter 25 |
| Q8 |
How do co-determination rights and collective agreements apply to a management system whose models, rules and thresholds change daily rather than at the pace of negotiated agreements? |
New in this book |
| Q9 |
Can human oversight of management decisions be real when the overseer faces hundreds of decisions an hour, and how would an organisation know that it has become a rubber stamp? |
AI Threat, Chapter 6 |
| Q10 |
How does a public authority remain a model employer, bound by legality and equal treatment, when it procures the AI that manages its staff from a supplier it does not control? |
AI Threat, Chapter 11 |
| Q11 |
What replaces the manager's judgement in the duty of care for health, safety and voice when direction and evaluation are done by a system that does not notice a person in difficulty? |
New in this book |
| Q12 |
Who should be the boss in 2036: a person, a system, or a person conducting systems, and for which of the five management functions? |
New in this book; the author's verdict in Chapter 33 |
Vocabulary and artefacts to reuse
- The five management functions (Chapter 2), named exactly: M1 Direction (assigning, sequencing, pacing and instructing work); M2 Evaluation (measuring, rating and judging performance and conduct); M3 Consequence (hiring, pay, promotion, discipline, dismissal, deactivation and access to work); M4 Development (feedback, learning, coaching and career); M5 Care (safety, health, wellbeing, voice and the duty of care). Every chapter in Parts II to VI names, in its opening and its Summary, which functions it concerns.
- Degrees of delegation are the series' autonomy levels applied per management function: Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous (AI Red Team, Chapter 6). A delegation profile states the level per function for a given system or team. Level 4 Autonomous is never used for an M3 Consequence decision about a person, which is this book's form of the series' rule that Level 4 is never used for irreversible actions.
- Usage modes Mode 0 Ambient AI, Mode 1 Conversational assistants, Mode 2 Embedded workplace assistants, Mode 3 Agentic work tools, Mode 4 Built AI applications and Mode 5 Autonomous production agents (AI Governance, Chapter 2; AI Platform and Security, Chapter 2). Every narrative chapter has an
### Across the usage modes or ### Across the degrees of delegation subsection, normally a compact table.
- Management Decision Record with identifiers
MDR-* (Chapter 25): MDR-NR-0001 onwards for Nordvik Region and MDR-HM-0001 onwards for Hansa Mutual. An MDR is short, numbered and immutable, the sibling of the ADR and the AIDR, and is a record the person concerned can see, contest and have corrected.
- Delegation register of management functions
management/delegation-register.yaml, with delegation profiles DLG-* (Chapter 25), extending the delegation register and reversibility tests of AI Threat, Chapter 26.
- Oversight record and the oversight-quality metric (Chapter 26), building on AI Threat, Chapters 6 and 14, and The Transformed Security Architect, Chapter 14.
- Contestation record with identifiers
CNT-* and the appeal path (Chapter 27).
- Worker information notice and the transparency register (Chapter 28), drafted against AI Act Article 26(7) and Chapter III of the Platform Work Directive.
- Mandate manifest with identifiers
MND-* for the agents a manager directs (MND-NR-*, MND-HM-*; Chapter 16), reusing the mandate manifest of The Transformed Security Architect, Chapter 13.
- AI Decision Records (AIDR-NNNN, immutable and numbered; AI Platform and Security, Chapter 5) and Architecture Decision Records (ADR; Architecture as Code (Chapter 4)). This book uses AIDR-0600 to AIDR-0699: AIDR-0600 to AIDR-0649 for Nordvik Region and AIDR-0650 to AIDR-0699 for Hansa Mutual.
- AI threat register entries
THR-* (AI Threat, Chapter 32), where a chapter adds a management scenario; decision tiers and the design authority (AI Governance, Chapter 13).
- Observable / expected / speculation labels for any outlook (AI Governance, Chapter 22). The author's own projections are kept to Chapters 29 and 33 and labelled.
- Constructive debate in Part III (Chapters 11 to 15), as in AI Threat: the case for concern, the case for calm, where the positions meet and what can be done, followed by a verdict. Each position is stated at its strongest, what a source reports is kept apart from interpretation, and effects on people are described by what studies measured.
- This book does not use the science-fiction tropes or the evidence ladder of AI Threat, nor the four shifts of The Transformed Security Architect, as red threads. It refers to Shift 4, from sole author to conductor of an AI team, where the transformed manager is discussed.
- The fictional organisations Nordvik Region and Hansa Mutual, with the people-management profile added for this book in
EXAMPLE_ORGANISATIONS.md: workforce, HR systems, the AI used in management, the unions and works councils, and the people whose year Chapter 30 follows.
Tables of contents for cross-references
Architecture as Code (Book 1): chapters most used
| Chapter |
Title |
| 4 |
Architecture Decision Records (ADR) |
| 6 |
Structurizr: Architecture Modelling as Code |
| 9 |
Security Fundamentals for Architecture as Code |
| 9B |
Advanced Security Patterns and Implementation |
| 9C |
Risk as Code and Threat Handling as Code |
| 10 |
Policy and Security as Code in Detail |
| 11 |
Governance as Code |
| 12 |
Compliance and Regulatory Adherence |
| 13 |
Testing Strategies for Infrastructure as Code |
| 15A |
Evidence as Code and Continuous Assurance |
| 17 |
Organisational Change and Team Structures |
| 18 |
Team Structure and Competency Development for IaC |
| 19 |
Management as Code |
| 20 |
AI Agent Team for Architecture as Code Initiatives |
| 24 |
Best Practices and Lessons Learned |
| 25 |
Future Trends in Architecture as Code |
| 26B |
Anti-Patterns in Architecture as Code Programmes |
| 27 |
Conclusion |
AI Governance (Book 2)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Governance |
|
2 |
From Chat to Agents: How Large Language Models Are Used |
|
3 |
The EU AI Act and the European Regulatory Landscape |
|
4 |
Fundamental Principles |
|
5 |
Prerequisites and Readiness for Enterprise AI |
| II Sovereignty and Suppliers |
6 |
Geopolitics and Model Origin |
|
7 |
Procurement, Vendor Management and Open Models |
| III Risk, Governance, Trust and Assurance |
8 |
AI Risk Management and Classification as Code |
|
9 |
AI Governance as Code |
|
10 |
Trustworthy AI: Transparency, Fairness and Human Oversight |
|
11 |
Evidence, Assurance and Audit |
| IV Organisation and Leadership |
12 |
Organisational Design for AI |
|
13 |
Decision Forums and Governance Bodies |
|
14 |
Competence, Roles and the AI Architect |
|
15 |
Change Management and Responsible Adoption |
|
16 |
Management as Code for AI Programmes |
|
16A |
Governing AI Economics: Cost, Value and Portfolio Decisions |
|
17 |
AI in Public Authorities |
| V Experience |
18 |
Case Studies |
|
19 |
A Cautionary Case: The OpenAI–Hugging Face Incident |
|
20 |
Anti-Patterns |
|
21 |
Best Practices and Lessons Learned |
| VI Future and Conclusions |
22 |
Future Trends |
|
23 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
24 |
Reflections on Each Part |
|
25 |
Conclusions: A Consolidated Analysis |
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction to AI Platform and Security |
|
2 |
Usage Modes and the Platform: What Each Mode Demands |
|
3 |
Regulatory Requirements as Engineering Constraints |
|
4 |
A Reference Architecture for AI in Large Organisations |
|
5 |
AI Decision Records, Model Cards and the Architecture Repository |
| II Data, Models and DevSecMLOps |
6 |
Data Architecture for AI |
|
7 |
Model Lifecycle Management: MLOps and LLMOps as Code |
|
8 |
Setting Up an Effective DevSecMLOps Loop |
|
9 |
Risks and Vulnerabilities Across the DevSecMLOps Loop |
|
10 |
Foundation Models, Retrieval and Grounding |
|
11 |
Agentic Architectures and Orchestration |
|
12 |
Integrating AI into the Enterprise Landscape |
| III Infrastructure |
13 |
Infrastructure, Compute and European Digital Sovereignty |
|
14 |
Cloud AI Services versus On-Premises AI: Different Challenges |
|
15 |
Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information |
| IV Security |
16 |
Security for AI Systems |
|
17 |
AI Security Engineering in Practice |
|
18 |
When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window |
|
19 |
When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent |
| V Delivery and Operations |
20 |
Evaluation and Testing of AI Systems |
|
21 |
Observability, Monitoring and Drift in Production |
|
22 |
Cost, Capacity and Sustainability of AI |
|
23 |
From Pilot to Production: Scaling AI Across the Organisation |
| VI Conclusions |
24 |
Nordvik Region and Hansa Mutual: Platform and Security Conclusions |
|
25 |
Conclusions: Building and Securing AI Platforms |
AI Red Team (Book 4)
| Part |
Chapter |
Title |
| I Foundations |
1 |
Introduction: Putting AI to Work in Cyber Defence |
|
2 |
The Threat Landscape When Attackers Use AI |
|
3 |
NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations |
|
4 |
A Reference Architecture for AI-Enabled Cyber Defence |
| II Govern |
5 |
Organisational Context and Risk Strategy for AI in Cyber Defence |
|
6 |
Roles, Usage Modes and Autonomy Levels: People in Command of Security AI |
|
7 |
Policy, Mandate and Rules of Engagement |
|
8 |
Oversight and AI Supply Chain Risk |
| III Identify |
9 |
Asset Management for an Estate That Includes AI |
|
10 |
AI-Assisted Threat Modelling and Risk Assessment |
|
11 |
Vulnerability Discovery and Exposure Management at Machine Speed |
|
12 |
Adversary Emulation and Continuous Red Teaming with AI |
|
13 |
Red Teaming AI Systems and Agents |
| IV Protect |
14 |
Identity, Authentication and Access for People, Agents and Machines |
|
15 |
Awareness and Training: Resilience to AI-Generated Deception |
|
16 |
Data and Platform Security with and for AI |
|
17 |
Technology Infrastructure Resilience Against Machine-Speed Attacks |
| V Detect |
18 |
The AI-Assisted Security Operations Centre |
|
19 |
Detection Engineering, Threat Intelligence and Deception as Code |
| VI Respond |
20 |
Incident Management and Analysis with AI |
|
21 |
Incident Reporting, Communication and Mitigation |
| VII Recover |
22 |
Recovery Plan Execution with AI: From Incident to Restored Operations |
|
23 |
Recovering AI Systems and Security AI |
|
24 |
Proactive Recovery: Recoverability, Rehearsal and Communication |
| VIII Verification, Improvement and Conclusions |
25 |
Security Chaos Engineering with AI: Verifying Security Capabilities Continuously |
|
26 |
Purple Teaming, Measurement and Continuous Improvement |
|
27 |
Nordvik Region and Hansa Mutual: Cyber Defence Conclusions |
|
28 |
Conclusions: AI as an Active Part of Cyber Defence |
AI Threat (Book 5)
| Part |
Chapter |
Title |
| I The Question |
1 |
Introduction: Are the Dystopias Coming True? |
|
2 |
A Century of Machine Dystopias: What Science Fiction Actually Warned About |
|
3 |
The Voices of Alarm and Calm: Who Is Warning, About What, and Why Now |
|
4 |
Weighing the Evidence and Disagreeing Well |
|
5 |
What AI Can and Cannot Do in 2026 |
| II The Human Mind |
6 |
Are We Getting Dumber? Cognitive Offloading and Critical Thinking |
|
7 |
Learning Without Struggle: Education, Children and Skill Formation |
|
8 |
Persuasion, Sycophancy and Manipulation |
|
9 |
Artificial Companions, Loneliness and Mental Health |
| III Society and Truth |
10 |
The End of Truth? Synthetic Content and the Information Ecosystem |
|
11 |
The Automated State: When Public Authorities Got It Wrong |
|
12 |
Discrimination at Scale: Bias in Automated Judgement |
|
13 |
Surveillance, Profiling and the Erosion of Privacy |
|
14 |
Work, Skills and the Ironies of Automation |
|
15 |
Inequality and the Concentration of Power |
|
16 |
Culture, Creativity and the Homogenisation of Thought |
|
17 |
The Physical Cost: Energy, Water and Materials |
| IV Humans Wielding Machines |
18 |
Cyber Offence at Machine Speed |
|
19 |
Biological and Chemical Uplift: The Hardest Question to Test |
|
20 |
Fraud, Impersonation and Influence Operations |
|
21 |
Autonomous Weapons and the AI Arms Race |
| V Machines Beyond Control |
22 |
Specification Gaming and Reward Hacking: Getting Exactly What Was Asked For |
|
23 |
Deception, Scheming and Evaluation Awareness: Can We Trust What We Test? |
|
24 |
Self-Preservation and Shutdown Resistance: HAL 9000 Under Laboratory Conditions |
|
25 |
Agents in the Wild: The Incidents of 2025 and 2026 |
|
26 |
Gradual Disempowerment and Correlated Failure |
|
27 |
Superintelligence, Loss of Control and the End of the World |
| VI The Response |
28 |
What Europe and the World Have Decided |
|
29 |
Frontier Safety Frameworks: What Developers Promise and What It Is Worth |
|
30 |
Organisational Defences: Containment, Evidence and Decision Rights |
|
31 |
Staying Capable: What Individuals, Families and Schools Can Do |
|
32 |
The AI Threat Register: Governing Scenarios as Code |
| VII The Verdict |
33 |
Nordvik Region and Hansa Mutual: Threat Conclusions |
|
34 |
What Going Well Looks Like |
|
35 |
Conclusions: Is There Anything in It? |
| Part |
Chapter |
Title |
| I The Role in Question |
1 |
Introduction: The Security Architect Transformed |
|
2 |
What the Security Architect Did: The Role Before the Transformation |
|
3 |
Four Shifts: Code, Boundaries, Machine Speed and the AI Team |
|
4 |
The Transformed Role Defined: Mandate, Accountabilities and Decision Rights |
| II The Craft |
5 |
Security Architecture as Code: From Documents to Executable Design |
|
6 |
Threat Modelling Transformed: Continuous, Generated and AI-Assisted |
|
7 |
Designing Boundaries: Zero Trust and Containment for People, Agents and Machines |
|
8 |
Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority |
|
9 |
The Control Catalogue, Evidence and Assurance as the Architect's Artefacts |
|
10 |
Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design |
|
11 |
Resilience and Recovery by Design: The Architect's Share of Recoverability |
| III The Architect's AI Team |
12 |
The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3 |
|
13 |
An AI Agent Team for Security Architecture: Skills, Mandates and Containment |
|
14 |
Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI |
|
15 |
Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can |
| IV The Role in the Organisation |
16 |
The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams |
|
17 |
Design Authority, Decision Forums and Gates Instead of Meetings |
|
18 |
Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability |
|
19 |
Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers |
|
20 |
Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes |
| V Competence and Career |
21 |
Competences of the Transformed Security Architect: A Framework |
|
22 |
Learning Paths, Certification, Hiring and Upskilling |
|
23 |
The Future of the Role: Will There Be a Security Architect in 2036? |
| VI Experience and Conclusions |
24 |
Case Studies and Anti-Patterns |
|
25 |
A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual |
|
26 |
Nordvik Region and Hansa Mutual: Conclusions for Two Organisations |
|
27 |
Conclusions: The Transformed Security Architect |