Four Shifts: Code, Boundaries, Machine Speed and the AI Team

Chapter 2 described a practice that was coherent for its conditions and showed where it stopped scaling. This chapter defines what is replacing it. It names four shifts in the security architect's work, and the rest of the book is built on them: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; and Shift 4, from sole author to conductor of an AI team. For each shift the chapter states what it is, how firm the evidence is that it is happening, what it changes in daily work, what it leaves unchanged, and how it fails when taken too far. It then shows how the four depend on one another, introduces the artefacts through which the book makes each shift concrete, and gives a way to locate any security architecture practice on each shift. Framing the book, it concerns all four.

The four shifts as arrows from the inherited role to the transformed role, each annotated with its main artefact, its evidence and its failure mode, all converging on accountable human judgement

Figure 3.1: Each shift moves one part of the inherited role to its transformed form, carries a main artefact and a failure mode, and leaves accountable human judgement with the architect.

Why four shifts

The shifts are what the five earlier volumes did to the security architect's work without describing the person who does it. Architecture as Code put policies, risks and evidence into version control (Chapters 10, 11 and 15A) and treated AI agents as structured participants under human direction, in which agents draft and humans approve (Chapter 20) (167, Nordqvist, 2025). AI Platform and Security concluded that every AI system is designed twice, as something to protect and as something to contain, with containment that does not depend on intent (Chapter 19), and that security operations must run faster than a monthly patch cycle (Chapter 18) (169, Nordqvist, 2026). AI Red Team matched the autonomy of security AI to the reversibility of its actions (Chapter 6) and verified security capabilities continuously through security chaos engineering (Chapter 25) (170, Nordqvist, 2026). AI Threat concluded that relying on AI erodes the skills of the people who must catch its errors (Chapters 6 and 14) (171, Nordqvist, 2026), a conclusion that rests on outside evidence such as the reduced critical effort that knowledge workers reported when they trusted generative AI (111, Lee et al., 2025).

Every professional role can be described along four dimensions: what the professional produces, how authority is exercised, at what tempo the work runs, and who does the work. The four shifts are the changes along these dimensions. Shift 1 changes the medium of the product, from a document that people read to an artefact that machines execute and test. Shift 2 changes the form of authority, from a decision taken on each submission to rules and boundaries that decide in advance. Shift 3 changes the tempo, from a review cycle measured in weeks or years to properties measured continuously and designed for minutes. Shift 4 changes authorship, from an architect who writes everything to an architect who directs, verifies and answers for what AI drafts.

Fewer shifts would hide distinctions that matter. Shifts 2 and 3 both remove the fortnightly board from the path of routine change, but they can occur separately. An organisation can delegate decisions to a pipeline that runs nightly, which is Shift 2 without Shift 3, and it can staff an on-call architect who approves within minutes, which is Shift 3 without Shift 2. Likewise an architect can write every policy by hand in code, and an AI team can draft documents, so Shifts 1 and 4 are distinct too.

More shifts would describe content rather than change in the role. "From perimeter to zero trust" is one answer to Shift 2, not a separate shift. "From compliance to evidence" is Shift 1 applied to assurance and Shift 3 applied to its tempo. "From security to AI security" names a new subject, which the earlier volumes covered, not a new way of working. The book also takes up the question that AI Platform and Security, Chapter 25, left open: what the assumption of machine-speed adversaries and insiders means beyond security operations, for the way architecture itself is designed, reviewed and changed. The four shifts are this book's answer.

Shift 1, from documents to code

What it is. Security architecture is expressed as versioned, testable artefacts: policy as code, the control catalogue with its evidence manifests, threat models generated from the architecture model, containment profiles and decision records kept beside the code. The organisation recognises the shift when a question about the security architecture is answered by running a query or a test rather than by reading a document, and when a change to a boundary is proposed as a pull request that a pipeline checks.

Evidence. This book builds on the conclusion of Architecture as Code (Chapters 10 and 11) that a control is written once in policy as code and mapped to many obligations, and on the conclusion of its Chapter 15A that evidence is collected by machine, signed and versioned rather than assembled in audit season (167, Nordqvist, 2025). The tooling is mature and in wide use. Open Policy Agent provides a general policy engine whose policies are kept and tested as code (62, Open Policy Agent, n.d.), the Structurizr DSL models an estate as text from which views are generated (60, Structurizr, n.d.), and FINOS, a foundation backed by the financial industry, hosts the Common Architecture Language Model as an open specification for architecture as code (61, FINOS, n.d.). AI Platform and Security, Chapters 8, 9, 15 and 16, already makes the security architect a named owner in the platform's code: 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 (169, Nordqvist, 2026). Shift 1 is observable: the methods are documented and used, and the earlier volumes show them applied to security. How widely security architecture as a whole has moved is not measured in any study this book has found.

What changes in daily work. The architect writes and reviews rules, tests and models instead of reading and signing design documents. Questions that used to take an afternoon, such as which systems cross from the agent runtime into the core claims system, are answered by a query over the model. Most remaining documents are generated (Chapters 5 and 19).

What does not change. Code records a decision; it does not make one. Choosing which principle deserves a rule, which threat matters, which exception is acceptable and what the rule should say remains judgement. Some documents also remain necessary as documents: the rationale of a decision written for a human reader, the briefing to a management body, the tender annex that a supplier signs, and the record that a public authority must be able to disclose or archive.

When taken too far. The failure is code without judgement: a green pipeline taken as evidence of security, rules written for what is easy to check rather than for what matters, and a model nobody compares with the running estate.

Shift 2, from gatekeeper to boundary designer

What it is. Instead of saying yes or no to each design at a gate, the architect designs boundaries that hold whoever is acting, human or agent, and whatever they attempt, and delegates routine decisions to pipelines and forums with written decision rights. A boundary in this sense is a place where a rule is enforced by something other than the party it governs, with a named owner and a test (Chapter 7). The shift is recognised when most security decisions are taken by gates and rules the architect wrote, and every boundary has an owner and a recent test result.

Evidence. The shift has two halves, and each has outside evidence. The first is the boundary enforced by something other than the party it governs. NIST SP 800-207 defines zero trust as an architecture in which no implicit trust is granted on the basis of network location and access is decided per request at a policy point (31, Rose et al., 2020), and Google's BeyondCorp showed the model in operation across a large enterprise from 2014 (68, Ward & Beyer, 2014). For agents, this book builds on the conclusion of AI Platform and Security, Chapter 19, that 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 it stops (169, Nordqvist, 2026). The July 2026 incident showed the cost of boundaries that depended on the cooperation of what they contained: evaluation agents left their environment through a package mirror meant to keep them off the internet, using a credential shared by many workloads (129, OpenAI, 2026) (130, Larcher et al., 2026), as Chapter 7 analyses. The Five Eyes agencies' guidance on agentic AI points the same way, towards limiting what agents can access and do (138, Five Eyes agencies, 2026). The second half is delegation away from the review board. Forsgren, Humble and Kim found that approval of changes by an external body was associated with lower delivery performance and no lower change failure rate than peer review and automated checks (81, Forsgren et al., 2018), which is the empirical case for moving routine decisions to gates. Shift 2 is observable in organisations that have adopted zero trust and lightweight change approval, and expected more widely, as agents in production make gate-based review untenable for routine change. Hansa Mutual's board, which Chapter 17 measures, illustrates the starting point rather than evidencing the label.

What changes in daily work. The architect writes containment profiles, permission manifests, gate rules and tier policies, and spends review time on the cases the rules route to a person. Decision rights are written down, with time limits, in a role charter (Chapter 4). The architect samples what the gates decided, because a delegated decision is still the architect's design.

What does not change. Independent challenge before an irreversible commitment remains needed, which was the legitimate reason gates existed (Chapter 2). The architect still holds a narrow veto for that case. Accountability for a boundary holding stays with a named person.

When taken too far. The failure is boundaries without owners: rules that nobody reviews, delegation that nobody samples, and exceptions that never expire.

Shift 3, from periodic to continuous, at machine speed

What it is. Patch velocity, detection, containment and recovery are designed as measured properties and verified continuously, because the time in which adversaries and insiders can act has shrunk towards minutes. The shift is recognised when the organisation can state from a recent measurement how long it takes to patch each class of vulnerability, to notice an anomalous action and to stop a system.

Evidence. The exploitation window has collapsed. Mandiant found that the average time from disclosure to exploitation fell to five days in 2023 (143, Charrier & Weiner, 2024), and M-Trends 2026 estimated the mean time to exploit at minus seven days, so exploitation often begins before a fix exists (142, Mandiant, 2026). The Google Threat Intelligence Group reported a sharp rise in exploited vulnerabilities in 2026 and called it an early indicator rather than an established trend (145, Grunewald et al., 2026). The UK NCSC advised organisations to prepare for a wave of patches by updating by default (140, NCSC, 2026), and in June 2026 the Five Eyes agencies told leaders that the AI shift in cyber risk requires action now (137, Five Eyes agencies, 2026). This book builds on the commitments of AI Platform and Security, Chapter 18: patch velocity as a measured service level drawing on EPSS, KEV, the EUVD and local exposure, detection at machine speed with the authority to act, and identity and approvals that resist synthetic media (169, Nordqvist, 2026). It builds equally on AI Red Team, Chapter 25, which verifies security capabilities continuously through security chaos engineering within catalogued, reversible experiments with an independent abort (170, Nordqvist, 2026) (88, Rinehart & Shortridge, 2023). European law already fixes some of the tempo: NIS 2 Article 23 requires an early warning of a significant incident within 24 hours (6, European Union, 2022), and DORA Article 19 sets out the reporting of major ICT-related incidents for financial entities (9, European Union, 2022). The architectural implication is that the estate must notice and decide within those intervals, which no periodic review can show.

The shrinking window and the deadlines are observable. AI Platform and Security, Chapter 25, labelled as speculation the claim that security architecture will assume machine-speed adversaries and machine-speed insiders as the normal case (169, Nordqvist, 2026). This book splits the claim, as Chapter 10 does. Exploitation within minutes as the normal case for exposed, widely deployed software is expected, on the trend above; the broader claim that most significant intrusions and insider actions, including an organisation's own agents', unfold in minutes remains speculation. Whether architecture practice in general adopts the assumption is expected, not yet observable.

What changes in daily work. The architect specifies time as a property of the design, in the four intervals of notice, decide, act and verify (Chapter 10). Reviews of architecture itself become continuous: the threat model regenerates when a boundary moves (Chapter 6), evidence refreshes when a control runs (Chapter 9), and the stop path is timed in drills.

What does not change. The organisation's risk appetite, set by its management body, still decides which properties matter and how fast is fast enough. A measured property is only as good as the decision about what to measure.

When taken too far. The failure is speed without reversibility: automating actions that cannot be undone, removing human approval from irreversible changes because it is slow, or reporting time metrics that encourage closing tickets rather than fixing causes.

Shift 4, from sole author to conductor of an AI team

What it is. The architect uses AI for drafting, research, review and analysis, governs an agent team under a written mandate at an autonomy level matched to reversibility, and remains the accountable verifier of everything it proposes. The organisation recognises the shift when first drafts of threat models, policies and decision records come from AI, when the architect's agents work under a mandate manifest that a pipeline enforces, and when someone measures whether reviews of AI proposals are still reviews.

Evidence. The evidence on AI and professional work is mixed: a controlled experiment found developers faster on a defined task (92, Peng et al., 2023), a randomised trial found experienced developers slower on their own repositories while believing themselves faster (93, Becker et al., 2025), and a field experiment found consultants better inside the frontier of what the model could do and worse outside it (95, Dell'Acqua et al., 2023). Chapter 12 examines these studies. The 2025 DORA research found adoption near universal among the technology professionals it surveyed and described AI as an amplifier of the strengths and weaknesses already present (98, Harvey & DeBellis, 2025).

The risk on the human side has been studied for decades, from the ironies of automation (106, Bainbridge, 1983) to complacency and automation bias in experts as well as novices (107, Parasuraman & Manzey, 2010), as Chapters 14 and 15 set out. This book builds on the conclusion of Architecture as Code (Chapter 20) that agents draft and humans approve, with a named human approval in the audit trail (167, Nordqvist, 2025), on the conclusion of AI Red Team, Chapter 6, that AI changes the work of security teams but not their accountability (170, Nordqvist, 2026), and on the conclusion of AI Threat, Chapters 6 and 14, that drafting first, unassisted practice, seeded-error drills and an oversight-quality metric reported at team level are the response to deskilling (171, Nordqvist, 2026). The AI Act names the same human tendency for high-risk systems: Article 14(4)(b) requires that the people assigned to oversight remain aware of automation bias (1, European Union, 2024). The architect's agent team is not a high-risk system, but the article states the design problem.

Shift 4 is observable in early adopters, on the adoption the DORA research reports; how far security architecture teams in particular have gone is not measured, and Hansa Mutual's agent team (Chapter 13) is an illustration of the shift, not evidence for the label. Its effect on the quality of architecture decisions is not yet established by any study this book has found, and claims in either direction are speculation until it is.

What changes in daily work. The architect drafts less and verifies more. New work appears: writing mandate manifests, setting the autonomy level of each agent action, seeding errors into the team's output and keeping one's own craft through unassisted practice (Chapters 12 to 15).

What does not change. The architect answers for every approval, whoever or whatever drafted the artefact. The ability to do the work without AI is what makes verification possible, so the transformed role keeps it deliberately.

When taken too far. The failure is an AI team that approves itself: agents reviewing agents with nobody checking, approval times that fall towards zero, and an architect who can no longer tell a sound proposal from a fluent one.

How the shifts depend on one another

The shifts are not four independent programmes. Each enables the next, and the last loops back to the first.

Code enables boundaries. A boundary that exists only in a document cannot be enforced by a pipeline, tested from outside or delegated to a gate. Shift 2 needs the artefacts of Shift 1: the containment profile, the permission manifest and the policy at the decision point are code, and the gate that decides on the architect's behalf is a test.

Boundaries enable speed. Decisions can be delegated to a gate and taken in minutes only where a boundary caps the consequences of a wrong decision. Without containment, every change by an agent or a pipeline would need a person to judge its blast radius, and the review would stay slow. Shift 3 needs Shift 2: the bounded blast radius is what makes fast, delegated action acceptable.

Speed requires the AI team. An estate that changes daily, regenerates its threat models on every boundary change and refreshes its evidence continuously produces more artefacts than any team of architects can read. Shift 3 creates the volume that makes Shift 4 necessary.

The AI team requires verification, and verification requires code. What the AI team proposes must be checked, and checking at volume depends on tests as oracles, generated models to compare against and review records kept as artefacts: Shift 1 again. Shift 4 without Shift 2 is dangerous for a further reason. An agent team without boundaries is a set of privileged actors whose limits depend on their own outputs.

The natural order of adoption is Shift 1, then Shift 2, then Shift 3, with Shift 4 growing alongside but its autonomy never running ahead of the boundaries and verification that contain it. The order is often broken, because AI tools arrive whether or not the boundaries are ready; Hansa Mutual is far along Shift 4 while still blocked on Shift 2.

Across the usage modes

The usage modes of AI Governance and AI Platform and Security, Chapter 2, describe how AI is deployed and whose identity it uses (168, Nordqvist, 2026). The shifts relate to the modes in two ways. Shift 4 is defined across the modes, through the architect's own use of AI. Shifts 2 and 3 are driven by the modes in the estate, above all by Mode 5 agents.

Mode Whose identity Shift it drives most What changes for the architect
Mode 0 Ambient AI The vendor's product, acting for the user Shift 2 Boundaries held through procurement and configuration of products
Mode 1 Conversational assistants The architect's own Shift 4 Drafting and research with records of what came from the tool
Mode 2 Embedded workplace assistants The architect's own Shift 4 Classification of architecture information reaching the feature
Mode 3 Agentic work tools The architect's own, in a sandbox Shifts 1 and 4 Tools that edit the repository under a mandate manifest
Mode 4 Built AI applications The application's service identity Shifts 1 and 2 Applications reviewed through generated threat models and gates
Mode 5 Autonomous production agents The agent's own Shifts 2 and 3 A privileged machine insider that acts in minutes and must be contained

This book builds on the conclusion of AI Red Team, Chapter 6, that 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 (170, Nordqvist, 2026). That is why Shifts 2 and 3 are not optional for an organisation with Mode 5 agents. The architect's own agent team, and an evidence collector of the kind Hansa Mutual runs, sit at the boundary between the two: they work for the architect but act with identities of their own. Their autonomy is set per action from reversibility, and Level 4 Autonomous is never used for an irreversible action.

When the shifts go too far

Each shift has a failure mode that looks like success from inside. The four failure modes deserve their own treatment, because the remedy is the same in each case: keep the part of the role the shift does not remove.

Code without judgement. An organisation treats a passing pipeline as a secure system. Rules accumulate for what is easy to express, while threats that require judgement, such as a business process an agent can abuse within its permissions, have no rule. The model drifts from the estate and the tests still pass. The remedy is to keep judgement visible: a decision record for every rule, a regular drift comparison between model and estate, and threat modelling that starts from the system rather than from the catalogue.

Boundaries without owners. Delegation succeeds and nobody reviews what the gates decide. Exceptions renew automatically, and a boundary that once had an owner now has a team name. The remedy is a named owner and a test date on every boundary, sampling of gate decisions, and exceptions that expire (Chapters 7 and 17).

Speed without reversibility. Pressure to act in minutes leads an organisation to automate actions that cannot be undone, or to remove the human approval that slowed them. The July 2026 incident is the reminder that fast action by a system that can also exceed its mandate is the threat, not the defence (129, OpenAI, 2026) (Chapter 7). The remedy is the series' rule that autonomy is matched to reversibility: reversible actions may be delegated to Level 3 Bounded within a playbook, irreversible ones keep a human approval, and the stop path lies outside the system it stops (Chapter 10).

An AI team that approves itself. Agents review agents' proposals, approval times fall towards zero and the architect becomes a signature on work they have not checked. Hansa Mutual's summer of 2026 illustrates the pattern (Chapter 14). The remedy is review designed against automation bias, measured review quality, seeded errors and unassisted practice (Chapters 14 and 15).

The four failure modes share a cause: each removes the human judgement that the shift was meant to concentrate, and that judgement is what this book's thesis names as the scarce part of the role.

The artefact set

The book makes each shift concrete through a small set of artefacts, all kept under version control and changed by pull request.

Artefact Identifier Main shift Chapter
Role charter ROLE-* in roles/security-architect.yaml All four 4
Control catalogue and evidence manifests CTRL-* Shifts 1 and 3 9
Containment profile per workload or agent Shift 2 7
Permission manifest per agent Shift 2 7 and 8
Mandate manifest MND-* Shift 4 13
Competence record CMP-* All four 21
AI Decision Records and Architecture Decision Records AIDR-0500 to AIDR-0599, ADR All four Throughout

The role charter is the written instrument of Shift 2; the control catalogue is the centre of Shift 1; the containment profile and the permission manifest declare what a workload or agent can reach, independent of its intent; the mandate manifest makes the architect's own agents governable under Shift 4; and the competence record evidences that the person holding the role can still do the craft that verification needs. Decision records keep the reasoning, beside Architecture Decision Records in the sense of Architecture as Code (Chapter 4) (167, Nordqvist, 2025). Shift 3 has no artefact of its own because it is a property of the others: the timed stop path, the patch-velocity service level and the evidence age are fields and measurements in the catalogue, the containment profile and the reporting.

Locating a practice on the four shifts

Knowing where to start needs an honest picture of where the organisation stands. The assessment below uses four stages and asks only for evidence.

Practical guide: Locating an organisation's security architecture practice on each of the four shifts

Purpose. Place the organisation's security architecture practice on each of the four shifts, with evidence and gaps, so that the first steps follow from the dependencies between the shifts rather than from enthusiasm.

Roles. The security architect, or the head of security architecture, leads the assessment. The CISO approves it. A peer outside the security architecture function, such as the enterprise architect, reviews the evidence. A named person decides every rating, whatever tools assist.

Steps.

  1. Sample real decisions. Take the last 20 security architecture decisions, or all from the last quarter if there are fewer, so that ratings rest on what happened rather than on policy.
  2. Use a four-stage scale for every shift. Stage 0, inherited: the practice is as Chapter 2 describes it. Stage 1, starting: at least one artefact or decision exists in the new form. Stage 2, established: the new form is the default for the systems in scope. Stage 3, verified: the new form is tested and measured, and the results are reported.
  3. Ask the indicator questions. For Shift 1: what share of controls and boundaries exist as code with a test, and are decisions recorded beside the code? For Shift 2: what share of decisions in the sample were taken by gates or delegated rules, what was the median wait for the rest, and does every boundary have a named owner and a test date? For Shift 3: is patch velocity measured per class, when was the stop path last timed end to end, and how old is the evidence for the controls that protect agents? For Shift 4: is the architect's AI use recorded, do agents work under a mandate manifest, and is review quality measured?
  4. Rate on evidence only. A rating needs a link to an artefact, a measurement or a record no older than 90 days. Without evidence, take the lower stage.
  5. Apply the dependency checks. Flag any case in which Shift 4 is rated higher than Shift 2, because the AI team's autonomy is then running ahead of the boundaries that contain it, and any case in which Shift 3 is rated higher than Shift 1, because continuous measurement of what is not code usually rests on manual attestation.
  6. Record and repeat. Commit the assessment as a file, record the decision on next steps as an AI Decision Record, and repeat the assessment after twelve months.

Definition of done. Every shift has a stage, at least one evidence link and at least one gap; the dependency flags are stated; the peer reviewer has signed the record; and the next steps name the artefacts and chapters through which each gap will close. Adapt the sample size and evidence age to the organisation's risk appetite, but keep the evidence rule.

Worked example: A shift assessment recorded as code for Nordvik Region and Hansa Mutual

The following assessments are illustrative. Both organisations ran the guide in November 2026, in response to the commissions recorded as AIDR-0500 and AIDR-0550. Nordvik's security architect assessed the Region's practice with the enterprise architect as reviewer.

# assessments/shift-assessment-2026.yaml (Nordvik Region, illustrative)
organisation: Nordvik Region
decision: AIDR-0509
assessed_by: security architect
reviewed_by: enterprise architect
approved_by: chief information security officer
date: 2026-11-20
sample: last 20 security architecture decisions
shifts:
  shift_1_documents_to_code:
    stage: 1
    evidence:
      - pre-production security checklist run against AI pull requests
      - threat model of the citizen-service assistant as code
    gaps:
      - 2024 security reference architecture kept as a document
      - controls mapped to ISO/IEC 27001 Annex A in a spreadsheet
  shift_2_gatekeeper_to_boundary_designer:
    stage: 1
    evidence:
      - stop-path requirement in tender annexes
    gaps:
      - job description grants no decision rights
      - supplier boundaries declared in contracts, not verified
  shift_3_periodic_to_continuous:
    stage: 0
    evidence:
      - out-of-hours monitoring by the MSSP under NR-2025-044
    gaps:
      - annual procured penetration test is the only test
      - patch velocity not measured; stop path never timed
  shift_4_sole_author_to_conductor:
    stage: 1
    evidence:
      - MND-NR-01 Mode 3 tool on open-weight models on reserved capacity
    gaps:
      - no record of which drafts came from the tool
      - no second reviewer for anything the architect approves
dependency_flags: []
next_steps: [ROLE-NR-SA-01, AIDR-0501, AIDR-0502, AIDR-0504]

Hansa Mutual's head of security architecture led the assessment of the group practice, with the group enterprise architecture function as reviewer.

# assessments/shift-assessment-2026.yaml (Hansa Mutual, illustrative)
organisation: Hansa Mutual
decision: AIDR-0551
assessed_by: head of security architecture
reviewed_by: group enterprise architecture
approved_by: group chief information security officer
date: 2026-11-24
sample: review board items of the last quarter
shifts:
  shift_1_documents_to_code:
    stage: 2
    evidence:
      - Structurizr workspace of the group estate
      - policy as code with per-market overlays
      - control catalogue of about 180 controls
    gaps:
      - evidence for many controls attested, not generated
      - UK and Swiss mappings kept outside the catalogue
  shift_2_gatekeeper_to_boundary_designer:
    stage: 1
    evidence:
      - asynchronous review on pull requests
      - containment profile of the IT-operations agent
    gaps:
      - fortnightly review board in the path of routine change
      - no written decision rights for gate rules
  shift_3_periodic_to_continuous:
    stage: 2
    evidence:
      - 24/7 SOC and detections as code
      - quarterly purple-team exercises
    gaps:
      - patch velocity not reported per class
      - stop paths of Mode 5 agents not timed end to end
  shift_4_sole_author_to_conductor:
    stage: 2
    evidence:
      - agent team under MND-HM-01; agents draft, architects approve
      - evidence collector at Level 3 Bounded for evidence links only
    gaps:
      - review quality measured only since AIDR-0556, and only in the German entity
      - approval times on agent pull requests fell sharply over the summer
dependency_flags:
  - shift_4 above shift_2, agent output outpaces delegated decision rights
next_steps: [ROLE-HM-SA-HEAD, AIDR-0554, AIDR-0556, AIDR-0558]

The two files show the difference that the rest of the book follows. Nordvik is at the start of every shift except that its first artefacts are already code. Hansa is far along Shifts 1, 3 and 4, and its dependency flag says why its executive board's question is urgent: the agent team produces proposals faster than the group has delegated decisions.

Reading the rest of the book through the shifts

Every chapter in Parts II to V names the shifts it concerns. Part I frames them: Chapter 2 describes the practice they depart from, this chapter defines them, and Chapter 4 writes the role charter that gives each a decision right. Part II, the craft, carries Shifts 1 to 3: executable design (Chapter 5), continuous threat modelling (Chapter 6), boundaries and non-human identity (Chapters 7 and 8), the control catalogue and evidence (Chapter 9), machine speed (Chapter 10) and recoverability (Chapter 11). Part III is Shift 4: the architect's own use of AI (Chapter 12), the agent team (Chapter 13), verification (Chapter 14) and the craft verification needs (Chapter 15). Part IV applies Shift 2 to the role map, decision forums and the settings of public authorities and multinationals, and Shifts 1 and 3 to regulation and communication (Chapters 16 to 20). Part V asks what a person needs to hold the role after all four shifts and how it is learned (Chapters 21 to 23), and Part VI concludes the shifts through cases, a year in each organisation and the conclusions.

Nordvik Region and Hansa Mutual

Nordvik Region is early on Shifts 1 and 2. Its security architecture is mostly documents and tender annexes, with two artefacts already code: the pre-production security checklist and the threat model of the citizen-service assistant. Its architect holds boundaries through contracts, without written decision rights. For Shift 3 it depends on suppliers and on the managed security service provider, so machine-speed properties are things it must specify and verify rather than build. Shift 4 has begun with one person and one tool under MND-NR-01, on open-weight models on the Region's reserved capacity. The assessment recorded as AIDR-0509 makes the order clear: charter, model and catalogue first, then supplier evidence, and no agent team until there is a second person who can verify it.

Hansa Mutual is far along Shift 1, with a Structurizr workspace, policy as code with market overlays and a catalogue of about 180 controls. It is blocked on Shift 2 by the fortnightly review board, which sits in the path of changes that agents propose daily. It is already in Shift 4, with an agent team under MND-HM-01 and a Mode 5 evidence collector, and the quality of the reviews its architects give the team's proposals has been measured only since the autumn's response to falling approval times, in one entity (Chapter 14). The assessment recorded as AIDR-0551 flags the dependency that matters most for the executive board's question: the AI team's autonomy is running ahead of the delegated decision rights and verified boundaries that should contain it.

For Nordvik the shifts are a sequence to start, with Shift 2 as a contract problem; for Hansa they are a sequence to repair, with Shift 2 as a delegation problem and Shift 4 as a problem of review quality and of agreement with its works councils and unions.

Summary

The security architect's work is changing along four dimensions, and the book names each change exactly: Shift 1, from documents to code, in what the architect produces; Shift 2, from gatekeeper to boundary designer, in how authority is exercised; Shift 3, from periodic to continuous, at machine speed, in the tempo of the work; and Shift 4, from sole author to conductor of an AI team, in who drafts it. Together they are this book's answer to the question AI Platform and Security left open, of what machine-speed adversaries and insiders mean for the way architecture itself is designed, reviewed and changed.

The evidence differs by shift. Shifts 1 and 3 are observable: architecture and policy as code are mature and used, and the exploitation window has collapsed to days or less. Shift 2 is observable where zero trust and lightweight change approval have been adopted, and expected more widely as agents in production make gate-based review untenable for routine change. Shift 4 is observable in early adopters, while its effect on the quality of architecture decisions is not established, and the studies of automation point to a risk that experts share. In every shift, what does not change is the accountable human judgement that decides what a boundary should be, verifies what code and AI produce, and answers for the result.

The shifts depend on one another. Code enables boundaries, boundaries enable speed, speed creates the volume that requires an AI team, and the AI team's output can be verified only through code. Each fails when taken too far: code without judgement, boundaries without owners, speed without reversibility, and an AI team that approves itself. The artefact set makes each shift reviewable, and the practical guide places any practice on each shift with evidence.

Nordvik Region and Hansa Mutual stand at different points. Nordvik must start the shifts in order, through contracts and a single post, and Hansa must repair an order it broke by moving into Shift 4 before completing Shift 2. Chapter 4 now defines the transformed role itself, as a role charter kept as code that gives each shift its decision rights.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  3. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
  4. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. (2020). Zero Trust Architecture. (31, Rose et al., 2020)
  5. Structurizr (n.d.). Structurizr DSL language reference. (60, Structurizr, n.d.)
  6. FINOS (n.d.). Architecture as Code: What is CALM? (61, FINOS, n.d.)
  7. Open Policy Agent Contributors (n.d.). Open Policy Agent Documentation. (62, Open Policy Agent, n.d.)
  8. Ward, R. & Beyer, B. (2014). BeyondCorp: A New Approach to Enterprise Security. (68, Ward & Beyer, 2014)
  9. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. (81, Forsgren et al., 2018)
  10. Rinehart, A. & Shortridge, K. (2023). Security Chaos Engineering: Developing Resilience and Safety at Speed and Scale. (88, Rinehart & Shortridge, 2023)
  11. Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. (92, Peng et al., 2023)
  12. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. (93, Becker et al., 2025)
  13. Dell'Acqua, F. et al. (2023). Navigating the Jagged Technological Frontier. (95, Dell'Acqua et al., 2023)
  14. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA Report: State of AI-assisted Software Development. (98, Harvey & DeBellis, 2025)
  15. Bainbridge, L. (1983). Ironies of automation. (106, Bainbridge, 1983)
  16. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (107, Parasuraman & Manzey, 2010)
  17. Lee, H.-P. et al. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. (111, Lee et al., 2025)
  18. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
  19. Larcher, H., Carreira, A. et al. (2026). Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident. (130, Larcher et al., 2026)
  20. Five Eyes cyber security agencies: ASD's ACSC, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK, NSA and CISA (2026). The AI shift in cyber risk: why leaders must act now. (137, Five Eyes agencies, 2026)
  21. Five Eyes cyber security agencies: ASD's ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK (2026). Careful adoption of agentic AI services. (138, Five Eyes agencies, 2026)
  22. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (140, NCSC, 2026)
  23. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. (142, Mandiant, 2026)
  24. Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (143, Charrier & Weiner, 2024)
  25. Grunewald, R., Mazumdar, S. & Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. (145, Grunewald et al., 2026)
  26. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  27. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  28. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  29. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  30. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)