Conclusions: The Transformed Security Architect

This book began with a question that the five earlier volumes of the series had left behind them: what has happened to the security architect, the person on whose work every one of their conclusions depends? Twenty-six chapters later this chapter answers it. It restates the thesis and tests it against what the chapters found, reflects on each part, draws the conclusions that hold across the parts and says how firm each one is, settles the open questions Q1 to Q12 or says why they remain open, and sets out what organisations and individual architects should do first, next and later. It then shows how the six volumes make one argument, with the security architect as the person who makes that argument executable. As the conclusion of the book it concerns all four shifts: 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. The author's own judgement is kept to one labelled section, as in Chapter 23, and apart from the conclusions the evidence supports.

Figure 27.1: The book's argument in one figure: the series' five commitments are made executable by the four shifts, carried by artefacts kept as code, and serve the scarce resource of accountable human judgement.

The thesis restated

The working thesis, stated in the blueprint and in Chapter 1, was that the security architect role is being transformed, not abolished. It moves from author of documents and reviewer at gates to designer of executable boundaries and decision rights, from periodic review to continuous verification at machine speed, and from sole expert to the accountable conductor of an AI team whose proposals the architect must be able to verify. What remains scarce, and therefore defines the role, is accountable human judgement: the ability to decide what a boundary should be, to verify that code and AI output are sound, and to answer for the decision to a board, a supervisor or a court. Because an architect who cannot do the craft without AI cannot verify AI, the transformed role keeps the craft deliberately.

The chapters support the thesis. Every part of the inherited practice (Chapter 2) either moved into an artefact (Shift 1) or was delegated to a gate, and something remained that neither could hold: the choice of which principle deserves a rule (Chapter 5), the placement of a boundary (Chapter 7), the honest classification of evidence (Chapter 9), the conditions under which a decision may be delegated (Chapter 17) and the review that decides whether an agent's proposal is sound (Chapter 14). Fowler argued two decades ago that the architect's contribution lies in the decisions that are important and hard to change (73, Fowler, 2003), and Hohpe that the architect connects the board with the engine room (74, Hohpe, 2020). Both definitions survive the transformation intact.

The thesis must be qualified in three places. First, the scarce resource is not judgement alone but the capacity to exercise it at the volume the estate now produces. The automation-bias evidence explains why review thins under volume (Chapter 14), and Hansa Mutual's six architects illustrate it: they could not review in depth everything their agents drafted, and the honest response was a queue rather than a thinner review (Chapter 26). Judgement that cannot keep pace is still scarce, but it becomes a throughput constraint as well as a quality one. Second, the transformation is uneven. Shift 1 and Shift 3 are observable; Shift 2 is observable where zero trust and lightweight change approval have been adopted and expected more widely; Shift 4 is observable in early adopters, while its effect on the quality of architecture decisions is not yet established (Chapter 3). Third, transformation is not guaranteed. Chapter 23 showed that the role could disappear without anyone deciding to abolish it, through a sequence of reasonable delegations that remove the fallback before anyone notices. The thesis describes what the evidence shows today and a condition to maintain, not a law of development.

Chapter 1 named the evidence that would refute the thesis, and the book can say how far it met those conditions. Abolition would be supported by organisations that removed the role and kept boundaries that held for years; the book found no such evidence, and the incidents it examined showed boundaries failing where they depended on the cooperation of what they contained (Chapters 7 and 24). Absorption would be supported if decision rights over boundaries moved to platform teams without loss of independent challenge; the book found the operation of boundaries moving to platform teams, but the seams of Chapter 16 still needed a separate holder of the ceiling, so absorption remains a live scenario rather than a refuted one (Chapter 23). Continuity would be supported if the work looked the same after the shifts; the observable evidence for Shifts 1 to 3 (Chapter 3) shows the work changing, although the year of Nordvik Region and Hansa Mutual in Chapter 25 illustrates the change and cannot test it. None of the three conditions can be settled within one book's horizon, because each asks for years of tests and incidents; they remain the measure against which the thesis should be judged again.

Reflections on each part

Each part ended with a lesson that the thesis can be tested against.

Part I, the role in question. The transformed role keeps the function of the gate, independent challenge before an irreversible commitment, while giving up the gate as the place where every decision waits (Chapters 2 to 4). Part II, the craft. The craft did not shrink; it moved from describing what should hold to stating, testing and evidencing what does (Chapters 5 to 11). Part III, the architect's AI team. Conducting is a craft in itself, and it fails silently when the conductor can no longer play (Chapters 12 to 15). Part IV, the role in the organisation. A boundary designer needs written decision rights more than a gatekeeper ever did, because delegation without a written source of authority is abdication (Chapters 16 to 20). Part V, competence and career. Competence is evidenced by practice on real artefacts, and the route by which verifiers are made must be protected on purpose, because automation removes it by default (Chapters 21 to 23). Part VI, experience. The order of adoption matters: where Hansa Mutual ran its agent team before its review quality was measured, the cost arrived later in the year (Chapters 24 to 26).

Cross-cutting conclusions

Seven conclusions hold across the parts. Each is the book's own conclusion, drawn from the chapters named.

The boundary is the product, not the review

The architect's lasting contribution (Shift 2, from gatekeeper to boundary designer) is a boundary that holds whatever anyone or anything inside it does: enforced by something other than the party it governs, owned by a named person, written as an artefact and tested (Chapter 7). Zero trust, as NIST defines it, supplies the structure by removing implicit trust from network location (31, Rose et al., 2020); for agents the action must be verified as well as the actor. The July 2026 incident, treated in Chapters 7 and 24, showed the cost of boundaries that depended on the cooperation of what they contained (129, OpenAI, 2026). This book builds on the conclusion of AI Platform and Security, Chapter 25, that a platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever the contained party does and when evidence is produced by normal operation (169, Nordqvist, 2026). The transformed architect is the person who designs those three properties and answers for them.

Decision rights are written before the pressure

Every successful case in the book wrote its decision rights before it needed them: the charter's rights and time limits (Chapter 4), the tier policy that routes each class of decision (Chapter 17), the stop holder named in advance (Chapter 10) and the delegated patch playbook approved by Hansa's executive board (Chapter 10). This book builds on the conclusion of AI Governance, Chapters 2 and 25, that governance is effective when it is codified, evidenced and proportionate to usage mode and risk, and that the usage mode, not the brand, sets the governance (168, Nordqvist, 2026). Decision rights are the codified form of that proportionality for the architect's own work. A right that is not written down cannot be delegated, sampled or withdrawn.

Time is a design property, and the drill is its evidence

Patch velocity, time to detect and time to stop are properties the architect specifies and the organisation measures (Chapter 10). The exploitation window has fallen to days and, on Mandiant's estimate, below zero (142, Mandiant, 2026), and NIS 2 Article 23 and DORA Article 19 fix reporting clocks in hours (6, European Union, 2022) (9, European Union, 2022). The two organisations illustrate why the drill is the evidence: their first timed stop paths were slower than their budgets, 26 minutes against 15 at Nordvik and 17 against five at Hansa (Chapter 26). A measured shortfall can be fixed; an untested claim cannot.

Verification, not drafting, is the constraint

When AI drafts, the limit on architecture work moves from authoring to verifying (Chapters 14 and 23). Review quality falls under volume unless it is designed to hold, because automation bias and complacency affect experts as well as novices and are not cured by instruction alone (107, Parasuraman & Manzey, 2010). The book's response is to define soundness in advance, use oracles the proposer cannot edit, compute review tiers from reversibility and blast radius, and slow the AI rather than thin the review when the queue grows (Chapter 14).

The craft is kept deliberately, and autonomy is paced to it

Bainbridge's ironies of automation apply to architects: automation leaves the hardest residue to the human while eroding the practice needed to handle it (106, Bainbridge, 1983). This book builds on the conclusion of AI Red Team, Chapter 28, that AI strengthens defence when it acts inside a written mandate, at an autonomy level matched to the reversibility of its actions, under continuous verification (170, Nordqvist, 2026), and adds a condition for the architect's own agents: an action stays at Level 3 Bounded only while two architects could write its playbook unaided (Chapter 15). Autonomy rises with evidenced competence and falls back when it lapses (Chapter 21).

The chain of accountability ends in a person

The approver answers for the approval and the author of a gate answers for the gate, and the chain never ends in an agent (Chapter 4). NIS 2 Article 20 places approval and oversight of cybersecurity risk-management measures on the management body (6, European Union, 2022), DORA Article 5 places ultimate responsibility for ICT risk there (9, European Union, 2022), and Article 26 of the AI Act requires deployers to assign human oversight to people with the necessary competence and authority (1, European Union, 2024). The architectural implication, which is not legal advice, is that the architect's professional responsibility for the soundness of the design, the faithfulness of the mapping and the honesty of the evidence must be recorded so that a management body can rely on it and a supervisor can inspect it (Chapter 18).

Evidence replaces attestation

A control is verified only while a test that re-runs its scenario has passed recently and produced evidence by operation; otherwise it is declared or failed (Chapter 9). The classification turned Nordvik's dependence on suppliers into a visible negotiating position and gave Hansa's board one number it could watch, the share of verified controls. Shared dependencies are counted once, so that coverage measures protection rather than the number of controls.

How the conclusions interact

The conclusions reinforce one another in the chain of dependencies that Chapter 3 set out between the shifts, and the tensions described below are where the failure modes it named for each shift taken too far begin: code without judgement, boundaries without owners, speed without reversibility and an AI team that approves itself. Written rights make delegation possible, delegation makes speed possible, speed creates the volume that makes verification the constraint, and verification depends on the craft and on evidence the proposer does not produce. The boundary bounds the cost of every failure along the chain.

They also pull against each other, and the tensions are where judgement is most needed. Speed pulls against verification, which is the sign-off in seconds of Chapter 24; the book keeps irreversible and self-referential changes at the highest review tier whatever the queue. Delegation pulls against the craft, which is why Chapter 15 reserves learning tasks and Chapter 23 lists a delegation register. Evidence pulls against co-determination, which is why Hansa's review metrics are reported at team level only, on terms agreed with works councils and unions (Chapter 26). Accountability pulls against scale, so Nordvik converted every right that would let one person approve their own work into a recommendation to the CISO (Chapter 4). Each tension is held by a written rule that a person reviews.

How firm the conclusions are

The labels follow AI Governance, Chapter 22: observable trends justify commitment, expected ones preparation and speculative ones reversibility (168, Nordqvist, 2026).

Conclusion	Firmness	What would change it
The boundary is the product, not the review	Observable: containment outside the agent is documented practice and its absence documented in incidents	Reliable intent-independent behaviour of agents, for which there is no evidence
Decision rights are written before the pressure	Observable in leading organisations; expected more widely as agents act in production	Evidence that unwritten delegation performs as well under incident conditions
Time is a design property, and the drill is its evidence	Observable: the shrinking window and the reporting clocks; a supervised patch-velocity metric is expected	A reversal of the exploitation trend
Verification, not drafting, is the constraint	Expected, on the trend in AI task length (100, Kwa et al., 2025) and the evidence on automation bias; Hansa's year illustrates it	Reliable verification of AI by AI, which is speculation
The craft is kept deliberately, and autonomy is paced to it	Observable for reduced checking and skill erosion in other domains; expected for security architects	Controlled evidence that architects keep judgement without unassisted practice
The chain of accountability ends in a person	Observable as law in force; how courts weigh review records is untested	Amendment of NIS 2 Article 20, DORA Article 5 or the AI Act's oversight provisions
Evidence replaces attestation	Observable as practice; supervision by query is speculation	Supervisors accepting machine-generated assurance without a human account

Table 27.1: The cross-cutting conclusions, how firm each is and what would change it.

The firmest conclusions concern boundaries, time and law; the least firm concern what AI will do to the architect's judgement, for which no study of security architecture yet exists. Commit to boundaries and drills now, prepare for verification as the bottleneck, and keep every delegation of judgement reversible.

Answered and open questions

SERIES_FOUNDATIONS.md recorded twelve questions for this book. Table 27.2 records what the book answers and what remains open.

Question	Status	Where
Q1 What the assumption of machine-speed adversaries and insiders means for designing, reviewing and changing architecture	Answered: every design carries four timed properties, every review asks for measured intervals, and every change ships through a pipeline whose approvals were decided in advance	Chapters 3 and 10
Q2 When an AI may change the architecture without per-action approval, and who decides	Answered as the book's position: a tier 3 decision sets a ceiling per class, an agent never changes its own boundary, only tightening or restoring changes may reach Level 3 Bounded behind a gate outside the agent, and Level 4 is not used	Chapter 17
Q3 How AI-proposed change is reviewed for soundness when the reviewer depends on the AI	Partly answered: soundness defined in advance, re-derivation, oracles the proposer cannot edit, provenance, review tiers and seeded errors; whether review holds as volume grows is expected to be the hardest test	Chapters 14 and 15
Q4 Planning for patch-to-exploit times in minutes	Answered for design: delegated patch playbooks and patch velocity as a service level; patch velocity as a supervised metric is expected	Chapters 10 and 19
Q5 What remains of the role when boundaries are code, decisions sit in pipelines and AI drafts	Answered: deciding boundaries and the rules that hold them, verifying what code and AI propose, and answering for both, under written decision rights	Chapters 4, 21 and this chapter
Q6 Who is accountable for an agent-proposed, drafted or merged change	Answered in records: the approver for the approval, the gate author for the gate; the standing of these records before a court is untested	Chapters 4, 14 and 26
Q7 How competence is evidenced when AI does the visible work	Answered: practical demonstration unaided and with AI, the lower level counting, with review records and artefacts that held under test	Chapter 21
Q8 How anyone becomes a security architect when junior work is automated	Partly answered: adjacent starting points, reserved learning tasks, rotation through verification and shadowing of forums; whether these suffice at scale is open	Chapters 15 and 22
Q9 Where the role ends and its neighbours' begin	Answered: four seams, each with one role that proposes, one that holds the ceiling and one that operates; convergence with the AI architect is speculation	Chapter 16
Q10 How a single architect in a procuring authority holds boundaries in suppliers' systems	Partly answered: annexes as code, a catalogue that separates declared from verified, and a stop path on the authority's side; replacing that architect when the post falls vacant remains open	Chapters 20 and 26
Q11 What management-body accountability means for the architect who turns each article into a control	Answered: accountability stays with the body; the architect owes decision-ready information, faithful mappings, honest evidence and a record of advice	Chapter 18
Q12 Whether there will be a security architect in 2036	Open by nature: a horizon register, four scenarios and seven no-regret measures; the author's judgement is in Chapter 23 and below	Chapter 23

Table 27.2: The open questions of Book 6 and how the book leaves them.

Q5 deserves its answer in prose, because it is the question the whole book was written to answer. When boundaries are code, routine decisions sit in pipelines and AI drafts most of the artefacts, three things remain with the security architect: deciding what a boundary should be and writing the rule that holds it; verifying that what code and AI propose is sound, which requires being able to do the work without them; and answering for both to the people who rely on them. Everything else can be moved to an artefact, a gate or an agent. What remains is smaller in volume and larger in consequence.

What to do first, next and later

The sequence below follows the order Chapter 25 found to matter: written authority before delegation, boundaries before speed, measurement before autonomy. The defaults are starting points and must be adapted to the organisation's risk appetite.

First, in the first six months. For organisations: write the role charter with decision rights and time limits, and state what the role does not do (Chapter 4). Put the architect's own AI use under a mandate manifest with a ceiling of Level 1 Assisted (Chapters 12 and 13). Start the control catalogue with the boundaries whose failure would hurt most, normally agent egress, machine identities and the stop path, and classify each control by evidence (Chapter 9). Time one stop path in a drill (Chapter 10). For individual architects: keep a share of work unassisted, draft first and record which drafts came from a tool (Chapters 12 and 15).

Next, from six to eighteen months. For organisations: measure the review board's queue and delegate the routine classes to gates after shadow running (Chapter 17); write containment profiles and permission manifests for every Mode 5 agent (Chapter 7); introduce review tiers and a review-quality metric agreed with employee representatives (Chapter 14); open competence records and a learning path for every architect (Chapters 21 and 22); and generate the board's view from the catalogue (Chapter 19). For individual architects: reach Practitioner in the code domain if you are not there, and take part in a seeded-error drill as reviewer and as seeder.

Later, from eighteen to thirty-six months. For organisations: raise the autonomy of any agent action only on conditions recorded in advance, never to Level 4 for an irreversible action (Chapter 17); keep a horizon register for the role and a delegation register with yearly reversibility tests (Chapter 23); bring every regime the organisation answers to into the catalogue as an overlay that can only tighten the baseline (Chapter 20); and reserve learning tasks for those entering the role (Chapter 22). For individual architects: mentor someone through work the agents could do, and keep the competence record honest about the difference between the assisted and the unassisted level.

Across the usage modes

The book's position across the modes and levels can be stated in one table. The architect uses AI in Modes 1 to 3 and answers for it; designs boundaries that hold for Mode 5 agents whatever they do; and matches the autonomy level of every agent, including the architect's own, to the reversibility of its actions.

Usage mode	The architect's relation to it	Autonomy the book allows in architecture work	First thing to do
Mode 0 Ambient AI	Finds and contracts vendor AI before relying on it	Whatever is established and recorded by contract	Inventory AI features in security products
Mode 1 Conversational assistants	Uses with own identity and answers for output	Level 0 Advisory and Level 1 Assisted	Route by classification; keep a work log
Mode 2 Embedded workplace assistants	Uses with own identity; classifies what reaches the feature	Level 0 Advisory and Level 1 Assisted	Decide which architecture information may reach it
Mode 3 Agentic work tools	Directs under a mandate manifest	Drafts at Level 1 Assisted; executed actions at Level 2 Supervised	Write the mandate manifest and its ceiling
Mode 4 Built AI applications	Reviews through generated threat models and gates	Not applicable to the architect's own work	Generate the threat model from the architecture model
Mode 5 Autonomous production agents	Designs containment that holds whatever the agent does; the architect's evidence collector is one	Level 3 Bounded for reversible actions only; Level 4 never for irreversible ones	Time the stop path

Table 27.3: The book's position across the usage modes and autonomy levels.

Practical guide: Taking up a transformed security architect role in the first 90 days

Purpose. Give a newly appointed security architect, or one whose role has just been rewritten, a sequence that establishes authority, knowledge of the boundaries and calibrated judgement before the architect approves anything an agent proposes. Roles. The new architect drafts and executes the plan; the head of security architecture or the CISO approves it and acts as mentor; a peer architect reviews the boundary map and the calibration; employee representatives are informed where the plan creates records about the person.

1. In the first week, read the role charter and list every decision right with its time limit and its override. Where no charter exists, draft one from Chapter 4 and make its approval the first milestone.
2. By day 30, map the boundaries the post owns from the architecture model, not from slides, and merge the map as a pull request reviewed by a peer. List every boundary without a recent test as a finding.
3. By day 30, shadow at least two sessions of the decision forum and one stop-path drill, so that the architect knows who holds each stop decision before needing it.
4. By day 60, produce one threat model and one boundary design unaided, then compare each with what the agent team drafts for the same change. Record the differences in the competence record, not in an appraisal.
5. By day 60, complete a calibration on seeded errors before joining the approver pool. Default: at least 20 proposals and a catch rate at or above 0.85; adapt the threshold to the organisation's own review-quality target.
6. By day 90, lead one timed stop drill for a system the post owns and sign the first review records as approver at the tiers the charter allows.
7. Throughout, protect unassisted practice. Default for a new post-holder: half a day a week, twice the team's standing default, for the first 90 days.
8. Do not, before day 90, approve at the highest review tier, propose changes to the mandate manifest of the architect's agents or hold the second-owner signature on a protected path.

Definition of done. The decision rights are known and written; the boundary map is merged and its untested boundaries are findings with owners; the calibration and the unaided exercises are recorded; one drill has a measured time against its budget; and no approval was given before the calibration passed.

Worked example: A first-90-days plan as code

Illustrative example. Hansa Mutual's security architect post embedded at the Polish service centre, through which the claims-triage agent works, fell vacant in January 2027 and was filled from outside in June under the hiring profile HP-HM-2027-01 and the decision recorded as AIDR-0584 (Chapters 22 and 25). The plan below is the new post-holder's first 90 days, drafted by the post-holder and approved by the head of security architecture. It sits beside the charters in the group's repository.

# plans/first-90-days/PLAN-HM-SA-PL-90.yaml (Hansa Mutual, illustrative)
id: PLAN-HM-SA-PL-90
post: security architect embedded at the Polish service centre
charter: ROLE-HM-SA-PL
hiring_decision: AIDR-0584
competence_record: CMP-HM-08
mentor: head-of-security-architecture
approved_by: head-of-security-architecture
period: {from: 2027-06-01, to: 2027-08-29}
own_ai:
  mandate: MND-HM-01
  max_level_own_tools: Level 1 Assisted
  approver_pool_from: calibration-passed
  unassisted_practice: half a day per week
phases:
  - name: first
    days: 1-30
    deliver:
      - decision rights listed with time limits and overrides
      - boundary map of the claims-triage agent from the architecture model
      - two design-authority sessions and one stop drill shadowed
    verify: boundary map merged; untested boundaries raised as findings
  - name: next
    days: 31-60
    deliver:
      - unaided threat model of one claims-triage change, compared with the agent draft
      - seeded-error calibration on 20 Tier 1 and Tier 2 proposals
      - evidence age checked for every control the post owns
    verify: calibration catch rate at or above 0.85
  - name: later
    days: 61-90
    deliver:
      - Tier 1 and Tier 2 approvals on service-centre paths
      - timed stop drill of the claims-triage agent led by the post-holder
      - first service-centre signals recorded for the role register due in November
    verify: drill time recorded against budget; review records signed
not_before_day_90:
  - approve Tier 3 changes
  - propose changes to MND-HM-01
  - sign as second owner on a protected path
records:
  terms: AIDR-0566
  reported: team-level only
  used_for_appraisal: false

Three choices in the plan matter. The new architect joins the approver pool on evidence of calibration, not on a date, because an approver who has not been calibrated is the sign-off in seconds of Chapter 24 waiting to happen. The unaided threat model comes before any approval, so that the comparison with the agent's draft shows the post-holder, and the mentor, what the post-holder can verify. And the plan names what the post-holder may not do yet, in the same form as the charter's does_not list, so that a limit is a written rule rather than an expectation. The plan ends with the craft calibrated rather than with throughput, because from September the post-holder is the day-to-day senior of the junior architect of Chapter 15.

The series as one argument

The six volumes were written for different readers but make one argument. Architecture as Code made architecture executable, with agents that draft and humans who approve, and its Chapter 27 asked who holds responsibility for machine-authored artefacts and whether version control captures the soundness of reasoning (167, Nordqvist, 2025). AI Governance made governance codified, evidenced and proportionate to the usage mode, and in its Chapter 24 kept the author's judgement apart from its findings (168, Nordqvist, 2026). AI Platform and Security built the platform on which every model call and tool call passes a policy point outside the model (169, Nordqvist, 2026). AI Red Team put AI to work in cyber defence under a written mandate, at autonomy levels matched to reversibility (170, Nordqvist, 2026). AI Threat weighed the evidence behind the mechanisms fiction dramatised and concluded that 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 (171, Nordqvist, 2026).

This book adds the person. Each of the five commitments is a design decision that someone has to take, write down, test and answer for, and in most large European organisations that someone is the security architect. Correctable records are the decision records, the catalogue and the charter; the stop outside what it stops is the timed stop path; people able to judge are evidenced by competence records; reversible dependence is the delegation register and the exit plan; autonomy matched to reversibility is the tier policy and the mandate manifest. The four shifts make those commitments executable, and the artefact set is where they live. The role is kept honest by the same argument applied to itself: its own decisions recorded, its own agents stoppable, its own judgement kept, its own delegations reversible and its own autonomy matched to what it can undo.

The author's judgement

This section was drafted on the author's behalf from the book's content and is to be reviewed and personalised by the author before publication. It is a projection, labelled as such, and is not one of the book's findings.

My judgement in Chapter 23 was that there will be a security architect in 2036, in a mixture of the governance and command scenarios, and that the role's disappearance, if it comes, will come by delegation rather than by decision. Writing the conclusion has not changed that view, but it has sharpened where I think the risk lies.

I think Shift 4 is the hardest of the four, and the one most likely to be done badly. The first three shifts have clear evidence of failure: a boundary that leaks, a drill that runs late, a control whose evidence expires. Shift 4 fails quietly. The approvals continue, the pipeline stays green, and nobody notices that the reviewer has stopped reviewing until a fluent proposal that was wrong reaches production. My projection is that, in the next few years, more harm to security architecture practice will come from well-run agent teams whose review quality has decayed than from agents acting beyond their mandates, because the second is now designed against and the first is designed against only where someone measures it.

I also think the profession undervalues the craft it is about to lose. Many architects I have worked with learned their judgement by writing threat models badly and having them corrected, and most of that apprenticeship is the work that agents now do first. My judgement is that organisations that reserve learning tasks and protect unassisted practice will have security architects in ten years, and those that do not will have people who sign.

Two of my judgements go beyond the evidence and could be wrong. The first is that verification of AI by AI will not become reliable for the open-ended, adversarial judgement that boundary design needs within the horizon of this book; if it does, much of Part III will need rewriting. The second is that European law will continue to require a person who can explain the design; if supervisors come to accept machine-generated assurance without a human account, the role will contract faster than I expect, whatever its usefulness.

The advice I would give a newly appointed security architect is short. Get your decision rights in writing before you need them. Learn to express a boundary as code and to test it from outside. Time a stop path in your first quarter. Keep doing some of the work yourself. And never approve what you could not have written.

The judgement ends here.

A call to the profession

Security architects owe the organisations and the people who depend on them three things, and the transformation makes each more demanding rather than less.

They owe them boundaries that hold: independent of the goodwill of what they contain, tested from outside, and reported plainly when one has failed. They owe them honest evidence: a catalogue that reports a declared control as verified, or a board page that omits what is not measured, transfers risk to people who did not choose it, and the classification into verified, declared and failed exists so that bad news takes the same form as good.

And they owe them judgement that is still their own. The European Cybersecurity Skills Framework describes the cybersecurity architect by what the role designs and assures (41, ENISA, 2022), and the International AI Safety Report 2026 recorded rapid but uneven gains in what general-purpose AI can do (128, Bengio et al., 2026). The profession's obligation is to remain the people who can tell when fluent is wrong, and to build the learning routes and records that let the next generation do the same. The Cyber Resilience Act asks manufacturers to design products with digital elements for security from the outset (12, European Union, 2024); the book has argued the same for the role: security designed in, evidenced and maintained, not asserted at a gate.

Nordvik Region and Hansa Mutual

The fuller comparison is in Chapter 26. The same four shifts produced a contract-first plan at Nordvik Region (ROLE-NR-SA-01, a small catalogue led by controls in suppliers' systems, tender annexes as code with a stop path the Region can exercise, any agent team deferred until two people can supervise one, a deputy from the platform team) and a delegation-first plan at Hansa Mutual (a review board relieved of routine change by gates, review tiers and seeded errors for agent proposals, generated evidence, and indicators for the management body). Both rest on accountable human judgement that each chose to keep deliberately, and both left open a limit set by people: one post at Nordvik, review throughput at Hansa.

Summary

The thesis has held: the security architect role is being transformed, not abolished. Across twenty-six chapters every part of the inherited practice either moved into an artefact or was delegated to a gate, and what remained was accountable human judgement: deciding what a boundary should be, verifying what code and AI propose, and answering for both. The thesis is qualified in three places: the scarce resource is also a throughput constraint, the transformation is uneven, and the role can be lost by delegation rather than decision.

Seven conclusions hold across the parts: the boundary is the product, decision rights are written before the pressure, time is a design property evidenced by drills, verification is the constraint, the craft is kept deliberately and autonomy is paced to it, the chain of accountability ends in a person, and evidence replaces attestation. The conclusions about boundaries, time and law are observable; that verification becomes the constraint is expected; reliable AI-on-AI verification and supervision by query remain speculation. Of the twelve open questions, the book answers eight, three in part, and leaves Q12 open by nature, with the author's judgement in its own section.

The chapter concluded all four shifts. Shift 1, from documents to code, gave the role its artefacts; Shift 2, from gatekeeper to boundary designer, gave it written decision rights and boundaries that hold whatever the contained party does; Shift 3, from periodic to continuous, at machine speed, made time a measured property; and Shift 4, from sole author to conductor of an AI team, made verification and the craft that sustains it the centre of the role. The first-90-days plan shows the sequence for one person: authority first, boundaries second, calibration before approval.

Read with the five earlier volumes, the book names the person who makes the series' argument executable. The glossary and Appendix A that follow collect the terms and the fuller artefacts on which the chapters rely.

Sources

1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
2. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union. (6, European Union, 2022)
3. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (9, European Union, 2022)
4. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union. (12, European Union, 2024)
5. Rose, S., Borchert, O., Mitchell, S. & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. (31, Rose et al., 2020)
6. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. ENISA. (41, ENISA, 2022)
7. Fowler, M. (2003). Who Needs an Architect? IEEE Software. (73, Fowler, 2003)
8. Hohpe, G. (2020). The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. O'Reilly Media. (74, Hohpe, 2020)
9. Kwa, T., West, B., Becker, J. et al. (2025). Measuring AI Ability to Complete Long Tasks. (100, Kwa et al., 2025)
10. Bainbridge, L. (1983). Ironies of automation. Automatica. (106, Bainbridge, 1983)
11. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors. (107, Parasuraman & Manzey, 2010)
12. Bengio, Y. et al. (2026). International AI Safety Report 2026. International AI Safety Report. (128, Bengio et al., 2026)
13. OpenAI (2026). OpenAI – Hugging Face Incident Technical Report. (129, OpenAI, 2026)
14. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Cloud Blog. (142, Mandiant, 2026)
15. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (167, Nordqvist, 2025)
16. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (168, Nordqvist, 2026)
17. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (169, Nordqvist, 2026)
18. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (170, Nordqvist, 2026)
19. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (171, Nordqvist, 2026)