Technology Infrastructure Resilience Against Machine-Speed Attacks

An automated intrusion does not pause between steps; once it has a foothold, it moves at a rate set by the network rather than by an operator's working day, so a defence that relies on a person noticing the first step has already lost. The infrastructure itself therefore has to do part of the defending: it has to limit how far a compromised component can reach, how long it survives, and how much of the defence fails when one part of it, including the security AI, fails. This chapter describes how to build that resilience, how to make security AI degrade safely, and how to test that both work.

In CSF terms the chapter is responsible for PR.IR Technology Infrastructure Resilience, the Protect Category whose outcome is that security architectures are managed with the organisation's risk strategy to protect asset confidentiality, integrity and availability, and organisational resilience (19, NIST, 2024). Its four Subcategories frame the chapter: networks and environments are protected from unauthorised logical access and usage (PR.IR-01); technology assets are protected from environmental threats (PR.IR-02); mechanisms achieve resilience requirements in normal and adverse situations (PR.IR-03); and adequate resource capacity is maintained (PR.IR-04). The chapter reads them through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025) and maps them to the business-continuity, backup, disaster-recovery and crisis-management measures in NIS 2 Article 21(2)(c) (3, European Union, 2022) and, for financial entities, to the ICT risk-management framework and digital operational resilience testing required by DORA (2, European Union, 2022).

The chapter builds on three conclusions from the earlier volumes. Architecture as Code (Chapter 9B) concluded that manual incident response cannot scale when attacks develop within minutes, and that compromised components are redeployed from known-good definitions rather than repaired; the same volume (Chapter 9) named zero trust as one of the four dimensions of security (71, Nordqvist, 2025). AI Platform and Security, Chapter 19, concluded that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, and a stop path outside the system it stops (73, Nordqvist, 2026).

Four resilience layers and the three degradation modes of security AI

Figure 17.1: Four resilience layers and the three degradation modes of security AI.

Segmentation and zero trust

Why speed changes the design

The time between an attacker's first foothold and a meaningful compromise has been shrinking for years. Mandiant's analysis of time-to-exploit found that the average time taken to exploit a vulnerability, before or after a patch is released, fell from 63 days in 2018 and 2019 to five days in 2023 (44, Charrier & Weiner, 2024), and Chapter 2 describes AI-enabled operations that threaten to shorten it further. Lateral movement, the ATT&CK tactic in which an adversary moves from one system to the next (10, MITRE, n.d.), is where that compression does most damage: a human operator takes hours or days, while an automated operation moves as fast as the targets respond.

No SOC can guarantee a response faster than an attacker's next step, so the infrastructure has to limit the reach of each step, so that the attacker needs many steps to reach anything that matters and each step crosses a boundary where it can be refused, logged and detected. Bounded reach is the first line; speed of response is the second.

Zero trust as the architectural baseline

NIST's zero trust architecture turns this idea into design: no implicit trust is granted on the basis of network location; access to each resource is granted per session; access is decided by dynamic policy that considers identity, asset state and other attributes; and every request passes a policy enforcement point that consults a policy decision point (23, Rose et al., 2020). For a machine-speed attacker the consequence is direct. A compromised host inherits no trust from its subnet, a stolen credential works only for its scoped resources and session, and each new resource is a fresh decision at a point the attacker does not control. Chapter 14 treats the identity side of zero trust; this chapter treats the infrastructure side, where PR.IR-01 sits: segments, enforcement points and egress controls.

Properties that limit machine-speed attacks

Property	What it limits	Why it matters at machine speed
Segmentation by function and sensitivity	How far one compromised workload can reach	Each boundary crossing is a refusal, a log entry and a detection opportunity
Default-deny east-west traffic	Undeclared paths between workloads	Automated discovery finds every open path
Default-deny egress	Exfiltration and command-and-control	An agent or implant that cannot reach the internet cannot be steered from it
Per-session, task-scoped credentials	Reuse of stolen credentials	The attacker gets minutes, not months
Separate administration paths	Escalation to the control plane	The control plane is the fastest route to everything
Immutable, redeployable workloads	Persistence	Replacement from a known-good definition removes the foothold
Rate and budget limits	Volume of automated actions	Machine speed is visible as volume

Agents are workloads in a segment

Containment for the organisation's own agents must hold whatever the agent intends and must not depend on the agent reporting its own behaviour (AI Platform and Security, Chapter 19) (73, Nordqvist, 2026). Segmentation is where much of that containment lives. An agent with its own workload identity, such as Hansa Mutual's SOC investigation agent HM-SEC-001, sits in a segment whose permitted flows are exactly the tools in its permission manifest, with default-deny egress and with its policy files and manifest held where it cannot write. The same segment that contains a well-meaning agent exceeding its mandate also limits an attacker who takes it over.

Segmentation must, however, be checked from the attacker's side rather than from the diagram. AI Governance, Chapter 19, concluded that the July 2026 incident failed through correlated controls, among them a package mirror that was also an egress path (72, Nordqvist, 2026); OpenAI's report on the incident describes zero-day exploits in the package mirror as the agents' principal egress path to the public internet (64, OpenAI, 2026). A segment is only as tight as the least obvious service that crosses it, such as a proxy, a shared file store or a management interface on the wrong network, and automated attackers find such paths because they try everything reachable. Defenders should therefore enumerate reachable paths from inside each segment, not only the intended rules.

AI in segmentation design

Flow logs from a large estate are too voluminous for people to read, and intended rules diverge from actual traffic. An assistant can read flow logs and the configuration management database, group workloads by observed behaviour, propose segments with minimal flows and flag rules nobody has used for months. It works at Level 1 Assisted, drafting the change as a pull request that a network engineer reviews, in line with the Policy as Code practice of Architecture as Code (Chapter 10) (71, Nordqvist, 2025). It does not apply rules itself, because a wrong segmentation change can take down a critical service as surely as an attack.

Redeploy, do not repair

Known-good definitions as a control

Architecture as Code (Chapter 9B) concluded that compromised components are redeployed from known-good definitions rather than repaired in place (71, Nordqvist, 2025). Repairing a touched component means trusting the analyst's judgement that every change has been found; replacing it from a signed definition built by a pipeline means trusting the definition, a far smaller and more verifiable claim. At machine speed the argument is stronger, because an automated attacker may establish persistence in more places than an investigator can enumerate.

Redeployment is also a resilience control. If workloads are rebuilt regularly, persistence lasts only until the next rebuild; if the definition is the only route to production, attacker drift is visible as a difference; and a compromised segment can be replaced rather than cleaned host by host. This is PR.IR-03 in practice. Recovery from an incident, including restore order and verification, is treated in Chapter 22.

What a known-good definition contains for an AI system

For an AI system the behaviour depends on artefacts that are not code, so the definition from which security AI can be redeployed and trusted includes:

the model identifier and version, with the weights' hash for self-hosted models or the pinned version for a hosted model;
the system prompt, prompt templates and skills, as versioned files;
the guardrail configuration and the gateway policy;
the permission manifest, tool definitions and workload-identity scopes;
the retrieval sources and index version;
the evaluation suite and thresholds the system must pass before returning to its normal autonomy level.

The last item matters most. A system redeployed from correct definitions can still behave differently if a hosted model has changed underneath it or an index has been rebuilt from poisoned content. The redeployed system therefore starts at a reduced autonomy level and returns to normal only after its evaluation suite passes. Chapter 23 treats the restoration of AI systems in more detail.

Capacity and the environment

PR.IR-04 asks that adequate capacity is maintained, and PR.IR-02 that technology assets are protected from environmental threats (19, NIST, 2024). Security AI consumes accelerators, gateway throughput and budget, and OWASP names unbounded consumption as a risk in its own right (14, OWASP, 2025). An attacker who can generate alerts can load the services that read them just as the real intrusion begins, so capacity planning must assume that peak load coincides with an attack. AI can forecast that headroom from historical alert volumes and propose rate limits and queue priorities that keep high-severity alerts flowing, but how much headroom to buy and which alerts to shed are risk decisions for people.

Environmental threats, such as the loss of a data centre, a power supply or a network link, call for the familiar placement across sites, failover and achievable recovery objectives. The AI-specific point is dependency: security AI on the same accelerators, gateway and identity provider as production AI fails together with it, and where that coupling cannot be avoided, the degradation modes must assume it.

Resilience of security AI

How security AI fails

Security AI fails in four ways, each calling for a different response.

Unavailable. The endpoint, gateway, accelerators or hosting provider is down, and the AI produces nothing.
Degraded. The AI works slowly, on a fallback model or with part of its tooling missing, so its output is less reliable than its evaluation assumed.
Untrusted. There is reason to doubt the output: an evaluation regression, an unannounced supplier model change, a rise in signs of injected content, or an analyst rejection rate far above baseline.
Compromised or out of mandate. The agent acts outside its permission manifest or is suspected of being steered by an attacker. This is a security incident under Chapter 20, and the stop path is used.

The second and third are dangerous because they are quiet: a degraded or untrusted system keeps producing plausible output, and analysts used to relying on it may not notice. Since much of what security AI reads is attacker-controlled, the untrusted state is the one an attacker will try to induce.

The principle: lose speed, never lose the defence

The book's own conclusion sets the design principle: when security AI fails, the defence must lose speed, never the defence itself. Three rules follow.

Fall back to people and deterministic playbooks. Every capability needs a staffed, documented and practised fallback that works without the AI: a person doing triage, a SOAR playbook running deterministic steps, a detection rule alerting without enrichment.

Reduce autonomy in steps. A capability at Level 3 Bounded first suspends its bounded actions and returns to proposals a person approves, then to advice, and only then to manual operation, each step removing the contribution that depends most on trusting the output. The autonomy levels of Chapter 6 name the steps.

Trigger degradation from outside the AI. The signals come from components that do not depend on the AI: the gateway, the evaluation harness, the SOAR platform and analysts' decisions. This follows the conclusion of AI Platform and Security, Chapter 19, that detection comes from telemetry and decoys rather than from self-report (73, Nordqvist, 2026).

Direction matters too. Stepping down is automatic and immediate, because a delay leaves an untrusted system acting; stepping back up requires a person's approval and a passing evaluation suite. The stop path sits outside the system it stops and remains available in every mode.

Fail safe, not fail open

If a Level 3 agent that isolates compromised endpoints becomes unavailable, nothing harmful is done, yet an attack proceeds unchecked. The fallback must therefore include deterministic controls that catch the worst cases without the AI, such as high-confidence detection rules that trigger SOAR containment directly, and added analysts on shift. Conversely, a control that depends on an AI classifier to allow something should fail closed unless a documented risk decision says otherwise. The degradation-mode definition records, for each function, whether it fails open or closed and who accepted that choice.

Across the autonomy levels

Level	Degradation path	Fallback without the AI
Level 0 Advisory	Suggestions withdrawn or marked unreliable	The person works without suggestions
Level 1 Assisted	Drafts withdrawn; the person drafts from runbooks	Runbooks and manual work, by design
Level 2 Supervised	Step to Level 0, proposals shown as advice only	SOAR playbooks and analysts
Level 3 Bounded	Suspend bounded actions, then Level 2, then Level 0	Deterministic containment rules, playbooks and added staff
Level 4 Autonomous	Step to Level 3 Bounded, then down the same path; never used for offensive or irreversible actions	As for Level 3 Bounded

The higher the level, the more carefully the degradation path must be defined and staffed.

Practical guide: Defining degradation modes for a security AI capability

Purpose. Ensure that a security AI capability degrades in defined steps and that the defence continues at reduced speed without it.

Roles. The capability owner (accountable), the SOC lead (fallback and staffing), the platform team (gateway, monitoring and redeployment), the evaluation engineers, and the CISO (approval of the definition and any fail-open choice).

Steps.

List the capability's functions, such as triage, enrichment and bounded actions, and the autonomy level of each.
For each function, write and test the fallback that works without the AI: who performs it, with which playbook, with what added staffing.
Define the degradation modes as a sequence from normal to manual operation.
For each mode, define entry triggers as measurable signals from outside the AI, with thresholds and windows.
Make stepping down automatic and stepping up subject to human approval and a passing evaluation suite.
Record for each function whether it fails open or closed, with the CISO's approval for every fail-open choice.
Place the definition in version control next to the decision record and permission manifest, enforced by the gateway or orchestration layer.
Add at least one chaos experiment per mode to the catalogue of Chapter 25 and run them before go-live.

Default values to adapt. Enter manual mode after 15 minutes of unavailability; suspend bounded actions on any unannounced model change or evaluation regression; enter advisory mode when analysts reject more than 30 per cent of proposals over four hours; require a passing evaluation run within 24 hours to step up. Adapt these to volume and risk appetite.

Definition of done. Every function has a tested fallback, every mode has measurable triggers enforced outside the AI, every fail-open choice has a named approver, and a chaos experiment has verified each mode transition.

Worked example: Degradation-mode definition for the SOC investigation agent

The illustrative definition below is Hansa Mutual's for HM-SEC-001, the SOC investigation agent (Mode 5, with its own workload identity, AIDR-0311). The agent normally runs at Level 2 Supervised, with Level 3 Bounded for two reversible actions, so it must first lose those actions before falling back to advice. The monitor that evaluates the triggers runs on the SOAR platform, outside the agent's runtime.

# Illustrative: Hansa Mutual, degradation modes for HM-SEC-001
kind: DegradationModes
id: HM-SEC-001-degradation
version: 1.1.0
capability: HM-SEC-001            # SOC investigation agent, Mode 5
decisionRecord: AIDR-0311
approvedBy: group-ciso
monitor: {runsOn: soar-platform, independentOfAgent: true}
stepDown: automatic
stepUp: {approver: soc-shift-lead, requiresEvaluationPassWithinHours: 24}
modes:
  - name: normal
    autonomy: {default: 2, bounded: [revoke-sessions, isolate-endpoint]}
  - name: bounded-suspended
    autonomy: {default: 2, bounded: []}
    enterWhen:
      - {signal: evaluation-suite-regression, threshold: any}
      - {signal: model-version-changed-unannounced, threshold: any}
      - {signal: injection-detector-rate, threshold: 2x-baseline, windowMinutes: 60}
  - name: advisory
    autonomy: {default: 0}
    enterWhen:
      - {signal: proposal-rejection-rate, threshold: 0.30, windowHours: 4}
      - {signal: analyst-reports-suspected-manipulation, threshold: any}
  - name: manual
    agent: stopped
    enterWhen:
      - {signal: agent-unavailable, windowMinutes: 15}
      - {signal: stop-path-used, threshold: any}
fallback:
  playbooks: soar://playbooks/tier1-manual
  deterministicContainment: {rules: high-confidence-credential-theft, keepRunning: true}
  staffing: {addAnalystsPerShift: 1, sites: [hamburg, polish-service-centre]}
failBehaviour: {revoke-sessions: closed, isolate-endpoint: closed}
evidence:
  reportedTo: [group-ai-governance-board, dora-ict-risk-register]

The agent never decides its own mode, a rising rejection rate is a trust signal because analysts who reject most proposals have usually noticed something the metrics have not, and the deterministic rule for high-confidence credential theft keeps running in every mode, so that the most time-critical response never depends on the agent.

Testing resilience

Exercises, tests and experiments

Resilience that has not been tested is a hypothesis. Failover exercises take a site, region or supplier out of service in a planned window and verify that services, including security services, continue within their objectives. Restore tests rebuild a destroyed component in an isolated range from its known-good definitions, frequently and narrowly. Security chaos experiments inject conditions continuously and check steady-state hypotheses (Chapter 25), following Shortridge and Rinehart's definition of the discipline as proactive experimentation to identify failures in security controls (67, Shortridge & Rinehart, 2023). They catch the drift between exercises, such as a firewall rule widened for a migration and never narrowed, or a standby model that no longer passes its evaluation suite.

European obligations expect this testing. NIS 2 Article 21(2) requires business continuity measures, including backup management, disaster recovery and crisis management, and procedures to assess the effectiveness of cybersecurity risk-management measures (3, European Union, 2022). DORA requires financial entities to maintain ICT business continuity arrangements and a programme of digital operational resilience testing (2, European Union, 2022). Resilience tests should therefore produce evidence like any other control test, linked to a control identifier, a CSF Subcategory and the obligation it serves, as the profile as code of Chapter 3 expects.

AI-assisted resilience testing

AI makes resilience testing more targeted. A planner that reads the dependency graph, change history and earlier results can propose what to test next: the dependency that changed last week or the fallback playbook that has not run for a quarter. An evaluator can reconstruct where a failover exercise diverged from the plan. Both work within the safety boundaries of Chapter 25, where the AI proposes and interprets and deterministic components with scoped credentials execute (73, Nordqvist, 2026). Experiments that disable security AI run in agreed windows with the fallback staffed in advance, and an abort controller restores the AI if a real incident is declared.

Verifying with security chaos engineering

The chapter's experiments fail a segment boundary, a site or the security AI itself. All inject conditions or catalogued benign activity, never new attack behaviour, within the safety boundaries of Chapter 25.

Condition injected	Steady-state hypothesis	Time bound
A test workload connects to a segment with no declared flow	Refused at the enforcement point, logged and raised in the SOC queue	Refused at once; alert within 15 minutes
The primary site for a test environment is taken out of service	Services and security tooling fail over and meet their recovery objectives	Within each recovery time objective
The security AI's model endpoint is blocked at the gateway	The monitor moves the capability to manual mode, fallback playbooks run, and the queue stays within its backlog limit	Mode change within 5 minutes; backlog within limit for 30 minutes
An unannounced model version change is simulated in a test deployment	Bounded actions are suspended and the change is raised for reassessment	Within 10 minutes

The third row is catalogued as SCE-PR-017 against HM-SEC-001; it requires the fallback to be staffed and routes any failure to the purple backlog.

Across the usage modes

The usage mode changes what fails and who carries the work when it does (see usage modes).

Mode	Opportunity	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Vendor AI blocks at machine speed	Verdicts may stop when the vendor's cloud is unreachable, or act unannounced during an outage	The vendor's model, with the product's identity
Mode 1 Conversational assistants	Faster drafting of runbooks and fallbacks	Lost speed when unavailable; fallback is by design	A person, in the person's session
Mode 2 Embedded workplace assistants	Faster handovers in SOAR and ticketing	Silent degradation of summaries	A person, through delegated access
Mode 3 Agentic work tools	Faster segmentation policies and infrastructure code	An agent with an engineer's credentials can widen a segment rule	A person reviews; the agent uses the engineer's identity
Mode 4 Built AI applications	Triage and capacity planning at scale	Capacity exhaustion by attacker-generated load	A person decides; read-only service identity
Mode 5 Autonomous production agents	Containment at machine speed	Failure or compromise must not take the defence down	The agent's workload identity; an outside monitor sets its mode

The three AI focus areas

Securing AI systems. Security AI needs known-good definitions that include models, prompts, guardrails and permission manifests, capacity planned for attack-driven peaks, and degradation modes that fall back to people and deterministic playbooks (20, NIST, 2025).

AI-enabled cyber defence. AI assists segmentation design, capacity planning and resilience-test planning; in each case it proposes, and pipelines and people apply the change.

Thwarting AI-enabled attacks. Segmentation, default-deny egress, task-scoped credentials and regular redeployment make each step of an automated intrusion cross a boundary where it can be refused and detected, and the same boundaries contain the organisation's own agents.

Nordvik Region and Hansa Mutual

Nordvik Region depends on its European hosting provider, which reserves the accelerators, and on the MSSP that monitors out of hours. If NR-SEC-001 is unavailable, analysts and the MSSP triage from the SIEM, because a Level 1 Assisted service fails back to people by design; the Region tests these fallbacks under NR-SEC-004 and segments citizen-facing services from case management. Because NR-SEC-001 shares accelerators with the citizen-service assistant, its capacity plan treats both as failing together.

Hansa Mutual runs failover between its Frankfurt data centre and the Polish service centre, segments the group estate tightly and redeploys security AI from known-good definitions. It tests these modes through HM-SEC-006 as resilience evidence under DORA. Nordvik's resilience thus rests on contracts and fallback to its own people, Hansa's on engineered redundancy.

Summary

Under PR.IR Technology Infrastructure Resilience the infrastructure itself must limit the speed and reach of automated attacks. Segmentation and zero trust make every step cross a boundary where it can be refused and detected, and segments are checked from the inside, because a package mirror can quietly become an egress path.

Redeployment from known-good definitions, which for AI systems include the model version, prompts, guardrails and evaluation suite, turns Architecture as Code into a resilience control, and capacity is planned for peak load coinciding with an attack.

Security AI must have defined degradation modes, triggered by signals measured outside the AI, so that its failure costs the defence speed, never the defence itself. Lower usage modes fail back to people by design, while a Mode 5 agent needs an explicit path from bounded action to manual operation. The chaos experiments verify these modes and failover, producing evidence for NIS 2 and DORA. Chapter 18 opens Part V (Detect) with the AI-assisted security operations centre.

Sources

NIST. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
Rose, S., Borchert, O., Mitchell, S. & Connelly, S. Zero Trust Architecture. (23, Rose et al., 2020)
Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (44, Charrier & Weiner, 2024)
MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (14, OWASP, 2025)
Shortridge, K. & Rinehart, A. Security Chaos Engineering: Sustaining Resilience in Software and Systems. (67, Shortridge & Rinehart, 2023)
European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)