Glossary
This glossary collects the vocabulary that The Transformed Security Architect uses: the four shifts, the artefacts the security architect keeps under version control, the terms of boundary, identity and machine-speed design, the vocabulary of the architect's AI team, the competence frameworks against which the role is measured, and the European instruments that constrain it. Terms used in the earlier volumes of the series keep the meaning given there; where this book relies on such a term, the entry names the volume and chapter. Behaviours of AI systems are described as observable behaviours, not as intentions. Statements about law are attributed to the instrument and article and are architectural implications, not legal advice.
A
ADR (Architecture Decision Record) — A short, numbered, immutable record of a significant architectural decision, its context and its consequences. Architecture as Code (Chapter 4).
AI Decision Record (AIDR) — An Architecture Decision Record with the fields that a decision about AI needs, such as usage mode, autonomy level, evaluation evidence and the obligations it touches. This book uses AIDR-0500 to AIDR-0599: AIDR-0500 to AIDR-0549 for Nordvik Region and AIDR-0550 to AIDR-0599 for Hansa Mutual. AI Platform and Security, Chapter 5.
ATLAS (MITRE ATLAS) — A knowledge base of adversary tactics and techniques against AI systems, used in this book as shared vocabulary for threat models and tests. Chapter 6.
ATT&CK (MITRE ATT&CK) — A knowledge base of adversary tactics and techniques based on observed intrusions, used as the vocabulary for describing adversary behaviour at the level needed to design controls. Chapter 6.
Automation bias — The tendency to accept the output of an automated system without sufficient scrutiny, including when it is wrong. A central risk when the architect reviews AI proposals. Chapter 14.
Autonomy level — The degree of independence granted to an AI capability for a given action, from Level 0 Advisory, Level 1 Assisted, Level 2 Supervised and Level 3 Bounded to Level 4 Autonomous, set from reversibility and blast radius. Level 4 is never used for irreversible actions. AI Red Team, Chapter 6; Chapter 13.
B
Blast radius — The scope of impact of a failure, a compromise or a mistaken action. Containment is designed to bound it. Chapter 7.
Boundary — A designed limit on what a person, workload or agent can reach or do, enforced outside the actor it constrains. The transformed security architect's main product. Chapter 7.
C
C4 model — A hierarchical way of describing software architecture at four levels: context, containers, components and code. Chapter 5.
Competence framework — A versioned definition of the competence domains and levels a role requires and the evidence that demonstrates each. For the security architect: design, code, AI, adversary, law and people. Chapter 21.
Competence record — The versioned evidence of one person's competence against the framework, with identifiers CMP-* (CMP-NR-*, CMP-HM-*). Chapter 21.
Containment profile — The declared limits on what a workload or agent can reach (identity, network egress, data, tools and budgets), enforced whatever the actor intends. AI Platform and Security, Chapters 11 and 19; Chapter 7.
Control catalogue — The versioned set of controls, with identifiers CTRL-*, each mapped to the obligations it helps meet and the evidence it produces. AI Platform and Security, Chapter 17; Chapter 9.
D
Decision tiers — The levels at which decisions are taken, from pipeline and team to design authority and management body, each with written decision rights. AI Governance, Chapter 13; Chapter 17.
Default-deny egress — A network boundary that blocks all outbound connections except those explicitly allowed. Chapter 7.
Delegated authority — Authority that one actor grants to another to act within stated limits, such as a person authorising an agent to act on their behalf. Chapter 8.
Deliberate practice — Effortful, focused practice of a specific skill with feedback, used in this book to keep the craft that verification of AI output depends on. Chapter 15.
Deployer — Under the AI Act, a natural or legal person that uses an AI system under its authority, except in a personal non-professional activity (Regulation (EU) 2024/1689, Article 3). Contrast provider.
Design authority — The forum with written decision rights over architectural decisions above the pipeline tier, including exceptions. AI Governance, Chapter 13; Chapter 17.
Deskilling — The loss of a skill through disuse when automation does the work. Treated in this book as something to be measured and countered, not assumed. Chapter 15.
E
ECSF (European Cybersecurity Skills Framework) — ENISA's framework of twelve cybersecurity role profiles, including the profile "Cybersecurity Architect", used to map the competence framework. Chapter 21.
EPSS (Exploit Prediction Scoring System) — A model that estimates the probability that a published vulnerability will be exploited in the near term, used to prioritise patching. Chapter 10.
EUVD (EU Vulnerability Database) — The European vulnerability database operated by ENISA under NIS 2. Chapter 10.
Evidence manifest — A versioned declaration of which evidence each control produces, where it is stored and how it is verified, tying the evidence chain together. AI Governance, Chapter 11; Chapter 9.
Exception — A recorded, owned and expiring departure from a control or policy (EXC-NNNN), never an open-ended waiver. Chapter 17.
F
Four shifts — The four changes that transform the security architect role, named exactly: 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.
H
High-risk AI system — An AI system classified as high-risk under Article 6 of the AI Act, in Annex I or Annex III, and subject to the requirements of Chapter III of the Act.
Horizon register — A versioned record of trends, each labelled observable, expected or speculation, with the decision it affects and a review date. AI Governance, Chapter 22; for the role, Chapter 23.
K
KEV (Known Exploited Vulnerabilities catalogue) — CISA's catalogue of vulnerabilities with evidence of active exploitation, used as a patching trigger. Chapter 10.
M
Management body — The body that directs an entity, which under NIS 2 Article 20 must approve and oversee cybersecurity risk-management measures and can be held liable, and under DORA Article 5 bears ultimate responsibility for ICT risk. Chapter 18.
Mandate manifest — The written mandate of the architect's AI agents: their tasks, autonomy level per action, tools, data, approvals and stop path, with identifiers MND-* (MND-NR-*, MND-HM-*). Chapter 13.
N
NICE Framework — The NIST Workforce Framework for Cybersecurity, which describes work roles by tasks, knowledge and skills. Chapter 21.
O
Observable, expected, speculation — The three labels for any statement about the future: observable (visible now in adopted law, published guidance or production systems), expected (strongly evidenced but uncertain in timing or form) and speculation (plausible but not yet evidenced). AI Governance, Chapter 22.
On-behalf-of token — A credential that lets a service or agent act for a user with a scope derived from, and narrower than, the user's own, so that the delegation is visible and limited. Chapter 8.
P
Patch velocity — The time from publication of a fix to its deployment across the estate, treated in this book as a service level with targets by severity and exploitation evidence. Chapter 10.
Permission manifest — The declared ceiling on the actions an agent or workload may take, enforced by a policy decision point outside it. AI Platform and Security, Chapter 11; Chapter 7.
Policy as code — Machine-readable rules, kept under version control and evaluated automatically, that express security and governance policy. Chapter 5.
Policy decision point — The component that evaluates a request against policy and returns a decision that a separate enforcement point applies. For AI systems, placed outside the model so that it holds whatever the model produces. Chapter 7.
Prompt injection — The manipulation of an AI system's behaviour through crafted content in its input, including content it reads from documents or tools. Treated as an architectural problem, defended by boundaries outside the model. Chapter 7.
Provider — Under the AI Act, a natural or legal person that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name (Regulation (EU) 2024/1689, Article 3). Contrast deployer.
Purple loop — The practice by which every finding from an exercise, experiment or incident ends as a verified control, closed only when the re-test passes. AI Red Team, Chapter 26.
R
Rego — The policy language of Open Policy Agent, used for policy as code. Chapter 5.
Role charter — The versioned definition of a role's mandate, accountabilities, decision rights and limits (roles/security-architect.yaml, identifiers ROLE-*). Chapter 4.
S
SABSA — The Sherwood Applied Business Security Architecture, a risk-driven method for enterprise security architecture. Chapter 2.
Security chaos engineering — The verification of security capabilities by injecting controlled conditions and checking steady-state hypotheses. AI Red Team, Chapter 25; Chapter 11.
Security architect, the — The role accountable for the security design of systems, boundaries and decision rights. Written in lower case in prose. The transformed security architect is the role as this book describes it after the four shifts. Chapters 1 and 4.
SFIA (Skills Framework for the Information Age) — A global framework of skills and levels of responsibility for digital work. Chapter 21.
Stop path — The means of halting a system that lies outside the system it stops and does not depend on its cooperation. AI Platform and Security, Chapter 19; Chapter 10.
STRIDE — A threat classification of spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, used in threat modelling. Chapter 6.
Structurizr — Tooling for describing architecture models as code with the C4 model. Chapter 5.
T
Threat model — A structured analysis of what can go wrong in a system, kept in this book as a versioned artefact generated from the architecture repository that can fail the pipeline. Chapter 6.
TOGAF — The Open Group Architecture Framework, an enterprise architecture method. Chapter 2.
U
Usage modes — The six ways in which AI is used: 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.
W
Workload identity — A cryptographic identity issued to a workload rather than a person, such as a SPIFFE identity, used to authenticate and authorise machine-to-machine traffic without static secrets. Chapter 8.
Z
Zero trust — A security model in which no actor is trusted by network location, and every request is authenticated and authorised against policy (NIST SP 800-207). Chapter 7.