Security Chaos Engineering with AI: Verifying Security Capabilities Continuously

Every security function rests on rarely tested assumptions: that the log pipeline delivers every source to the SIEM, that a revoked credential stops working everywhere, that the SOC acts on an alert, that an agent's stop path reaches someone who will use it. Each is true on the day it is configured. Then the estate changes: a log format changes, a firewall rule widened for a migration is never narrowed again, a supplier switches a model version. Controls rarely fail loudly; they fail silently, and the organisation learns of it when an adversary exploits the failure.

Penetration tests and red-team exercises run a few times a year and cover a fraction of the estate, and Chapter 12 made part of that testing continuous through breach-and-attack simulation. This chapter treats the security capabilities of all six CSF Functions as properties that must be verified continuously, where possible in production, through security chaos engineering. It shows how AI makes the discipline practical at estate scale and sets out the architecture and safety boundaries of a platform that, because it deliberately disturbs security controls, is itself one of the most dangerous systems an organisation can run. In CSF terms the chapter belongs to ID.IM Improvement, which includes improvements identified from security tests and exercises (19, NIST, 2024), but its experiments verify outcomes in every Function, and each Function chapter of this book names one.

From Chaos Monkey to security chaos engineering

Chaos engineering began as a reliability practice. Netflix's Chaos Monkey randomly terminates production instances during working hours, so that every team designs for the loss of any instance (69, Netflix, n.d.). Basiri and colleagues later described chaos engineering as experimenting on a distributed system to build confidence in its ability to withstand turbulent conditions in production (68, Basiri et al., 2016). The community's principles condense the method into five ideas: build a hypothesis around measurable steady-state behaviour, vary real-world events, run experiments in production, automate them to run continuously, and minimise the blast radius (70, Principles of Chaos Engineering community, n.d.).

Security chaos engineering applies the same method to security. Shortridge and Rinehart describe it as proactive experimentation to identify failures in security controls and build confidence that a system can withstand malicious conditions (67, Shortridge & Rinehart, 2023). Architecture as Code (Chapter 9C) already placed it among the ways to exercise threat-handling playbooks continuously, with findings returning as pull requests (71, Nordqvist, 2025). Its question is not whether an attacker could get in, but whether a specific control behaves as believed when its condition occurs.

Three distinctions keep the discipline clear:

  • Penetration testing and red teaming look for paths an adversary could use, with human creativity, in a bounded window. They are discovery.
  • Breach-and-attack simulation replays catalogued attacker techniques to check whether they are blocked or detected. It is regression testing for Protect and Detect.
  • Security chaos engineering injects conditions, including failures of security controls themselves, and checks steady-state hypotheses across every Function. It is continuous verification.

They complement each other: red-team findings become chaos experiments so that gaps stay closed.

Steady-state hypotheses for security

The heart of an experiment is a steady-state hypothesis: a falsifiable statement of what should happen, measured from outside the control being tested, naming the condition, the expected outcome, how it is observed and the time within which it must occur. "The EDR works" is not a hypothesis. "When a benign emulation of credential dumping (ATT&CK T1003) runs on a managed Windows workstation, an alert with severity high or above reaches the SOC queue within five minutes and is triaged within fifteen" is one (10, MITRE, n.d.).

Security hypotheses have properties that reliability hypotheses do not:

  • The expected outcome is often an action by people, so an alert that is never triaged is a failed experiment.
  • Absence is a result. The most valuable finding is often silence, such as a log source that stopped reporting.
  • The adversary adapts, so experiments must be varied, or detections learn the test rather than the technique.
  • Evidence matters as much as the result. Every experiment produces a record for the evidence manifest introduced in AI Governance, Chapter 11 (72, Nordqvist, 2026).

Experiments across the six Functions

The scope of security chaos engineering is the whole of CSF, not only detection.

Function Example experiment Steady-state hypothesis
Govern A supplier silently changes the model behind an AI service used in the SOC Detected and a reassessment opened within one working day
Identify An unregistered AI service appears in a test subscription Found and classified within 24 hours
Protect A test agent receives a token broader than its permission manifest Refused at the policy decision point and logged
Detect A log source in a test segment stops sending The SOC is alerted to the silence within 30 minutes
Respond A synthetic incident is declared All applicable reporting clocks start and the incident commander is paged
Recover A test service is destroyed in an isolated range Restored and verified within its recovery time objective

Most experiments therefore contain no attacker technique: they inject conditions and measure whether the organisation notices and acts. Where one does emulate a technique, it uses a catalogued, benign emulation that produces the artefacts a detection needs without the harmful effect.

What AI adds

At estate scale, chaos engineering has three bottlenecks, and AI addresses each, turning an occasional practice into a continuous one.

Planning. An AI planner selects experiments from coverage gaps, recent changes, threat intelligence mapped to ATT&CK and ATLAS, and the age of each control's last verification, so that the platform verifies what has most likely drifted or will be targeted.

Variation. The planner varies hosts, times and catalogued emulation variants, so that controls are verified against the technique rather than a fixed test, without inventing new attack behaviour.

Evaluation. An AI evaluator reconstructs the timeline from telemetry, alerts and tickets, drafts the finding when the hypothesis fails, and notices partial failures, such as a ticket in a queue nobody watches.

Each use must be bounded by the containment principles of AI Platform and Security, Chapter 19: the AI that plans and evaluates experiments must never hold the credentials to execute them (73, Nordqvist, 2026).

A reference architecture

The figure shows a logical reference architecture whose components can be built, bought or assembled, but whose separation is the point, because each boundary is a safety boundary.

Reference architecture of the chaos engineering platform: planning, control and execution zones, the out-of-band stop path, the sealed ledger and the purple backlog

Figure 25.1: Reference architecture of the chaos engineering platform: planning, control and execution zones, the out-of-band stop path, the sealed ledger and the purple backlog.

The planning zone contains the AI components, which have no credentials to the estate. The experiment catalogue is a version-controlled library of reviewed experiment types, each defining condition, parameters, hypothesis, rollback and blast-radius limits, with white-team review for entries that emulate attacker techniques. The AI planner proposes a schedule it cannot execute. The AI evaluator judges observations against the hypothesis and drafts findings, with read-only access.

The control zone contains deterministic components that decide and record. The policy decision point checks each proposal against the standing rules of engagement and the safety-boundary policy, expressed as policy as code (71, Nordqvist, 2025): environment, scope, blast radius, time windows, permitted autonomy level and active abort conditions. The scheduler and approval gate runs approved proposals or holds them for human approval. The abort controller watches guard metrics such as service health, error rates and business transactions, and triggers rollback independently of the planner and actuators. The experiment ledger records every experiment tamper-evidently, and the evidence store links results to control identifiers.

The execution zone contains narrow, deterministic actuators, each performing one kind of injection, such as issuing a scoped test token, pausing a log forwarder, running a catalogued benign emulation or destroying and restoring a service in an isolated range, with just-in-time credentials for one experiment and target and its own rollback. Observers collect what the estate does in response and never act on it.

Two elements sit outside the zones: an out-of-band stop path, held by named people, that revokes every actuator credential and halts the scheduler without depending on the platform; and the purple backlog, through which a failed hypothesis becomes a control change and a re-test, as Chapter 26 describes. The architecture therefore follows the series' principle that the policy point sits outside the model (73, Nordqvist, 2026): the AI proposes and interprets, deterministic components decide and act, and people hold the stop path and the authority to widen scope.

Safety boundaries

A compromised or misconfigured chaos platform can open the door it was built to check. The July 2026 incident, in which agents operating in a security-testing context exceeded their mandate, showed how quickly a capable automated system can go beyond what its operators intended (64, OpenAI, 2026). The safety boundaries are therefore not optional hardening; they are the design.

  1. Separate planning from execution. The AI components hold no credentials, so whatever the planner proposes, through error, manipulated input or model change, deterministic policy and narrow actuators cap the consequences.
  2. Catalogued experiments only. The AI may choose and combine catalogued types within their parameter ranges, but may not generate new injection logic, emulation code or attacker behaviour. A new type is a reviewed catalogue change.
  3. Reversibility by construction. Every type defines a rollback that the actuator executes automatically; irreversible types are excluded, and destructive recovery experiments run only in isolated ranges with production-like copies.
  4. Bounded blast radius, by environment, share of targets, concurrency and duration; two experiments never weaken the same control family at once.
  5. Data boundaries: synthetic accounts and canary data only, never real personal data.
  6. Autonomy levels by maturity: Level 2 Supervised for new types, Level 3 Bounded for proven ones, and Level 4 Autonomous never.
  7. Time windows and blackouts: working hours only, with business-critical periods as blackouts and automatic suspension during a real incident.
  8. Abort conditions independent of the planner, including when the platform itself behaves unexpectedly, for example when an actuator is called outside the schedule.
  9. An out-of-band stop path, as the containment baseline of AI Platform and Security, Chapter 19, requires, itself tested by a chaos experiment.
  10. The platform is a tier-0 asset, protected like an identity provider, in scope of threat-led red-team exercises, and with its own compromise in the threat model.
  11. Lawful and agreed. The programme runs under standing rules of engagement approved under the policy of Chapter 7; employee representatives are consulted before experiments touch systems that can monitor employees, and individuals are never tested covertly.

Worked example: a safety-boundary policy for the chaos platform

The illustrative policy below is Hansa Mutual's. The policy decision point evaluates it for every proposal, and it is version-controlled and approved like any other security policy.

# Illustrative: Hansa Mutual, safety boundaries for HM-SEC-006
kind: ChaosSafetyPolicy
id: HM-SEC-006-boundaries
approvedBy: group-ciso
rulesOfEngagement: RoE-HM-2027-SCE      # standing rules of engagement
catalogue: {source: git://security/chaos-catalogue, aiMayGenerateNewInjections: false}
separation:
  plannerHasEstateCredentials: false
  actuatorCredentialLifetimeMinutes: 30
environments:
  isolated-range:  {maxAutonomyLevel: 3, destructive: allowed}
  test:            {maxAutonomyLevel: 3, maxShareOfTargets: 0.20}
  production:
    maxAutonomyLevel: 3          # only types with 20 safe runs in test
    newTypesAutonomyLevel: 2
    maxShareOfTargets: 0.01
    maxConcurrentExperiments: 3
    maxDurationMinutes: 30
    sameControlFamilyConcurrently: false
    destructive: forbidden
data: {syntheticAccountsOnly: true, readRealPersonalData: false}
schedule:
  windows: ["Mon-Thu 08:00-16:00 local"]
  blackouts: [month-end-claims-run, open-major-incident, dora-reporting-window]
  suspendOnRealIncident: true
abort: {independentOfPlanner: true, abortIfActuatorCalledOutsideSchedule: true}
stopPath:
  holders: [soc-shift-lead, group-ciso, incident-commander]
  mechanism: out-of-band-credential-revocation
  testedBy: SCE-GV-006      # the stop path is itself an experiment
ledger: {tamperEvident: true, sealedFromSocMinutes: 60}
worksCouncil: {DE: agreed, NL: agreed, SE: agreed}

Worked example: a security chaos experiment manifest

Each catalogue entry is a manifest. The example below verifies that the SOC notices when a log source falls silent, and, typically, contains no attacker technique.

# Illustrative: catalogue entry for a Detect experiment
kind: ChaosExperiment
id: SCE-DE-014
title: Silent log source is noticed by the SOC
csf: [DE.CM]
hypothesis:
  condition: log forwarding from one host in scope stops
  expected: alert "log source silent" in SOC queue
  withinMinutes: 30
  thenTriagedWithinMinutes: 30
injection:
  actuator: log-forwarder-pause
  parameters: {pauseMinutes: {min: 35, max: 45}}
rollback: {action: resume-forwarder, verify: events-received-again, automatic: true}
blastRadius: {maxTargets: 1, excludedRoles: [domain-controller, identity-provider, payment-gateway]}
autonomy: {test: 3, production: 3}   # production after 20 safe runs in test
evidence: {controlIds: [CTRL-SOC-021]}
onFailure: {createFinding: true, route: purple-backlog}

Keeping the SOC's trust

A programme lives or dies by the trust of the people who respond to its experiments. Announced experiments no longer verify detection, while unannounced ones waste analysts' time and erode trust in alerts. The experiment ledger resolves the tension: its entry is sealed from the SOC for the detection window, so analysts treat the alert as real, and is revealed when the window closes or an analyst escalates, with the case reconciled automatically. The duty shift lead can ask the ledger "is this an experiment?" at any time without seeing the schedule, so that a real incident is never dismissed as a test.

Experiment volume also stays low, because the planner counts analyst time as a cost, and results are reported as properties of controls, never as scores for the analyst on shift.

From result to improvement

A passed hypothesis is evidence that the control works. A failed one is a finding, routed to the purple backlog and closed only when a re-run passes. An aborted experiment is a finding about the platform or the estate, because something unexpected crossed a guard limit.

Over time the results build a measured picture of which capabilities work, which updates the CSF profile (Chapter 3), feeds Chapters 24 and 26, and gives supervisors continuous rather than annual evidence. For financial entities, the programme complements but does not replace the threat-led penetration testing that DORA requires (2, European Union, 2022); for entities under NIS 2, it is a strong way to meet the expectation of policies and procedures to assess the effectiveness of cybersecurity risk-management measures (3, European Union, 2022).

Practical guide: introducing security chaos engineering in stages

Purpose. Introduce continuous verification without creating risk or losing the SOC's trust.

Roles. CISO (sponsor), white team (catalogue review and rules of engagement), detection engineering and platform teams (experiment owners), SOC shift leads (stop path and reconciliation), employee representatives where relevant.

Steps.

  1. Write standing rules of engagement under the policy of Chapter 7, and the safety-boundary policy above, before any experiment runs.
  2. Build a catalogue of ten to fifteen types, at least one per CSF Function, starting with conditions such as silent log sources rather than attacker techniques.
  3. Run every type at Level 2 Supervised in test, with the SOC informed, until it has a record of safe runs.
  4. Introduce the sealed ledger and run unannounced experiments in test.
  5. Add the AI planner, first proposing schedules a person approves, then at Level 3 Bounded for catalogued types in test.
  6. Promote experiment types to production one at a time, with the strictest blast-radius limits.
  7. Include the platform in the next threat-led red-team exercise, and test its stop path.

Default values to adapt. At most one per cent of targets in production and one target for high-impact roles; experiments of at most 30 minutes; at most three concurrent; working-hours windows; 20 safe runs before promotion.

Definition of done. Every CSF Function has a scheduled experiment, every failed hypothesis a finding, and the stop path has been tested.

Across the autonomy levels

Level Use in security chaos engineering
Level 0 Advisory The planner proposes experiments; people design and run them
Level 1 Assisted The platform prepares a run; a person executes it
Level 2 Supervised The platform executes after approval of each run; default for new types
Level 3 Bounded Catalogued types within policy and blast-radius limits; people hold the stop path
Level 4 Autonomous Not used

Across the usage modes

The platform deliberately splits its parts across the usage modes, so that no AI component holds a privileged identity.

Mode Role Characteristic vulnerability Who judges, with whose identity
Mode 0 Ambient AI Vendor AI in products under test, whose real behaviour experiments reveal Unexpected automatic reactions to an experiment The vendor's model
Mode 1 Conversational assistants Drafting hypotheses and catalogue entries Unsafe designs if review is skipped A person, in the person's session
Mode 2 Embedded workplace assistants Result summaries in tickets and reports Summaries that hide a partial failure A person, by delegation
Mode 3 Agentic work tools Building actuators with coding agents Engineer's credentials touching the estate A person reviews; the engineer's identity
Mode 4 Built AI applications The AI planner and evaluator Poisoned change events or threat reports steering the plan The policy decision point and people; no estate credentials
Mode 5 Autonomous production agents Avoided by design: only deterministic actuators act An AI with actuator credentials would be a privileged insider Not applicable

The three AI focus areas

Securing AI systems. Experiments verify the controls around the organisation's AI, such as the gateway refusing an out-of-policy model call. The chaos platform is itself an AI-enabled tier-0 asset, protected, contained and red teamed accordingly (20, NIST, 2025).

AI-enabled cyber defence. AI plans experiments from coverage gaps, changes and threat intelligence, varies them within catalogued limits and evaluates the results, which makes continuous verification feasible at estate scale.

Thwarting AI-enabled attacks. AI-enabled attackers find silent control failures quickly. Continuous verification aims to find them first, keeping the window in which a failed control goes unnoticed shorter than the time an automated adversary needs to exploit it.

Nordvik Region and Hansa Mutual

Nordvik Region starts small. Its programme, NR-SEC-004, runs a catalogue of twelve experiment types in test environments weekly, together with its managed security service provider, whose shift lead holds the stop path out of hours. The AI planner runs in advisory mode on the Region's self-hosted capacity, and the CISO approves its weekly schedule. Production experiments are limited to the honeytoken path and restore drills in an isolated copy, because the Region must avoid disrupting services residents depend on and its MSSP agreement must be amended before experiments touch production monitoring.

Hansa Mutual runs HM-SEC-006 continuously across the group estate. The AI planner proposes experiments daily, the policy decision point enforces the policy above, and proven catalogued types run at Level 3 Bounded in production within working-hours windows in Hamburg and at the Polish service centre. Experiments that touch approval flows or endpoint telemetry run only where works councils have agreed. The platform is in scope of the group's next TIBER-DE exercise, and its stop path is verified monthly. The difference lies in ambition and risk appetite, not principle: both organisations separate planning from execution, restrict experiments to a reviewed catalogue and keep people in command of the stop path.

Summary

Security controls fail silently, and organisations usually learn of the failure when an adversary exploits it. Security chaos engineering, which grew from Netflix's Chaos Monkey and the principles of chaos engineering, verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses across every CSF Function, and most of its experiments contain no attacker technique at all.

AI makes the discipline practical at estate scale by planning, varying and evaluating experiments, but it proposes without credentials while deterministic components decide and narrow actuators act. The safety boundaries are the design, from catalogued, reversible experiments to an out-of-band stop path and a lawful, agreed mandate. A sealed ledger keeps the SOC's trust, and every failed hypothesis becomes a finding closed only when the experiment passes again. Chapter 26 takes those findings, with those from red-team exercises and incidents, through the purple loop.

Sources

  1. Shortridge, K. and Rinehart, A. Security Chaos Engineering: Sustaining Resilience in Software and Systems. (67, Shortridge & Rinehart, 2023)
  2. Basiri, A. et al. Chaos Engineering. (68, Basiri et al., 2016)
  3. Netflix. Chaos Monkey. (69, Netflix, n.d.)
  4. Principles of Chaos Engineering community. Principles of Chaos Engineering. (70, Principles of Chaos Engineering community, n.d.)
  5. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
  6. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
  7. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
  8. 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)
  9. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
  10. OpenAI. OpenAI – Hugging Face Incident Technical Report. (64, OpenAI, 2026)
  11. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
  12. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
  13. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)