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).
Primary topics explored
- Segmentation and zero trust
- Redeploy, do not repair
- Resilience of security AI
- Testing resilience
- Summary
- Sources
About AI Red Team
AI Red Team is Book 4 of The Transformed Architecture. It shows how large European enterprises and public authorities put artificial intelligence to work as an active part of cyber defence: AI-assisted red teaming and adversary emulation, red teaming of AI systems themselves, the AI-assisted security operations centre, detection engineering, threat intelligence, incident response and purple teaming, all under a lawful mandate and with evidence a supervisor can inspect.
It builds on the conclusions of Architecture as Code, AI Governance and AI Platform and Security.
CISOs, SOC leads, red and blue team practitioners, security architects, AI architects and technical decision-makers.
Continue with the full chapter
Chapter 17: Technology Infrastructure Resilience Against Machine-Speed Attacks in AI Red Team gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Protect” and is one of 32 drawn from the manuscript.