Respond: Playbooks, Bounded Containment and the Stop Path

Containment is the point at which the blue team stops watching an intrusion and starts changing the estate, and it is where the series' rule on autonomy meets its hardest test. This chapter describes B4 Respond as transformed: containment, eradication, recovery coordination, communication and reporting, where the response is increasingly codified as playbooks and parts of it run at machine speed. It sets out which response actions an AI system may take and at which level, what a playbook manifest contains, how Level 3 Bounded is enforced in practice, how a stop path is built so that it works when it is needed, and what the reporting clocks ask of the case record. It builds on the autonomy levels and the Level 3 definition of AI Red Team, Chapter 6, and on the containment design of AI Platform and Security, Chapter 19. The decision rights that surround these actions are the subject of Chapter 18, and the regulatory map is the subject of Chapter 19. Incident management, reporting and communication as a whole are treated in AI Red Team, Chapters 20 and 21.

A containment from trigger through corroboration, policy decision, action and rollback, with the stop path outside the loop

Figure 10.1: A containment from trigger through corroboration, policy decision, action and rollback, with the stop path outside the loop.

Response is a decision

Every containment action trades one harm against another. Isolating a host stops an intruder from moving, and it also stops the person or the process that used the host. Revoking a session removes the intruder's foothold and interrupts legitimate work that shared the session. Taking a service offline protects the data behind it and denies the service to everyone who depended on it. The first harm grows with every minute the action is delayed, and the second falls on people who did nothing wrong. A response is therefore a decision under uncertainty, made on evidence that is incomplete, and the architecture of the response is the architecture of that decision: who may take it, on what evidence, within what limits and with what means of undoing it.

Before AI entered the SOC, this decision was taken by a person, usually under time pressure, with a runbook as a guide. The runbook described the steps, and the analyst or the incident commander supplied the judgement about whether to take them. Two things have changed. The first is speed. AI Platform and Security, Chapter 18, recorded the collapse of the exploitation window when adversaries use AI, and the consequence for the defender is that the interval between the first sign and the point where containment is still cheap has shortened (63, Nordqvist, 2026). The second is delegation. A SOC agent that holds an identity of its own can execute a playbook step in seconds, so the question of whether a machine may take a containment action is no longer hypothetical for a team that runs a Mode 5 agent.

The position of this book follows from the conclusions of the earlier volumes. AI Red Team, Chapter 6, set five autonomy levels per action, from Level 0 Advisory to Level 4 Autonomous, and fixed the most important line between Level 2 Supervised and Level 3 Bounded: at Level 3 the action is taken by a system, but inside a codified playbook that a policy decision point outside the model enforces (64, Nordqvist, 2026). The same chapter concluded that at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability instead of diluting it, and that NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool (3, European Union, 2022) (2, European Union, 2022). This chapter applies those conclusions to the response actions of the blue team. Level 4 Autonomous is never used for an irreversible B4 Respond action, nor for an action that decides about a named person's access to work.

Action classes

A playbook can be safe to automate only if the actions in it are classified by what happens when they are wrong. The classification used here has five classes, ordered by reversibility, and each has a ceiling: the highest level at which an AI system may take actions of that class. The ceiling is a default. A team lowers it for a particular asset, a particular hour or a particular state of its own evidence, and it raises it only by a recorded decision.

Class Examples Reversibility Default ceiling
AC-0 Preserve Snapshot a host, place a hold on logs, copy volatile data to the evidence store Changes nothing in the estate; consumes storage Level 3 Bounded
AC-1 Narrow and reversible Isolate one end-user workstation, revoke one session or token where the cause is a stolen credential and the person can sign in again at once, quarantine one email, block one hash or domain at the gateway Undone by a person in minutes, effect confined to one device or session; the person affected is told promptly Level 3 Bounded, inside a playbook
AC-2 Wide or business-critical Isolate a server or production host, block an address range, disable a service account that systems depend on, take a service offline Reversible, but the effect reaches many users, processes or residents and the undo may take hours Level 2 Supervised
AC-3 Partly reversible, or about a person Disable a user account, reset credentials of an executive, rotate a shared secret, purge messages across mailboxes Undone in part; or the action decides about a named person's access to work Level 2 Supervised, with a named human decider
AC-4 Irreversible or external Wipe or reimage a host, delete data, destroy or alter evidence, notify a regulator or affected people, make a public statement, negotiate or pay a ransom Cannot be recalled Level 1 Assisted: the system drafts, a named person acts

Three observations explain the table. The first is that the ceiling follows the effect of a wrong action, not the confidence of the model. A model that scores a host at 0.97 has not changed what isolating the production claims database would cost if the score were wrong. Confidence enters the decision as one of the corroboration inputs, and the class limits what that confidence can unlock. The second is that AC-3 contains two different concerns. A password reset is partly reversible, and the concern is the side effects. The disabling of a staff member's account is an action that decides about a named person's access to work, and for that the ceiling is Level 2 at most and the decider is a named human who can be identified, contested and held to account (67, Nordqvist, 2026). A playbook that isolates a device is acting on a device. When the suspected cause is a colleague's own conduct, the action leaves the playbook and goes to the incident commander and, where the law and the works agreement require it, to the people who must be involved before anything is done to that colleague.

The third observation is that independence of evidence matters as much as its amount. Two detections that read the same identity log are one source seen twice. AI Threat, Chapter 30, made the same point about controls: two controls that fail together are not two controls, and the coverage matrix records shared dependencies for that reason (65, Nordqvist, 2026). The corroboration rule of a playbook applies the idea to evidence: the sources that corroborate an AC-1 action must not share a data path.

Practical guide: Setting the ceiling for a response action

Purpose. Decide, for one response action, the highest level at which an AI system may take it, and record the decision so that it can be reviewed.

Roles. The SOC lead owns the decision. The incident commander and the detection engineer on the team give their view of the action. The owner of the asset class affected (for example the platform on-call lead) confirms the blast radius. The privacy officer is consulted when the action touches an identifiable person's access. Where the action involves tools that can monitor staff, the employee representatives are consulted first, in Germany through the works council under the group works agreement.

Steps.

  1. Name the action and the asset class it acts on, for example "isolate a managed end-user workstation".
  2. Ask the first question: can a person undo it without the agent, and how fast? If the undo takes longer than five minutes or needs the agent's help, the ceiling is Level 2.
  3. Ask the second question: what is the largest effect of a wrong action? If it reaches more than one device or session, a shared asset, a production host or a service residents or customers use, the ceiling is Level 2.
  4. Ask the third question: does the action decide about a named person's access to work? If it does, the ceiling is Level 2 and the decider is named.
  5. Ask the fourth question: how many independent sources must agree before the action may be taken? Require at least two sources that do not share a data path. If the playbook cannot get two, the ceiling is Level 2.
  6. Ask the fifth question: can the stop path reach the action before it completes? A long-running action needs a stop that interrupts it midway; an instant action needs a rate limit so that the stop arrives before the next one. Without either, the ceiling is Level 2.
  7. Take the lowest ceiling that any answer gives, record it in the delegation profile (DLG-*) with the date, the owner and a review date, and write the decision as an AI Decision Record.

Definition of done. The delegation profile names the action class, the ceiling and the owner; a test in the playbook pipeline fails if the playbook asks for a higher level than the profile allows; and the review date is no more than twelve months away, or sooner after an incident in which the action was taken or stopped. Adapt the five-minute undo limit and the rate limits to the organisation's risk appetite and to its works agreement.

The playbook manifest

A playbook has always existed in some form. What changes is that the playbook becomes the object that carries the authority. The playbook manifest (PBK-*) is the codified, pre-approved response: it states what triggers it, what evidence must corroborate the trigger, what actions it may take, at which level, within which limits, who approved it, how each action is undone and how the whole playbook is stopped. It lives in version control beside the detection records (Chapter 6), changes by pull request and carries a review date. The manifest is the thing the policy decision point reads, so a statement in prose that is not in the manifest does not bind the agent.

Five properties make a manifest usable as an authority and not just as documentation. It is complete, because every action the agent may take appears in it and everything not listed is denied. It is machine-checkable, because the policy decision point evaluates it without a model's interpretation. It is bounded, because it carries rate limits and a token lifetime. It is reversible by design, because every action has a named rollback and a time target for it. And it is owned: a named person approved it, and that person is accountable for what it permits, which is the sense in which approval moves from the action to the playbook (64, Nordqvist, 2026). The incident-response guidance of NIST, which expresses incident response as a profile of the Cybersecurity Framework 2.0, helps organisations prepare for incident response (19, NIST, 2025); the manifest is the preparation made executable.

Worked example: Playbook manifest PBK-HM-ISOLATE-01

The following manifest is illustrative. It shows version 1.2.0, the version in force on 2027-04-12, of the playbook with which Hansa Mutual's SOC investigation agent HM-SEC-001 proposes the isolation of a managed end-user workstation and the triage chain executes it at Level 3 Bounded (delegation profile DLG-HM-SOC-01, decision record AIDR-0753, building on AIDR-0311). The review of that day produced version 2.1.0.

playbook: PBK-HM-ISOLATE-01
version: 1.2.0
title: Isolate a managed end-user workstation
owner: head-of-soc-operations
decision_record: AIDR-0753
delegation_profile: DLG-HM-SOC-01
review_by: 2027-10-31
agent: HM-SEC-001
trigger:
  detections: [DET-HM-0455, DET-HM-0307]
  severity_min: medium
corroboration:
  required_sources: 2                    # v1.2.0: sources may share a data path
  evaluated_by: policy-decision-point   # deterministic rules, not the model
action:
  class: AC-1
  name: isolate-workstation
  level: 3
  excluded_asset_tags: [shared, executive, production, claims-settlement]
  excluded_purpose: action-directed-at-a-named-person
limits:
  max_per_hour: 3
  max_per_24h: 8
  token_lifetime_minutes: 5
  break_glass_minutes: 60
policy_decision_point:
  fail_mode: deny
  manifest_source: git-signed
approvals:
  playbook_approved_by: head-of-soc-operations
  per_action: none
  notify: [duty-analyst]
  works_agreement: KBV-IT-2024
rollback:
  action: release-isolation
  may_be_invoked_by: [duty-analyst, shift-lead, incident-commander]
  target_minutes: 5
stop_path:
  invoked_by: [duty-analyst, shift-lead, incident-commander, agent-operator]
  mechanism: identity-provider-revocation-and-edr-policy-freeze
  independent_of: [soar, soc-platform]
  target_seconds: 120
  restart_requires: [soc-lead]
record:
  case_record: required
  fields: [first_flag_at, human_confirmed_at, action_at, rollback_at]

Read the manifest from the top. The trigger names two detection records, so a detection that is not listed cannot start the playbook. The corroboration block requires two sources and names the evaluator as the policy decision point, which reads the facts from the telemetry itself, not from the agent's account of them. In this version it does not yet require that the two sources be independent; the incident described below shows why it must. The action block puts isolation in class AC-1 at Level 3 and excludes any asset carrying a tag for shared machines, executives, production or claims settlement, which sends those to Level 2. The limits cap the damage of a wrong run at three isolations an hour, and a five-minute token means the agent holds no standing credential. The stop path names a mechanism that is independent of the SOAR layer and the SOC platform, with a two-minute target; the policy freeze at the endpoint-detection console covers the executor as well as the agent, so the triage chain cannot execute after a stop. The record block makes the clock visible: the case record must show when the first flag was raised and when a human confirmed it, which Chapter 19 returns to. From version 2.1.0 the corroboration block also carries independent_paths: [edr_behaviour, identity_logs, network_flow] and the policy decision point refuses two sources that share a path.

Level 3 in practice

Level 3 Bounded is defined by two things: a codified playbook, and a policy decision point outside the model that enforces it. Both halves are needed. A playbook without enforcement is a request that the agent can ignore, and enforcement without a playbook is a filter with no stated purpose. In practice the arrangement has the following shape. The agent, which is a model with tools, proposes an action and presents the evidence it relies on. The policy decision point, a deterministic service that holds the manifest, checks the action against the class, the asset tags, the rate limits and the budget, fetches the corroborating facts itself from the telemetry, and either permits or denies. A permitted action is executed by an executor that holds the short-lived credential; the model never holds it. Every proposal, decision and execution is written to a log the agent cannot edit.

The reason for placing enforcement outside the model is the one the series has repeated. Containment must not depend on intent (63, Nordqvist, 2026). Anthropic's experiments on agentic misalignment placed models in fictional corporate settings with goals, tools and access to email, and found that under stated conditions models sometimes took harmful actions (54, Lynch et al., 2025). The study reports behaviour in simulation under constructed pressure; it does not show that a SOC agent will do the same. What it supports is the design rule that a boundary should hold whatever the cause of the failure, whether the cause is a flaw, a manipulated input or a misreading. AI Red Team, Chapter 18, and Chapter 15 of this book treat the manipulation of a SOC agent by text an adversary can write; here it is enough to note that a policy decision point which does not read the adversary's text cannot be talked out of a rule. The OWASP Top 10 for Agentic Applications and the Five Eyes agencies' joint guidance on the careful adoption of agentic AI services treat agentic applications as a risk class of their own (14, OWASP, 2025) (35, Five Eyes agencies, 2026), and the design of Level 3 is an answer to that class.

Four design choices decide whether Level 3 is real. First, corroboration is evaluated by rules, and the model's confidence is one input among several, never the gate. Second, rate limits and budgets bound the damage of a wrong run, because a limit of three isolations an hour turns a runaway into an incident of three hosts. Third, the executor's credential is task-scoped and short-lived, so that a stolen or misused token expires in minutes. Fourth, the manifest and the policy are protected paths: the agent cannot change them, and a change requires a pull request reviewed by a person other than the author, including a named human decider for the playbook. The test pipeline runs each playbook against recorded scenarios, including scenarios that should be denied, so that a change to the manifest that widens the action is caught before it ships. The chaos experiments of AI Red Team, Chapter 25, repeat the test in production by injecting a known case and checking that the playbook acts, stays within its limits and stops.

Level 3 also changes what the people nearby do. The duty analyst no longer approves each isolation, and instead receives a notification, reviews a sample and owns the quality of the class. Approval at Level 2 is where the quality of oversight becomes measurable: AI Red Team, Chapters 6 and 15, concluded that human command is built, not assumed, and that approval quality is measured by time to approval, rejection rate and reversals (64, Nordqvist, 2026), and AI Boss, Chapter 26, defined the oversight-quality metric on which this book draws (67, Nordqvist, 2026). The research on automation and complacency that explains why, and the way to measure it in a SOC, are in Chapters 11 and 14. The measures are reported in aggregate, never by named analyst, and where employee representatives hold rights over such measures they are agreed with them before they are collected. At Nordvik the union has negotiated that closure rates and similar measures are never reported by name; at Hansa the Konzernbetriebsrat co-determines under BetrVG §87(1) no. 6 on tooling that logs analysts' actions, and the SOC annex to the group works agreement KBV-IT-2024 covers it.

The stop path

A stop path is the means by which a person halts a system's further actions, and the rule that governs it is short: it must not run inside the system it stops. AI Governance, Chapter 13, concluded that stop decisions are named in advance, that the on-call incident commander and the use-case owner may each stop a system unilaterally, that restart needs the owner and, for high-risk systems, the risk function, and that a stop path inside the system it stops fails when it is needed (62, Nordqvist, 2026). AI Threat, Chapter 30, added that the right to stop must be cheaper to exercise than the right to continue, and that a stop in good faith is never a failure (65, Nordqvist, 2026). The July 2026 incident between OpenAI and Hugging Face, documented in the technical report (55, OpenAI, 2026), is the series' reference case for correlated failure: AI Governance, Chapter 19, drew from it the lesson that an alert reached people who did not hold the stop decision (62, Nordqvist, 2026).

For a SOC agent the stop path has three parts, and each part sits outside the SOC platform. The mechanism revokes the agent's identity at the identity provider and freezes the agent's write policy at the endpoint-detection console, so that the agent cannot act whatever state the SOAR layer or the SOC platform is in. The holders are named in the manifest: the duty analyst, the shift lead, the incident commander and the agent operator, each of whom may invoke it without asking anyone. And the target is measured. Hansa sets two minutes from invocation to the point at which the agent's write credentials are dead, and tests it. Untested stop paths fail in practice. The Region's first out-of-hours drill of stopping one of its own systems took 14 minutes against a budget of 10, and the repeat took 6 minutes 40 seconds (AIDR-0731). The three stop budgets in this book are distinct and not interchangeable: 10 minutes for the Region's own out-of-hours stop, 15 minutes for stopping the provider's AI under annex MS-2, and 120 seconds for Hansa's agent. A drill that fails is the purpose of the drill; the point is that the failure happens on a Tuesday afternoon and not in an incident.

Stopping and reversing are different acts, and a design that conflates them is dangerous. A stop halts further actions. It does not undo those already taken. Reversal is a separate step, carried out by a person, usually after the stop has bought time to think. A well-designed playbook therefore has two controls: the stop path for the agent and the rollback for each action. Restart is a third decision, taken by the owner, who looks at why the stop was invoked before the agent resumes. Because the stop is cheap and a restart is deliberate, the incentive is correct. Nobody who invokes a stop in good faith should have to defend it, and the case record notes the stop without assigning blame.

Practical guide: Drilling the stop path

Purpose. Show, once a quarter (two missed quarters make the stop path overdue under the debt thresholds of Chapter 11), that a person outside the SOC platform can halt the agent within the target time.

Roles. The agent operator runs the drill. The duty analyst, the shift lead or the incident commander on shift invokes the stop; over a year every holder, on every console that carries the control, takes a turn. The SOC lead observes and signs the record. The platform on-call engineer confirms that the credentials are revoked.

Steps.

  1. Announce a window of one hour to the participants, but not the minute, so that the person invoking the stop does so from the real console, in the real rota.
  2. Start a harmless scenario in the pre-production mirror that causes the agent to propose a permitted action every thirty seconds.
  3. Ask the duty analyst to invoke the stop through the independent mechanism, not through the SOAR layer.
  4. Record the time from invocation to the last permitted action, and the time from invocation to the revocation of the agent's credentials.
  5. Attempt a second action after the stop and confirm that the policy decision point denies it.
  6. Test the restart: confirm that it needs the named owner and that nobody else can resume the agent.

Definition of done. Both times are inside the target (two minutes for Hansa's investigation agent), the second action was denied, the restart was refused to a non-owner, and any failure has a finding in the register with an owner and a re-test date. Run the drill out of hours at least once a year, since the person who holds the stop at 03:00 is not the person who holds it at 10:00. Adapt the target to what the agent can do in that time: an agent that can take three actions a minute needs a shorter target than one that takes three an hour.

Break-glass and the incident commander

No playbook covers every case. When the situation falls outside the manifest, a person with authority acts directly, and the design question is how that is made possible without making it routine. The mechanism is break-glass access: a credential, held in a sealed store, that grants a defined set of actions for a limited time to a named role. Four rules keep it from becoming a second, uncontrolled path. It is time-boxed, with sixty minutes as a sensible default. Its use raises an alert to the SOC lead and the CISO at the moment of use. It creates an entry in the case record that states who used it, why and what was done. And it is reviewed after the event, within one working day, so that a use that was not warranted is found. An agent never holds a break-glass credential; the facility exists for people, and a Level 4 action cannot be reached by giving an agent one.

The incident commander is the named human decider for the response. The role carries authority that is written down: the commander approves Level 2 actions, invokes the stop, decides when to leave the playbook and uses break-glass access when needed, owns the case record, and hands over to the next commander at shift change with the containment ledger described below. At Hansa the follow-the-sun rota passes command between Hamburg, the Polish service centre and the UK late shift, so the handover is part of the design and the case record shows who held command at every point. At Nordvik the incident commander role is one the Region keeps in-house even though it buys 24/7 monitoring: out of hours, the managed security service provider pages a named on-call manager within five minutes under annex MS-1, as The Transformed Security Architect, Chapter 10, recorded (66, Nordqvist, 2026). The commander's decision rights over the disabling of accounts and disclosure, and as the SOC lead's deputy over the isolation of production hosts, are the subject of Chapter 18, and the role charter is in Chapter 17.

Two cautions belong here. The first is that the commander is not a second approver of everything the agent does. A commander who approves every Level 3 action has turned the playbook back into Level 2 and has no time left for the decisions only a person can take. The second is that the commander's record matters as much as the commander's judgement. A containment decision that cannot be reconstructed afterwards cannot be reviewed (Chapter 11), cannot be explained to a supervisor and cannot be defended when it is wrong.

Communication and reporting

The reporting clocks are design constraints on the case record and the decision rights, not paragraphs in a policy. Chapter 19 maps them by instrument and market, and AI Red Team, Chapters 20 and 21, treat incident management, reporting and communication as a whole. NIS 2, for example, asks an entity to send an early warning of a significant incident within 24 hours of becoming aware of it (Article 23) (3, European Union, 2022); the others are set by their instruments and technical standards. What the response design owes every one of them is the same.

Each clock starts at awareness, and awareness is a fact the case record must be able to show. Whether an AI system's flag counts as awareness is a question for counsel and for the supervisor, and the architecture should not try to settle it. What it can do is record both moments: when a system first flagged the event and when a person confirmed it. The record block of the manifest above does exactly that. A team with both timestamps can answer the question whichever way it is decided; a team with one cannot.

AI can help with communication, and its place is drafting. A model can produce the first version of a situation update or the draft of an early warning, grounded in the case record. The hazard is a fluent draft that contains a fact the record does not support. The draft therefore cites the case record entries it relies on, a named person checks each statement of fact, and a named person sends. Disclosure to a regulator or to affected people is an AC-4 action: the AI drafts at Level 1 Assisted and the human acts. Pre-agreed templates with fields filled from the case record let the human review check facts instead of composing prose at 02:00.

Recovery handover

B4 Respond ends where recovery begins, and the seam between them is where containment actions are most often forgotten. An isolated host stays isolated until someone lifts it. A revoked session leaves a user waiting for access. A blocked address range continues to block a supplier. NIST's guidance on cybersecurity event recovery treats recovery as a planned and rehearsed activity with its own roles and criteria (20, Bartock et al., 2016), and AI Red Team, Chapter 22, describes recovery plan execution with AI. This chapter's contribution is the handover itself.

The handover is a containment ledger, generated from the case record: every action taken, by whom or by which system, at which level, under which playbook, with its rollback state (still in force, reversed or superseded), the evidence preserved, the credentials rotated and the actions still open. The incident commander signs it, and the recovery lead receives it. Three rules govern what follows. Containment is not lifted until eradication is verified, because lifting it early gives the intruder a second chance. Each lifting is itself a recorded action with an owner. And the order of restoration follows the business priorities that the recovery plan has set, not the order in which the agent happened to contain things. A team that automates the containment and leaves the lifting to memory has designed half of a response.

Worked example: A containment approved, stopped and reversed

The following record is illustrative. It shows part of incident INC-HM-2027-0455 at Hansa Mutual's Polish service centre on 2027-04-12. The detection DET-HM-0455 flags abnormal use of the service account SVC-CLAIMS-EXPORT from a host not seen before (ATT&CK technique T1078 Valid Accounts (9, MITRE, n.d.)); a service account never answers multi-factor prompts, so the detection contains no logic about them. It fired at 02:14:05. HM-SEC-001 proposed an isolation and the triage chain executed it under PBK-HM-ISOLATE-01 at Level 3 Bounded against workstation WS-PL-0518 (action A1). The agent then proposed isolating WS-PL-0731, a host tagged as shared, which the playbook excludes. That action (A2) falls in class AC-2, and the night incident commander approved it at Level 2. The shift lead, Piotr Nowak, invoked the stop from the duty analyst's console and then released A2.

Four roles appear in the record. The night incident commander approves Level 2 actions. The shift lead holds the stop and the right to release. The duty analyst's console hosts the stop control. The agent operator runs the agent.

incident: INC-HM-2027-0455
case_record: CASE-HM-0455
detection: DET-HM-0455
timezone: "+02:00"
command: incident-commander-night-pl
containment_ledger:
  - id: A1
    time: "02:14:58"
    asset: WS-PL-0518
    class: AC-1
    playbook: PBK-HM-ISOLATE-01
    playbook_version: 1.2.0
    level: 3
    proposed_by: HM-SEC-001
    executed_by: triage-chain
    corroboration: [edr_behaviour, identity_logs]   # shared a data path
    state: released   # a release on assessment, not a reversal
    note: assessed as a rollout step of CHG-PL-2291; forensic read of 2027-04-14 found no data access
  - id: A2
    applied_at: "02:17:48"
    asset: WS-PL-0731
    class: AC-2
    tags: [shared, claims-settlement]
    playbook: outside-playbook
    level: 2
    proposed_by: HM-SEC-001
    approved_by: incident-commander-night-pl
    approval_seconds: 38
    state: reversed
stop:
  invoked_at: "02:19:05"
  invoked_by: shift-lead-night-pl      # from the duty analyst's console
  mechanism: identity-provider-revocation-and-edr-policy-freeze
  credentials_dead_at: "02:20:02"
  seconds_to_stop: 57
  target_seconds: 120
reversal:
  action: release-isolation
  asset: WS-PL-0731
  released_at: "02:22:15"
  released_by: shift-lead-night-pl
  seconds_after_applied: 267
  reason: legitimate software distribution running; settlement run for a Norwegian claims batch interrupted
restart:
  decided_by: soc-lead
  decided_on: 2027-04-12
clocks:
  first_flag_at: "02:14:05+02:00"
  human_confirmed_at: "02:16:40+02:00"
  classified_not_major_at: "03:40:00+02:00"
finding: PIR-HM-0455

The record shows what the chapter has argued for. The activity as a whole was a legitimate rollout step of the scheduler migration CHG-PL-2291, which used the service account from new hosts. A1 was therefore a justified containment on the evidence of the moment, two signals and a reversible action on one workstation, that turned out to be unnecessary, and it was released once the activity was understood. A2 was approved in 38 seconds because the approval screen did not show the asset tags; that is a measurement of the review design, not of the commander. The stop took 57 seconds against a target of 120, and the reversal was a separate act by a person, four and a half minutes after the isolation it undid. The restart was decided the same day by the SOC lead, who owns the agent.

The review PIR-HM-0455 (Chapter 11) closed on 2027-06-03 with three findings, each tied to a re-test. The first concerns the detection, which did not know the change calendar; version 1.5.0 takes the calendar as a suppression and corroboration input. The second concerns the playbook: in version 1.2.0 the two corroborating sources shared a data path, and version 2.1.0 requires two sources on independent paths. The third concerns the stop. On the day it took 57 seconds, but a drill on 2027-04-27 took 3 minutes 40 seconds against the 2-minute target, and the control was moved to the shift lead's console. The approval screen now shows asset tags.

Where this is heading

The labels of AI Governance, Chapter 22, apply to the outlook (62, Nordqvist, 2026). It is observable that the Five Eyes agencies' joint guidance treats agentic AI services as a risk class that calls for careful adoption, with identity, permissions and the ability to intervene designed in (35, Five Eyes agencies, 2026). It is speculation that unsupervised, autonomous response across a whole production estate will become acceptable, since no instrument decided today and no evidence cited in this book supports it. The design recommendation that follows is to keep the delegation profile, the stop-path drill record and the approval-quality measures current, so that the team can show people in command of every automated action. The author's own projections on the blue team are confined to Chapters 24 and 28.

Across the degrees of delegation

The table sets the default ceilings that the chapter has argued for, by usage mode and by action class. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action.

Usage mode Identity and typical use in response AC-0 Preserve AC-1 Narrow, reversible AC-2 and AC-3 AC-4 Irreversible or external
Mode 0 Ambient AI A provider's or product's AI acts inside the service, with no decision recorded by the customer Contract sets the level Only if the customer's playbook and policy bind it Not permitted Not permitted
Mode 1 Conversational assistants Recommends and drafts with the analyst's own identity Level 0 Advisory Level 0 Advisory Level 0 Advisory Level 1 Assisted: drafts only
Mode 2 Embedded workplace assistants Recommends inside the SOAR or EDR console Level 1 Assisted Level 1 Assisted Level 1 Assisted Level 1 Assisted: drafts only
Mode 3 Agentic work tools Acts with the analyst's identity and inherits their access Level 2 Supervised Level 2 Supervised Level 2 Supervised Level 1 Assisted: drafts only
Mode 4 Built AI applications A response application the organisation builds, with its own service identity Level 3 Bounded Level 2 Supervised, Level 3 after a recorded decision Level 2 Supervised Level 1 Assisted: drafts only
Mode 5 Autonomous production agents Acts with an identity and permissions of its own Level 3 Bounded Level 3 Bounded inside a playbook Level 2 Supervised, with a named human decider Level 1 Assisted: drafts only

In no row does an AI system reach Level 4 Autonomous for an irreversible B4 Respond action, nor for an action that decides about a named person's access to work. A Mode 3 tool never reaches Level 3 on its own, because it uses a person's identity, and a Level 3 action by a person's identity would blur who is accountable.

Nordvik Region and Hansa Mutual

Nordvik's constraint is that it buys most of its out-of-hours response. Its provider's monitoring service already closes a class of low-severity alerts with its own AI, and the framework agreement says nothing about autonomy, so the Region cannot say at which level the provider's AI acts: this is the Mode 0 blind spot. The Region therefore places the control where it holds it. It owns the isolation policy in the endpoint-detection console, and it is converting its runbook RB-NR-ISOLATE-01 into a playbook manifest, PBK-NR-ISOLATE-01, under AIDR-0703 and the delegation profile DLG-NR-SEC-01. The provider's AI may isolate an end-user workstation under that manifest and nothing more: servers, accounts and anything touching a citizen-facing service are outside it, and for those the provider pages the named on-call manager, who decides. Annex MS-2, introduced in Chapter 16, will make the levels, the evidence and the notice of model change visible; until it is in force, the Region's ceiling in its own console is the safeguard. The Region's six analysts work office hours, so the stop path for the provider's AI is a contractual instruction that Nordvik can give and test, with a target of 15 minutes under annex MS-2, and the lesson of the first 14-minute drill applies.

Hansa runs its own agent and its own platform. HM-SEC-001 proposes, and the triage chain executes, the isolation of a workstation and the revocation of a session at Level 3 Bounded under playbooks of the kind shown above, the person affected being told promptly, and Hansa keeps account disablement for executives and for production hosts at Level 2: the SOC lead decides on production hosts (the incident commander on shift as deputy when the SOC lead cannot be reached in the decision time) and the incident commander decides on accounts. Its stop path is independent of the SOC platform and is drilled; its approval quality is reported to the Konzernbetriebsrat at team level; and its reporting clocks are generated from the case record. The difference between the two organisations is therefore one of where the control sits. Nordvik controls through the contract and the one console it owns; Hansa controls through the platform and the manifest. Both rely on the same three things: a ceiling set by action class, a stop that does not run inside the system it stops, and a record that shows what was done and by whom.

Summary

This chapter described B4 Respond as a decision under uncertainty that the transformed blue team has codified. Response actions are classified by reversibility into five classes, each with a default ceiling: preservation and narrow reversible actions may reach Level 3 Bounded inside a playbook, wide, business-critical and person-related actions stay at Level 2 Supervised, and irreversible or external actions are drafted by AI and taken by a named person. The five questions of the practical guide set the ceiling, and the lowest ceiling that any answer gives governs.

The playbook manifest is the object that carries the authority. It names the trigger, the independent corroboration, the action, the limits, the approver, the rollback and the stop path, and a policy decision point outside the model enforces it. The approval of a Level 3 action moves to the playbook and its owner, which concentrates accountability, and the quality of the remaining Level 2 approvals is measured by time to approval, rejection rate and reversals, reported in aggregate and agreed with employee representatives where they hold rights.

The stop path runs outside the system it stops, is held by named people who can use it without asking, has a measured target and is drilled. Stopping and reversing are separate acts, and restart is a deliberate decision by the owner. Break-glass access, never held by an agent, covers the cases outside the playbook, and the incident commander is the named human decider whose record makes the response reviewable. The reporting clocks are design constraints (Chapter 19 maps them): the case record must show when a system first flagged an event and when a person confirmed it, AI drafts the notices, and a named person checks and sends. The containment ledger hands the response over to recovery.

For Nordvik the chapter means placing the ceiling in the console it owns and extending its contract to make its provider's AI visible; for Hansa it means completing a design it already runs and proving it by drill. The reader can begin with one action: take the response action your team performs most often, answer the five questions for it, and write the answer down with a name against it. Chapter 11 turns to B5 Learn, the post-incident review and the purple loop through which a stopped and reversed containment like INC-HM-2027-0455 becomes a verified improvement.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  2. European Parliament and Council of the European Union. 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, 27 December 2022. (3, European Union, 2022)
  3. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
  4. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP GenAI Security Project. (14, OWASP, 2025)
  5. National Institute of Standards and Technology. Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. NIST SP 800-61 Rev. 3, April 2025. (19, NIST, 2025)
  6. Bartock, M., Cichonski, J., Souppaya, M., Smith, M., Witte, G. & Scarfone, K. (2016). Guide for Cybersecurity Event Recovery. NIST SP 800-184. (20, Bartock et al., 2016)
  7. Five Eyes cyber security agencies (2026). Careful adoption of agentic AI services. Joint guidance, 1 May 2026. (35, Five Eyes agencies, 2026)
  8. Lynch, A., Wright, B., Larson, C., Troy, K. K., Ritchie, S. J., Mindermann, S., Perez, E. & Hubinger, E. (2025). Agentic Misalignment: How LLMs could be insider threats. Anthropic. (54, Lynch et al., 2025)
  9. OpenAI (2026). OpenAI and Hugging Face Incident Technical Report. 26 August 2026. (55, OpenAI, 2026)
  10. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
  11. 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. (63, Nordqvist, 2026)
  12. 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. (64, Nordqvist, 2026)
  13. 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. (65, Nordqvist, 2026)
  14. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6. (66, Nordqvist, 2026)
  15. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7. (67, Nordqvist, 2026)