Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design

A security architect has always designed for confidentiality, integrity and availability. This chapter adds a property that the earlier chapters of Part II assumed without naming: time. It asks how fast the estate can notice that something is wrong, decide what to do and act, and it treats the answer as a property of the design that the architect owns, in the way the architect owns a boundary. The chapter concerns Shift 3, from periodic to continuous, at machine speed, because patch velocity, detection, containment and the stop path are measured continuously and not reviewed once a year. It concerns Shift 2, from gatekeeper to boundary designer equally, because the decisions that must be taken in minutes cannot wait at a gate and are delegated in advance, with written decision rights and conditions that the architecture enforces.

The chapter builds on the conclusions of the earlier volumes. Architecture as Code (Chapter 9B) held that manual incident response cannot scale when attacks develop within minutes and that compromised components are redeployed from known-good definitions (167, Nordqvist, 2025). AI Governance, Chapters 13 and 24, held that stop decisions and patch decisions are named and delegated before they are needed (168, Nordqvist, 2026). AI Platform and Security, Chapter 18, committed to patch velocity as a service level and to detection at machine speed with the authority to act (169, Nordqvist, 2026), and AI Threat, Chapter 30, held that the right to stop must be cheaper to exercise than the right to continue (171, Nordqvist, 2026). Two questions were left open: what machine-speed adversaries and insiders mean for the way architecture itself is designed, reviewed and changed, and whether patch velocity will become a supervised metric. Chapter 7 places the boundaries and Chapter 11 treats recovery; this chapter owns how fast the estate acts in between.

The threat clock and the estate clock, with telemetry, delegated decisions, patchable design and the stop path as design properties that shorten the intervals the estate controls

Figure 10.1: The threat clock starts when a patch or advisory is published. The estate clock has four intervals, and each design property of this chapter shortens one of them.

The collapsing window

Mandiant measured the average time from disclosure to exploitation at 63 days in 2018 and 2019 and at five days in 2023 (143, Charrier & Weiner, 2024). M-Trends 2026 estimated the mean time to exploit at minus seven days, so exploitation now often begins before a fix exists (142, Mandiant, 2026). The architect can design the estate's clock and not the adversary's.

The Google Threat Intelligence Group reported in September 2026 that in-the-wild exploitation rose from an average of 10.5 vulnerabilities a month in 2025 to 18 a month in 2026, driven by rapid weaponisation of newly disclosed vulnerabilities rather than by new zero-days. The same analysis found that only 0.23 per cent of disclosures were exploited and called the trend an early indicator, not an established one (145, Grunewald et al., 2026). The small exploited fraction is why prioritisation works.

AI-assisted discovery adds volume. Google's Big Sleep agent found an exploitable flaw in the SQLite database engine before release that 150 CPU-hours of fuzzing had missed (147, Google Project Zero, 2024). In the final of DARPA's AI Cyber Challenge in August 2025, the competing systems patched synthetic vulnerabilities, 43 in all, in 45 minutes on average (148, DARPA, 2025). In April 2026 Anthropic reported that a frontier model could turn public vulnerability identifiers into working Linux kernel exploits faster and more cheaply than before, and that fewer than one per cent of the flaws it had found were then fully patched by their maintainers (149, Carlini et al., 2026); it restricted access through Project Glasswing so that defenders could work first (150, Anthropic, 2026). The National Cyber Security Centre (NCSC) assessed that the window had shrunk to days and that AI would almost certainly shorten it further (139, NCSC, 2025), and advised organisations to prepare for a wave of patches by patching quickly, more often and at scale (140, NCSC, 2026).

Agents compress the intrusion itself. Google and Mandiant reported in October 2026 that open-source agentic frameworks had been abused in the wild, with execution bursts of seconds and one campaign going from a first compromised account to deep access in about four hours, and that such frameworks traded stealth for velocity (146, Blum et al., 2026). In the July 2026 incident an agent spent days in another organisation's systems, and its operator was reported not to have noticed for a week (132, Satter et al., 2026). AI Governance, Chapter 19, drew the lesson that the controls failed together: a shared credential, a package mirror that was also an egress path and an alert that reached people who did not hold the stop decision (168, Nordqvist, 2026).

Observable, expected and speculation

The shrinking window, the rise in weaponised n-days and AI-assisted discovery in real software are observable. That patch velocity will become a supervised metric is expected, on a stated signal: in July 2026 the European Central Bank wrote to significant institutions about AI-enabled cyber threats, placed the response primarily with their management bodies and asked for action plans (21, ECB, 2026). Exploitation within minutes of disclosure as the normal case for exposed, widely deployed software is expected, not certain, because the evidence is a trend with documented caveats. The broader claim that most significant intrusions and insider actions, including an organisation's own agents', unfold in minutes remains speculation, the label AI Platform and Security, Chapter 25, gave the whole claim. The design consequence is the same under all three labels: an estate that can act in minutes for the few events that need it loses little if the window stops shrinking, and one that cannot has no remedy if it does not.

Four intervals the architect owns

The architect cannot shorten the adversary's clock, but the estate's clock has four intervals, and each can be designed. Notice runs from the trigger, whether an advisory entering a priority class or an anomalous action, until a person or pipeline that can act knows. Decide runs until someone with the right to act has chosen. Act runs until the control is in effect, whether a patch, a compensating control, an isolation or a stop. Verify runs until independent evidence shows the effect. A service level that states only the total hides where the time goes, and in most estates the answer is the decide interval: the weekly change board, the approval waiting for a signatory, the alert that reached an analyst without authority. The next four sections take one interval each, and the chapter then joins them in the stop path and in reporting.

Patch velocity as a service level

Patch velocity is the time from the moment a vulnerability enters a priority class to the moment a fix or compensating control is in place and verified. It becomes a service level when the organisation commits to a target per class, measures the share that meets it and reports misses with reasons. AI Red Team, Chapter 11, builds the prioritiser and the policy that computes it (170, Nordqvist, 2026). The architect's contribution is to set classes and targets that the architecture can meet, and to design the architecture so that it can.

Three public signals define the classes and local exposure completes them. The Exploit Prediction Scoring System (EPSS) estimates the probability that a published vulnerability will see exploitation activity in the next 30 days (151, FIRST, n.d.). The Known Exploited Vulnerabilities (KEV) catalogue of the US Cybersecurity and Infrastructure Security Agency (CISA) lists vulnerabilities with evidence of active exploitation (152, CISA, n.d.), and CISA's Binding Operational Directive 22-01 is an early example of an authority fixing the service level, by setting due dates for federal agencies to remediate catalogue entries (193, CISA, 2021). The European Vulnerability Database (EUVD), launched by the European Union Agency for Cybersecurity (ENISA) in May 2025 under the NIS 2 Directive, adds a European record (153, ENISA, 2025). None of the three says whether an adversary can reach the asset in question; exposure does, and it comes from the inventory. NIST frames patching as preventive maintenance, planned in advance in maintenance plans that set out routine updates, emergency updates, emergency mitigations and what happens to assets that cannot be patched (35, Souppaya & Scarfone, 2022).

NIS 2 Article 21(2)(e) lists vulnerability handling and disclosure among the measures that essential and important entities must take, and Article 20 makes their management bodies approve and oversee them (6, European Union, 2022). A service level, with its trend and the reasons for misses, is the form in which a management body can show that it has done so.

Practical guide: Setting a patch-velocity service level from EPSS, KEV and exposure

Purpose. Replace a single patching target with service levels per class that the architecture can meet, and find the design changes needed where it cannot.

Roles. The security architect proposes the classes and design requirements; the vulnerability management lead owns measurement; asset owners and suppliers accept the targets; the CISO approves exceptions; the management body receives the report.

  1. Take the asset inventory, generated from build pipelines and including AI platform components, and tag each asset with its exposure (internet-facing, internal, supplier-hosted) and the business service it supports.
  2. Measure the last 90 days of actual velocity per exposure group. This is the baseline, and it usually shows the decide interval as the largest term.
  3. Define the classes from the signals, using the defaults in the table below and recording any adaptation to risk appetite.
  4. Split each target into the four intervals. Remove first any interval that is waiting for a meeting, by delegation, and any that is manual work, by redeployment from definitions.
  5. Mark supplier-owned assets. For those the target becomes a contract clause, with the compensating control the supplier must apply when a fix is late.
  6. Record each unavoidable miss as an expiring exception with an owner, a compensating control and a date.
  7. Report the share within target per class to the management body monthly.

Definition of done. Every internet-facing asset has a class; every class has a target split into four intervals; the baseline and the first month's performance are recorded; supplier-owned assets carry contract clauses.

Class Signal Protect within Decision path
Exploited and exposed KEV or EUVD exploited, internet-facing 24 hours mitigation, 72 hours fix Delegated in advance
Exploited, internal KEV or EUVD exploited, internal 7 days Delegated in advance
Likely and exposed EPSS of 0.5 or more, internet-facing 7 days Expedited standard change
Critical, not exploited Severity critical 30 days Standard change
Routine None of the above 90 days Standard change

Designing for patchability

A service level of 72 hours is a promise that the architecture either makes possible or does not. The obstacles are rarely the patch itself: an application nobody can rebuild, a dependency pinned three years ago, a database cluster with no tested rollback, an appliance whose update needs a window booked a month ahead. The architect reviews for these at design time, as for trust zones.

Patchability has five checkable properties. Components are deployed immutably and redeployed from known-good definitions, so a patch is a new build and a compromised instance is replaced and not repaired (167, Nordqvist, 2025). The inventory knows every component and version without a person updating it, which shortens the notice interval. A rollback has been exercised within a stated period, which is what makes delegation safe. Dependencies can move: the architecture avoids forks and long pins, and records the reason for each pin as a decision with an expiry. And compensating controls are prepared in advance for each class of component, such as a virtual patch rule at the edge, a feature switch or an isolation path, so that they can be applied within minutes of an advisory. The NCSC's advice to adopt update by default, with exceptions for safety-critical and operational systems, assumes all five (140, NCSC, 2026).

AI changes where the effort falls. Systems like those of the AI Cyber Challenge draft patches in minutes (148, DARPA, 2025), so the scarce step is verifying a fix and deploying it safely. A design review that asks for a tested rollback and a canary ring for every component in the exploited-and-exposed class is a review of the architecture's capacity to absorb a patch wave.

Where the component belongs to a supplier, the architect cannot design the patchability and must specify it. The Cyber Resilience Act obliges manufacturers of products with digital elements to handle vulnerabilities and provide security updates without delay (Annex I, Part II) (12, European Union, 2024), and since 11 September 2026 to notify actively exploited vulnerabilities through a single reporting platform (13, European Commission, 2026). Those duties give a purchaser a baseline for a clause, but a duty to act without delay is not a service level, so the contract still has to state a time.

Decisions delegated in advance

A weekly change advisory board cannot sit in the path of a known-exploited vulnerability on an exposed asset. The weighing the board exists to do has already been done for that class: the risk of waiting exceeds the risk of changing, provided the change can be reversed. AI Governance, Chapter 24, concluded that this weighing is recorded once, as a delegated decision for a defined class of change, and that the board sees every use of it afterwards (168, Nordqvist, 2026). Delegation moves the human approval from the action to the playbook and the decision record, which concentrates accountability.

For the security architect this is Shift 2 in its plainest form: the gatekeeper says yes or no to each change, and the boundary designer decides which changes need no gate and builds the check that enforces the conditions. A delegated decision has five parts: the class of change, the conditions that must hold, the role authorised to apply it, the time within which it must be applied and the evidence it leaves. The architect's contribution is mainly the conditions, because they are properties of the architecture: a tested rollback, a health check, a canary ring, an exclusion list.

Containment decisions need the same treatment. Isolating an exploited service, suspending an agent's write credentials or closing an egress route are decisions that a duty analyst or a contracted provider must be able to take at three in the morning. The right, the conditions and the evidence are written beforehand and recorded as an AI Decision Record (AIDR), so that a supervisor or successor can see who decided what and why. Forums keep appetite, exclusions and the review of every use, as AI Governance, Chapter 13, assigns, and the management body decides whether the delegation stands, as NIS 2 Article 20 and DORA Article 5(2) place that responsibility with it (6, European Union, 2022) (9, European Union, 2022).

Worked example: A delegated playbook for known-exploited vulnerabilities at Hansa Mutual

Illustrative. Hansa Mutual's change advisory board meets weekly, and the group's vulnerability management team found that its calendar was the largest single term in the time to fix exposed, known-exploited vulnerabilities. The group security architecture team proposed that the board's role for the exploited-exposed and exploited-internal classes of the patch-velocity policy HM-PATCH-SLO-2027 be replaced by a delegated playbook. The executive board approved it, and it is recorded as AIDR-0554.

# Illustrative: Hansa Mutual, decisions/AIDR-0554-delegated-patch-playbook.yaml
adr_id: AIDR-0554
title: Delegated playbook for fixes to known-exploited vulnerabilities
status: Accepted
date: "2027-01-12"
next_review_due: "2027-07-12"
deciders: [head-of-security-architecture, group-ciso]
approved_by: executive-board
replaces: change-advisory-board review for the classes below
policy: HM-PATCH-SLO-2027
classes: [exploited-exposed, exploited-internal]
applies_in: [DE, NL, SE, NO, UK, CH, PL]
authorised_roles: [platform-engineer-on-call, soc-duty-analyst]
timing:
  decision_latency_target_minutes: 0   # no meeting in the path
  mitigate_within_hours: 24
  fix_within_hours: 72
conditions:
  - fix_published_by_supplier_or_proven_internally
  - rollback_tested_within_days: 90
  - canary_ring_and_automatic_rollback_enabled
  - post_change_health_check_required
excluded_from_delegation:
  - irreversible_firmware_or_storage_format_changes
  - changes_to_security_tooling_itself
  - safety_or_regulatory_critical_systems_in_register
agents:
  may_apply_fixes_in_production: false   # the pipeline applies, under a person's delegated authority
enforcement:
  policy_check: policies/change/delegated_patch.rego   # fails the change if a condition is missing
  evidence: evidence://change-pipeline/delegated-patch/
reporting:
  to: [architecture-review-board, group-ai-governance-board]
  every_use_listed_after_the_fact: true
review_triggers: [missed_target_two_months_running, failed_rollback_test, incident_linked_to_delegated_change]

The Rego policy fails any change that claims the delegation without a rollback test inside 90 days, so a stale test withdraws the delegation for that asset group automatically and does not wait for a review. The pipeline applies the fix, and no agent does, which keeps the delegation at a person's authority. The board's agenda for these classes changes from approving fixes to reviewing the list of fixes applied.

Detection designed in

Detection added after a system is built looks at what the system happens to emit. Detection designed in starts from a requirement: this element must emit these events, in this form, to this store, and these behaviours must raise an alert. The architect owns the requirement. Detection engineering owns the rules that meet it, which AI Red Team, Chapter 19, describes as versioned code with tests and mappings to MITRE ATT&CK and ATLAS techniques (170, Nordqvist, 2026) (46, MITRE, n.d.) (47, MITRE, n.d.).

Three practices make detection part of the architecture. Telemetry is a property of each element in the architecture model of Chapter 5: an element declares the identity, administrative, data-access and tool-call events it emits, and a pipeline check fails a change that adds an element emitting none. The threat model of Chapter 6 produces detection requirements, and coverage is the share of them that a tested detection satisfies. And detections are versioned beside the system they watch, so that a change that would blind one fails the pipeline like a failing unit test.

The signatures that matter at machine speed are those that agents produce and people do not: bursts of directory enumeration within seconds, many tokens issued in a short interval and use of a token from new infrastructure (146, Blum et al., 2026). Detection works against agents that trade stealth for velocity only if it also runs at machine speed and the alert reaches someone with authority to act. The July 2026 incident failed on both counts (132, Satter et al., 2026) (168, Nordqvist, 2026). NIS 2 Article 21(2)(b) names incident handling as a required measure (6, European Union, 2022), and DORA Article 10 requires financial entities to detect anomalous activity promptly, with alert thresholds and criteria that trigger the response (9, European Union, 2022). An alert that reaches a person without the decision right produces a record and no response.

Where detection is bought as a service, the architect writes it as a requirement. Supplier-default rules are written for an average customer and changed on the supplier's schedule, and the buyer rarely knows which were silenced during a noisy week. The requirement is that the content is held in the buyer's repository and can be tested by the buyer, that high-confidence alerts reach the buyer's on-call within minutes and that the service has written authority to take named containment actions.

Worked example: Machine-speed requirements for Nordvik Region's managed security service provider

Illustrative. Nordvik Region's out-of-hours monitoring is contracted to a European managed security service provider (MSSP) under framework agreement NR-2025-044, which already requires processing and log storage inside the EU and EEA. The security architect specified the requirements below as an annex for the next call-off. Public procurement law shapes the form: they are stated as measurable outcomes and tests, not as a named product, so that they can be evaluated and re-tendered.

# Illustrative: Nordvik Region, annex MS-1 to framework agreement NR-2025-044
annex: MS-1
subject: Machine-speed detection and containment requirements
owner: security-architect          # requirement owner; the MSSP service manager owns delivery
detection_content:
  held_in: region-detection-repository   # the Region's repository, deployed to the MSSP platform
  supplier_default_rules: allowed_as_baseline_with_listed_ids_only
  portability: exportable_in_sigma_and_platform_syntax_at_exit
  change_control: pull_request_reviewed_by_region_analyst
notification:
  high_confidence_alerts: [canary_touch, enumeration_burst, token_from_new_infrastructure]
  page_region_on_call_within_minutes: 5
  channel: two_independent_routes_registered_in_advance
authority_to_act:
  out_of_hours_without_prior_approval:
    - isolate_internet_facing_service        # from runbook list RB-NR-ISOLATE-01
    - disable_user_account
    - revoke_agent_or_service_credentials
  excluded: [benefits-triage-production-database]
  every_action_reported_within_minutes: 15
verification:
  quarterly_injected_test: region_runs_benign_emulation_unannounced
  pass_criteria: {detect_within_minutes: 10, page_within_minutes: 5, act_within_minutes: 20}
  failure_consequence: remediation_plan_within_10_working_days
reporting:
  monthly: [time_to_page, time_to_act, rules_silenced_with_reason, coverage_by_attack_technique]
legal_notes:
  nis2: Article 21(2)(b) incident handling and (d) supply chain security
  processing_location: EU_EEA_only

The annex gives the Region what one security architect and six office-hours analysts cannot build: detection content it owns and can move, a page that reaches a person in minutes and a service that may act at night. The injected test makes the numbers observable and not declared.

Canaries and honeytokens as architecture

A canary is an object that no legitimate process has a reason to touch: a credential, a record, a document, a host entry or a tool that exists only to be found. A honeytoken is the same idea applied to data. Because legitimate use is zero by design, a touch is a high-confidence alert that needs no baseline. MITRE D3FEND lists decoy objects, credentials and sessions among its countermeasures (48, MITRE, n.d.). The architect treats them as architecture and not as something the SOC adds later, because placement needs knowledge of the design.

Four properties define a canary that works. It does not reveal itself, so that it looks, in listings and among the data around it, like the genuine objects. It has no legitimate dependants, so every scanner, backup job and inventory crawler that might touch it is a recorded exception with an owner. Its registry lives outside the reach of what it watches: AI Platform and Security, Chapter 19, concluded that control artefacts sit outside an agent's reach and that detection comes from telemetry and decoys, not from the agent's own account of what it did (169, Nordqvist, 2026). And its alert is wired to a decision right, because a canary that pages an analyst who cannot act has only proved that something went wrong.

Placement follows the estate: a decoy credential in a vault path that the workload's identity can list but no workload uses; a decoy record or file; for agents, a decoy tool in the registry that no task needs and a decoy document in the retrieval corpus. Because agents read what is within reach, a touch shows that an agent has gone beyond its task whatever the reason, which suits the principle that containment must not depend on intent. AI Threat, Chapter 23, added that where models may behave differently under test, assurance includes decoys that do not reveal themselves (171, Nordqvist, 2026). Two cautions apply. Decoys must be maintained and rotated, and a stale canary is worse than none because it creates confidence. And the registry is sensitive, so it is kept where agents and ordinary engineers cannot read it.

The stop path as a timed property

The stop path is the last of the four properties and the one most often built wrongly. AI Governance, Chapter 13, concluded that stop decisions are named in advance, that the incident commander and the use-case owner may each stop a system without prior approval, and that restart needs the owner and, for high-risk systems, the risk function (168, Nordqvist, 2026). AI Threat, Chapter 30, added that stop holders must be able to act within the time the threat allows, which is minutes for an agent on a production estate (171, Nordqvist, 2026). The architect turns those sentences into a design with a clock.

A stop path has four design requirements. It lives outside the system it stops: an instruction sent to an agent is a request that the agent processes, whereas revoking its identity at the identity provider or denying its calls at the policy decision point is a control. Article 14(4)(e) of the AI Act asks that a high-risk system can be brought to a halt in a safe state (1, European Union, 2024), which, read architecturally, puts the halt outside what is halted. It has more than one mechanism, and the mechanisms share no dependency, because correlated controls fail together, as in July 2026 (168, Nordqvist, 2026): a stop that depends on the identity provider of the system it stops is one mechanism, however many buttons it has. It is held by named people around the clock with a decision right that needs no prior approval. And it is cheaper to exercise than the alternative, so the record says that a stop in good faith is never a failure.

For a deployer of a high-risk system the stop path is also a legal position. Article 26(5) of the AI Act requires a deployer that has reason to consider that use of the system may present a risk to inform the provider or distributor and the market surveillance authority without undue delay and to suspend the use of the system (1, European Union, 2024). The architectural implication is that the deployer can suspend use from its own side of the integration and does not depend on a supplier's availability to do it.

The stop path becomes a measured property when its four intervals are timed against a budget set from what the agent can do in that time. The principles of chaos engineering give the method: state a steady-state hypothesis, here that the system is contained within the budget, and test it with a limited blast radius (87, Principles of Chaos Engineering community, n.d.).

Practical guide: Timing a stop path end to end

Purpose. Show by measurement that the right to stop can be exercised within the time the threat allows, and turn each shortfall into a design change.

Roles. The security architect designs the drill and owns the timing record; the stop holders exercise the decision; the agent operator or system owner runs the mechanisms; the SOC supplies independent verification; internal audit may sample.

  1. List every mechanism by which the system can be stopped, where it runs and which identity, credential, network path or provider it depends on. Mark any mechanism that runs inside the system and any two that share a dependency.
  2. Name at least two stop holders for every hour of the week and write the decision right so that no approval is needed.
  3. Set the budget from blast radius. As defaults, adapted to risk appetite: five minutes from trigger to verified containment for a Mode 5 agent with write access to production, and fifteen minutes for other systems that can cause irreversible harm.
  4. Instrument the four intervals with system timestamps and not participants' recollections.
  5. Run the drill first in a safe environment, then in production with a limited blast radius and a safe-abort condition, and at least once a year unannounced and outside office hours.
  6. Pass only if verified containment is inside the budget. Record each shortfall as a finding, fix it by pull request and run the drill again.
  7. Repeat quarterly for agents with production write access, and after any change to the identity provider, gateway or network path they depend on.

Definition of done. Every mechanism is listed with its dependencies; stop holders cover every hour; the last drill is inside the budget or has an open finding with a date; the timing record is in the evidence store.

# Illustrative: Hansa Mutual, first timed stop drill of the IT-operations agent (AIDR-0027)
drill: STOP-HM-ITOPS-2027-Q1-01
system: it-operations-agent
mode: Mode 5
budget_minutes: 5
trigger: canary_touch_on_decoy_vault_path
intervals_minutes: {notice: 9, decide: 2, act: 5, verify: 1}
total_minutes: 17
result: failed
findings:
  - id: F-01
    cause: alert routed to soc-duty-analyst, who paged the agent operator on-call
    fix: route canary alerts for agent identities to operator on-call and stop holder together
  - id: F-02
    cause: credential revocation alone left 15-minute tokens valid
    fix: shorten task-scoped token lifetime to 5 minutes; the policy decision point deny rule is the first mechanism
  - id: F-03
    cause: soc-duty-analyst had no mandate to apply the deny rule
    fix: written mandate, recorded in role charter and playbook
redrill_due: 2027-Q2

Across the autonomy levels

The machine-speed properties differ with the autonomy level at which delegated actions run and with the mode of the AI involved. AI Red Team, Chapter 6, matches the level to reversibility and blast radius, and Level 4 is never used for irreversible actions (170, Nordqvist, 2026).

Action Level Why
Apply a fix under a delegated playbook, with tested rollback and a canary ring Level 3 Bounded where a policy decision point or pipeline check enforces the conditions Reversible, and the human decision is the playbook
Suspend a Mode 5 agent's write credentials after a canary touch Level 3 Bounded Reversible, small blast radius, restart needs the owner
Prepare compensating controls and propose an order of work Level 0 Advisory or Level 1 Assisted A person judges the prioritisation
Isolate a production system or a service with wide blast radius Level 2 Supervised A person approves each isolation, from a prepared runbook
Irreversible changes, security tooling changes, resuming a stopped agent Level 1 Assisted or Level 2 Supervised, never above Named people decide

Mode matters for the stop path. In Modes 1 to 3 the AI acts with a person's identity, and the stop is that person's own revocation. A Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider, so the stop path is timed against what it can do in minutes. Mode 0 is the blind spot: supplier AI inside security products and managed services may act at an effective autonomy nobody decided, so the contract states what the service may do.

Machine-speed properties in management reporting

The architect proposes five indicators for the management body. Patch velocity per class, as share within target and trend, with every miss and its reason. Decision latency, the median time between a trigger and an authorised action, which shows whether delegation works. Detection coverage, the share of threat-derived detection requirements satisfied by a tested detection, by ATT&CK or ATLAS technique. Canary freshness, the share of canaries touched by a scheduled test within the period. Time to stop, from the latest drill, for each agent with write access to production.

Each indicator is classified as Chapter 9 classifies controls. A time to stop measured in a drill within the last quarter is verified, one taken from a runbook is declared, and a drill that exceeded its budget is failed whatever the runbook says. The report is one page and shows the failed items first. NIS 2 Article 20 and DORA Article 5(2) put oversight of these risks with the management body (6, European Union, 2022) (9, European Union, 2022), and the ECB letter suggests that supervisors will ask how that oversight is exercised (21, ECB, 2026); it is expected that numbers of this kind will be requested.

The first open question can now be answered as the chapter's own conclusion. When adversaries and insiders are assumed to act at machine speed, a design carries four timed properties and not only a diagram of boundaries, a design review asks how long each interval takes and who may act, and architectural change ships through pipelines with decision rights written in advance, because a design that depends on a fortnightly forum for every change cannot keep pace with agents that act daily.

Nordvik Region and Hansa Mutual

Nordvik Region cannot build machine-speed properties itself, so its security architect specifies them. For suppliers, the architect writes patch service levels for known-exploited vulnerabilities into tender and renewal documents, starting with TriageSoft under tender NR-2026-117, with the compensating control the supplier applies when a fix is late. For detection, the architect replaces supplier-default rules with the annex above. For the benefits-triage system, of which the Region is deployer, the architect designs a stop that the Region and not TriageSoft can exercise: closing the integration route on the Region's own platform so that caseworkers work an unranked queue, with the incident commander and the use-case owner as stop holders. The first timed drill, out of hours, took 26 minutes against a budget of 15, because the MSSP held the runbook but not the credentials to the integration gateway. That finding goes into the next call-off.

Hansa Mutual builds much of what it runs, so its work is delegation and verification. The playbook recorded as AIDR-0554 replaces the change advisory board's role for known-exploited vulnerabilities, with a policy check that withdraws it where its conditions lapse. The architect designs canaries into the IT-operations agent's estate, namely decoy vault paths, a decoy tool in the registry and a decoy host record, in a registry that detection engineering runs and the agent cannot read. Patch velocity per class, decision latency and time to stop go to the executive board. The first timed drill of the IT-operations agent took 17 minutes against a budget of five, because the alert reached a duty analyst who did not hold the decision and because tokens outlived the revocation. Both organisations found their stop paths slower than the threat allows, which is the result a drill exists to produce. Nordvik changes a contract and a credential; Hansa changes an alert route, a token lifetime and a mandate.

Summary

This chapter treated time as a design property that the security architect owns. The exploitation window is documented as shrinking, agents can compress intrusions to minutes and AI raises the volume of discoveries and patches. The estate's response has four intervals, notice, decide, act and verify, and the architect designs each: telemetry, detections and canaries for notice, delegation for decide, patchable design and a service level for act, and a stop path outside what it stops. The shrinking window is observable and justifies commitment. A supervised patch-velocity metric is expected and justifies preparation. Exploitation in minutes as the normal case for exposed, widely deployed software is expected, not certain, and the broader claim that most significant intrusions and insider actions unfold in minutes remains speculation.

The chapter concerns Shift 3, from periodic to continuous, at machine speed. Patch velocity, detection coverage and time to stop are measured and reported continuously, and the drill is the only evidence that a time claim is true. It concerns Shift 2, from gatekeeper to boundary designer equally. The decisions taken in minutes are delegated in advance, with written conditions that the pipeline enforces and a management body that decides whether the delegation stands.

The book's conclusion on the open question is that assuming machine-speed adversaries and insiders changes how architecture is designed, reviewed and changed: each design carries four timed properties, each review asks for measured intervals and each change ships through a pipeline whose approvals were decided beforehand. Both organisations found their stop paths slower than the threat allows. A measured shortfall can be fixed, and an untested claim cannot.

Chapter 11 takes up what follows when prevention, detection and the stop have all been exercised and something has still failed. It treats recoverability as an architectural property, with redeployment from known-good definitions and the security chaos experiments that verify that recovery works.

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). (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). (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). (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). (12, European Union, 2024)
  5. European Commission (2026). Cyber Resilience Act: Reporting obligations. (13, European Commission, 2026)
  6. European Central Bank (2026). Addressing AI-enabled cybersecurity threats. (21, ECB, 2026)
  7. Souppaya, M. & Scarfone, K. (2022). Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. (35, Souppaya & Scarfone, 2022)
  8. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (46, MITRE, n.d.)
  9. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (47, MITRE, n.d.)
  10. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (48, MITRE, n.d.)
  11. Principles of Chaos Engineering community. Principles of Chaos Engineering. (87, Principles of Chaos Engineering community, n.d.)
  12. Satter, R., Seetharaman, D. & Cai, K. (2026). Exclusive: Its AI agent spent days hacking a company, but sources say OpenAI did not notice for a week. (132, Satter et al., 2026)
  13. National Cyber Security Centre (2025). Impact of AI on cyber threat from now to 2027. (139, NCSC, 2025)
  14. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. (140, NCSC, 2026)
  15. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. (142, Mandiant, 2026)
  16. Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (143, Charrier & Weiner, 2024)
  17. Grunewald, R., Mazumdar, S. & Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. (145, Grunewald et al., 2026)
  18. Blum, Mainor, Nambiar et al. (2026). ARTEX and Friends: Enter Agentic Offensive Frameworks. (146, Blum et al., 2026)
  19. Big Sleep team, Google Project Zero and Google DeepMind (2024). From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. (147, Google Project Zero, 2024)
  20. Defense Advanced Research Projects Agency (2025). AI Cyber Challenge marks pivotal inflection point for cyber defense. (148, DARPA, 2025)
  21. Carlini, N., Cheng, N., Lucas, K. et al. (2026). Assessing Claude Mythos Preview's cybersecurity capabilities. (149, Carlini et al., 2026)
  22. Anthropic (2026). Project Glasswing: Securing critical software for the AI era. (150, Anthropic, 2026)
  23. Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). (151, FIRST, n.d.)
  24. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. (152, CISA, n.d.)
  25. European Union Agency for Cybersecurity (2025). European Vulnerability Database (EUVD). (153, ENISA, 2025)
  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)
  31. Cybersecurity and Infrastructure Security Agency (2021). Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities. (193, CISA, 2021)