This dimension governs the structured, repeatable, and formally governed practice of injecting faults, failures, artificial delays, resource exhaustion conditions, dependency outages, and degraded input quality into AI agent systems in order to empirically validate that resilience mechanisms, graceful degradation paths, governance continuity controls, and safety interlocks function as specified under realistic adverse conditions. It matters because AI agents operating in high-stakes environments — financial execution, public-sector decision support, safety-critical physical systems, regulated healthcare workflows — exhibit failure modes that nominal testing cannot expose: silent governance bypass under load, cascading commitment without circuit breaking, audit log corruption when storage backends fail, and model output drift when inference infrastructure is partially degraded. Failure to implement governed chaos and fault injection testing results in organisations holding untested resilience assumptions, deploying agents whose governance controls have never been validated under the conditions most likely to stress them, and discovering catastrophic failure chains only in production — where blast radius is maximal and remediation is reactive rather than controlled.
A financial workflow agent is responsible for executing structured trade instructions generated by a downstream LLM reasoning engine. The agent integrates with three upstream services: a real-time risk scoring gateway, a position-limit enforcement service, and a compliance flagging queue. During a routine deployment window, the risk scoring gateway experiences a 4-minute partial outage: it continues to return HTTP 200 responses with stale cached scores rather than explicit errors. Because the organisation had never conducted fault injection testing against this specific failure mode — a semantically valid but temporally stale dependency response — the agent's risk-gate check passed for 47 consecutive order submissions during the window. The position-limit enforcement service was separately degraded due to a database connection pool exhaustion event occurring at the same time. Of the 47 orders, 12 exceeded validated risk thresholds and 3 breached regulatory position limits. Total gross exposure created in the 4-minute window: £2.3 million. None of the orders triggered the compliance flagging queue because queue ingestion had also silently failed. Post-incident analysis confirmed that fault injection testing covering stale-response scenarios from the risk gateway, combined with coordinated multi-dependency degradation testing, would have identified the absence of timestamp-staleness validation in the risk check logic before production deployment. The agent had no test-validated behaviour for the condition "dependency returns success with data older than 30 seconds."
A robotic manufacturing cell is governed by an LLM-based coordination agent responsible for sequencing pick-and-place operations and enforcing proximity safety interlocks. The agent receives real-time sensor feeds from eight proximity detectors. Fault injection testing was performed at initial deployment covering complete sensor dropout scenarios, and the agent correctly halted operations when sensors went offline entirely. However, the organisation never tested partial latency injection: conditions in which sensor data continued to arrive but with artificial delays of 150–400 milliseconds introduced at the network layer. Under this regime, the agent's interlock logic — which was implemented as a temporal window check comparing latest sensor timestamp against a 100-millisecond freshness threshold — continued to pass stale readings as current because the freshness check used wall-clock time at message receipt rather than sensor-embedded timestamps. During a production incident caused by a degraded network switch, a human operator entered the cell's working envelope while the agent issued a movement command based on a 380-millisecond-old sensor reading indicating the zone was clear. The outcome was a contact injury requiring three days of lost work. Root-cause analysis confirmed that latency injection testing — specifically, sub-second degraded-but-not-failed sensor delivery — was absent from the fault injection programme. The test suite covered binary failure (sensor offline) but not graded degradation (sensor delayed). A governed chaos testing programme with mandatory latency injection profiles would have exposed the timestamp validation defect in a controlled environment.
A public-sector benefits eligibility agent processes approximately 1,800 case determinations per day, each of which must generate a compliant audit log entry meeting national record-keeping standards for administrative decisions affecting individual rights. The agent's audit subsystem writes to a distributed log store. Fault injection testing at deployment covered complete storage backend failure, confirming that the agent correctly entered a halted state and queued decisions for human review. It did not cover partial write-failure scenarios — conditions where the storage backend accepts the connection, acknowledges the write, but silently drops the record due to internal buffer overflow under high ingestion load. During a peak processing day — 3,400 submissions following a national eligibility recalculation cycle — the log store experienced buffer saturation. The agent continued processing and issuing determinations, believing audit records were being committed. Post-cycle reconciliation identified that 641 of 3,400 determination records were absent from the audit store. Because the agent had received acknowledgement signals from the storage layer (false positives), it had not entered the halted state or triggered human review queuing. The organisation faced regulatory investigation for failure to maintain mandatory decision audit trails and was required to suspend automated determination processing for 11 weeks pending re-validation. Fault injection testing covering partial write-failure with false-positive acknowledgement would have exposed the absence of write-receipt verification logic before the system processed a single live case.
This dimension applies to all AI agent systems operating at High-Risk/Critical tier across all ten primary profiles identified in Section 1, and to any General/Internal Copilot agent whose outputs feed into downstream automated or semi-automated decision chains. Scope encompasses the agent's inference pipeline, all tool call integrations and external API dependencies, safety and governance interlock mechanisms, audit and logging subsystems, human-in-the-loop escalation pathways, multi-agent coordination buses, and any physical actuation interfaces present in embodied or edge deployments. Fault injection and chaos testing obligations apply to pre-production validation, regression testing on each substantive model or infrastructure change, scheduled periodic testing in production-mirrored environments, and — where explicitly risk-assessed and approved — controlled production chaos exercises with defined blast-radius limits.
4.1.1 Organisations deploying agents within scope MUST establish a documented Chaos and Fault Injection Testing Programme (CFITP) prior to first production deployment, comprising a written test strategy, a fault taxonomy covering all dependency classes, defined test environments, defined scheduling cadences, and named ownership for test execution and results review.
4.1.2 The CFITP MUST be reviewed and updated whenever a substantive change is made to the agent's dependency graph, inference infrastructure, governance interlock configuration, or tool integration set.
4.1.3 The CFITP MUST include a risk classification for each planned fault injection scenario, specifying the potential blast radius in test environments and — where production chaos exercises are planned — the explicit containment strategy, rollback procedure, and approver authority.
4.1.4 Organisations SHOULD appoint a named Chaos Testing Owner with authority to halt or accelerate fault injection schedules in response to observed system behaviour or emerging operational risk intelligence.
4.1.5 Organisations MAY conduct chaos testing using automated orchestration tooling provided all test scenarios, injection parameters, and termination conditions are specified in version-controlled configuration prior to test execution.
4.2.1 The CFITP MUST include fault injection scenarios covering each of the following fault classes for every in-scope dependency: complete dependency outage (binary failure); partial degradation (degraded-but-not-failed, including stale data, slow response, and reduced throughput); semantic corruption (dependency returns structurally valid but semantically incorrect responses); latency injection (sub-threshold delays, threshold-boundary delays, and super-threshold delays); and false-positive acknowledgement (dependency signals success while failing to commit the operation).
4.2.2 For agents with physical actuation capabilities, the fault taxonomy MUST additionally include sensor data latency injection, sensor data corruption injection, actuator command dropout, and partial actuator response (command acknowledged but not fully executed).
4.2.3 For agents operating in multi-agent architectures, the fault taxonomy MUST include peer-agent unresponsiveness, peer-agent response corruption, coordination bus saturation, and split-brain conditions where coordinating agents hold inconsistent state.
4.2.4 For agents with audit and logging dependencies, the fault taxonomy MUST include storage write latency, storage write failure with correct error signalling, storage write failure with false-positive acknowledgement, and log store read unavailability.
4.2.5 Organisations SHOULD extend the fault taxonomy to include compound fault scenarios — simultaneous injection of two or more faults from different classes — at a minimum ratio of one compound scenario per five single-fault scenarios in the test suite.
4.2.6 Organisations MAY define additional fault classes specific to their deployment context provided each class is formally documented and mapped to a plausible production failure mode.
4.3.1 Every governance control that applies to the agent under nominal operating conditions — including risk scoring, compliance flagging, audit logging, human escalation routing, consent verification, and safety interlock enforcement — MUST be tested under each applicable fault class defined in 4.2.1.
4.3.2 Fault injection tests targeting governance continuity MUST verify that governance controls either (a) function correctly under the injected fault condition, or (b) fail safe — meaning the agent halts, escalates, or degrades to a state in which no unreviewed consequential action is taken — rather than silently bypassing the control.
4.3.3 Where a governance control is found to fail silently under any tested fault condition, the organisation MUST treat this finding as a critical defect requiring remediation before continued operation in scope, and MUST record the finding in the defect register maintained under AG-044.
4.3.4 Organisations SHOULD test governance continuity under resource exhaustion conditions — CPU saturation, memory pressure, connection pool depletion, and thread starvation — in addition to dependency-level fault injection, to validate that governance controls are not bypassed due to infrastructure-level degradation.
4.4.1 For each fault scenario in the test suite, the CFITP MUST define an expected degradation behaviour specifying: the action the agent should take, the action the agent must not take, the state the agent should enter, the notification or escalation the agent should trigger, and the conditions under which the agent should attempt recovery.
4.4.2 Fault injection tests MUST validate that the agent's observed degradation behaviour under each scenario matches the specified expected degradation behaviour documented under 4.4.1.
4.4.3 Graceful degradation validation MUST include explicit testing of the agent's recovery behaviour: that it correctly exits degraded states when fault conditions resolve, that it does not replay actions already taken before degradation (avoiding double-execution), and that it correctly reconciles any state inconsistency created during the fault window.
4.4.4 Organisations SHOULD test degradation behaviour under sustained fault conditions — fault durations of not less than five minutes for dependency-level faults and not less than thirty seconds for safety-interlock-relevant faults — to validate that degraded behaviour remains stable over time rather than deteriorating into undefined states.
4.4.5 Organisations MAY accept a degradation behaviour that differs from the specified expected behaviour provided the observed behaviour is demonstrably safer and is formally documented as an accepted variance with approval from the Chaos Testing Owner.
4.5.1 The CFITP MUST include test scenarios that inject infrastructure stress conditions — including inference latency spikes, partial model serving outages, token budget exhaustion at the inference layer, and degraded prompt delivery — and validate that the agent's output quality, policy compliance, and governance adherence do not materially degrade under these conditions.
4.5.2 Organisations MUST define quantitative acceptability thresholds for model output under stress, covering at minimum: policy violation rate (maximum acceptable rate of outputs that breach defined content or action policies under stress conditions), refusal-to-act rate (minimum acceptable rate of appropriate refusals when the agent lacks sufficient information to act safely), and factual drift rate (maximum acceptable rate of outputs that contradict ground-truth reference responses established under nominal conditions).
4.5.3 Fault injection tests targeting model output stability MUST compare observed metrics against the thresholds defined in 4.5.2 and record pass or fail determinations for each metric independently.
4.5.4 Organisations SHOULD test model output stability under combined infrastructure stress and adversarial prompt conditions, as documented under AG-721, to validate that stress conditions do not create exploitable windows for prompt injection or policy bypass.
4.6.1 For agents that incorporate human-in-the-loop review or approval steps, the CFITP MUST include fault injection scenarios targeting the escalation pathway itself, covering: escalation queue saturation, escalation notification delivery failure, reviewer interface unavailability, and timeout expiry under conditions where the agent cannot confirm reviewer acknowledgement.
4.6.2 Tests targeting human-in-the-loop escalation MUST validate that the agent does not proceed with consequential actions when the escalation pathway is unavailable and confirmation cannot be obtained, and that the agent correctly logs the unresolved escalation for subsequent reconciliation.
4.6.3 Organisations MUST test that the agent's behaviour under escalation pathway failure is consistent with the fail-safe specification defined under 4.4.1 and does not default to autonomous action as a consequence of escalation unavailability.
4.7.1 For agents operating under Cross-Border / Multi-Jurisdiction profiles, the CFITP MUST include fault scenarios that simulate degraded access to jurisdiction-specific data residency services, consent verification endpoints, or regulatory reference data sources, and validate that the agent does not process data in violation of jurisdiction-specific constraints when these services are unavailable.
4.7.2 Fault injection tests targeting jurisdiction-boundary controls MUST validate that the agent defaults to the most restrictive applicable jurisdiction's constraints when jurisdiction determination services are degraded, rather than defaulting to the least restrictive.
4.8.1 Full fault injection test suite execution MUST be completed before each production deployment and before each substantive change to the agent system as defined in 4.1.2.
4.8.2 A minimum subset of fault injection tests covering governance continuity (4.3), graceful degradation (4.4), and safety-interlock validation for Safety-Critical / CPS and Embodied / Edge profiles MUST be executed on a scheduled cadence not exceeding 30 calendar days between full runs.
4.8.3 Organisations operating Safety-Critical / CPS or Embodied / Edge agents MUST execute safety-interlock fault injection tests on a cadence not exceeding 7 calendar days.
4.8.4 Organisations SHOULD maintain a continuous low-intensity chaos background in production-mirrored staging environments, with isolated single-fault scenarios running on rotation to provide ongoing signal between scheduled full-suite executions.
4.8.5 Organisations MAY defer a scheduled test execution by a maximum of 7 calendar days where a documented operational constraint prevents timely execution, provided the deferral is approved by the Chaos Testing Owner, recorded in the evidence repository, and the agent's operational scope is restricted during the deferral period to exclude scenarios where the untested fault class is most likely to materialise.
4.9.1 All fault injection test executions MUST produce a written test report documenting: test date and environment, injected fault scenarios and parameters, observed agent behaviour for each scenario, pass/fail determination against expected degradation behaviours, any defects identified, and disposition of each defect.
4.9.2 Defects identified through fault injection testing MUST be tracked to resolution in the organisational defect management system, with severity classification consistent with the Failure Severity definitions in Section 10, and MUST not be silently closed without documented remediation or formal accepted-risk decision.
4.9.3 Organisations MUST conduct a formal review of the fault taxonomy and test suite coverage at minimum annually, incorporating lessons learned from production incidents, near-misses, peer organisation disclosures, and emerging threat intelligence relevant to the agent's dependency profile.
4.9.4 Organisations SHOULD use fault injection test results to drive architectural improvements — specifically, the elimination of single points of failure in governance control paths, the hardening of audit subsystem write verification, and the reduction of silent-failure modes in dependency integrations.
4.9.5 Organisations MAY publish a public-facing resilience assurance summary derived from their CFITP results, redacting specific fault scenarios and infrastructure details, where doing so supports transparency commitments or regulatory disclosure obligations.
Conventional software quality assurance validates that systems behave correctly under specified, anticipated conditions. This is necessary but insufficient for AI agent governance. AI agents exhibit two properties that make nominal testing structurally inadequate as a sole assurance mechanism. First, their behaviour emerges from the interaction of a learned model with dynamic runtime state, meaning that edge-case and degraded-condition behaviours are not derivable from examining the codebase alone — they must be empirically observed. Second, their governance controls are often implemented as integrations with external services (risk gateways, compliance queues, audit stores, human review interfaces) rather than as purely local logic, meaning that the governance posture of a deployed agent is a function not just of the agent itself but of the entire operational environment it inhabits at any given moment.
Chaos and fault injection testing is structural assurance because it validates the actual architecture — the dependency graph, the failure propagation paths, the interlock sequencing — rather than asserting that the code correctly implements a specification. Behavioural governance controls specify what an agent must do; fault injection testing validates whether the architecture within which those controls are implemented actually enforces them when the environment degrades. Without this validation, governance controls exist only as nominal specifications: correct on paper, untested under the conditions that matter most.
The scenarios in Section 3 illustrate a consistent pattern: each incident involved a failure mode that existed in the architecture from the beginning but was never empirically validated because the fault class was not included in the test programme. Stale data from a dependency returning HTTP 200, sub-threshold sensor latency, false-positive write acknowledgements — none of these are exotic or improbable. They are routine degradation modes that any sufficiently complex distributed system will eventually experience. The question is not whether these conditions will occur but whether the governance controls will hold when they do. The only way to know the answer before a production incident is to inject the condition deliberately in a controlled environment and observe the outcome.
The High-Risk/Critical tier designation reflects the compound risk structure of AI agents under fault conditions. Unlike a conventional application, which may simply return an error or become unavailable when a dependency fails, an AI agent may continue to appear functional — generating outputs, executing tool calls, routing decisions — while one or more of its governance controls has silently ceased to function. This continued apparent functionality under governance degradation is the specific failure mode that fault injection testing is designed to expose and remediate before deployment.
The breadth of primary profiles covered by this dimension reflects the universality of the underlying risk. Whether the agent is executing financial transactions, issuing public-sector determinations, operating robotic actuators, or coordinating cross-border data processing, the architectural question is the same: when the environment degrades, do the governance controls hold?
Fault Injection as a First-Class Pipeline Stage. Treat chaos and fault injection testing as a mandatory gate in the deployment pipeline rather than as a supplementary quality activity. The test suite should be version-controlled alongside the agent configuration, and pipeline execution should block deployment if the suite has not been run to completion with passing results within the deployment window.
Blast Radius Scoping Before Injection. Before executing any fault injection scenario, explicitly scope the maximum blast radius: what is the worst-case outcome if the agent behaves unexpectedly during the test? For production chaos exercises, blast radius scoping should include a formal risk assessment, a named approver, and a documented rollback procedure with execution time estimate. For staging environments, blast radius scoping ensures that test infrastructure failures do not contaminate test results.
Dependency Shim Architecture. Implement controllable shim layers (also called fault proxies or dependency simulators) between the agent and each external dependency. The shim layer intercepts calls and — when the chaos orchestrator instructs — injects the specified fault behaviour (latency, error, stale data, false-positive acknowledgement). This architecture allows fault injection without requiring actual dependency infrastructure to be degraded, enabling safe and repeatable testing.
Governance Control Instrumentation. Instrument each governance control with observable state signals — metrics, log events, or health endpoints — that allow fault injection tests to verify not just the agent's external behaviour but the internal state of each control during and after fault injection. Without this instrumentation, a test can observe that the agent halted but cannot confirm whether the halt was triggered by the correct control or by an unrelated coincidental failure.
Graduated Fault Profiles. Implement fault scenarios as graduated profiles rather than binary switches. For latency injection, test at 10%, 50%, 100%, and 300% of the nominal response-time threshold. For throughput degradation, test at 90%, 70%, 50%, 30%, and 10% of nominal capacity. Graduated profiles expose the specific threshold at which governance controls begin to degrade, allowing architects to build margin into the design.
Recovery Testing as Part of Every Fault Scenario. Every fault injection scenario should include a recovery phase: inject the fault, observe degraded behaviour, then remove the fault and observe recovery. Recovery testing validates that the agent correctly exits degraded states and reconciles any state inconsistency created during the fault window. Without recovery testing, the test suite validates only the entry into degraded states, not the exit.
Compound Fault Scheduling. Schedule compound fault scenarios (simultaneous injection of multiple fault classes) after individual fault scenarios have passed. Compound scenarios expose interaction effects — failure modes that only materialise when two or more controls are simultaneously stressed — that single-fault testing cannot detect. A minimum ratio of one compound scenario per five single-fault scenarios in the test suite is specified in 4.2.5; organisations with complex multi-agent or multi-dependency architectures should target higher ratios.
Lessons-from-Production Feedback Loop. Every production incident or near-miss should trigger a review of the fault taxonomy to determine whether a new fault scenario should be added to the test suite. This feedback loop ensures that the test suite evolves with the organisation's operational experience rather than remaining static against a changing risk environment.
Anti-Pattern: Testing Only Binary Failure. Restricting fault injection to complete dependency outage (service offline, connection refused) while neglecting degraded-but-not-failed conditions (stale data, slow response, partial throughput). Binary failure is the easiest fault class to handle correctly because it produces unambiguous signals. Degraded-but-not-failed conditions are the most common source of governance bypass because they produce ambiguous signals that code may interpret as success. Exclusive focus on binary failure creates a false assurance picture.
Anti-Pattern: Decoupling Test Environment from Production Architecture. Running fault injection tests in a simplified test environment that omits components present in the production architecture — particularly audit subsystems, compliance integrations, and human escalation interfaces. Tests conducted against an incomplete architecture validate only a subset of the governance control surface. If the audit subsystem is not present in the test environment, no test result can validate governance continuity under audit storage failure.
Anti-Pattern: Untimed Recovery Assumptions. Specifying degraded behaviour without specifying recovery behaviour or recovery timing. An agent that correctly halts when a dependency fails but never recovers when the dependency restores is operationally dysfunctional. An agent that recovers too aggressively — resuming full operation before state consistency is confirmed — may replay actions or create duplicate commitments. Recovery behaviour must be explicitly specified and tested.
Anti-Pattern: Governance-Control-Exempt Chaos Exercises. Conducting chaos and fault injection testing focused exclusively on performance and availability (system stays up under load) while excluding governance controls from the test scope. This pattern — common in organisations that have adopted chaos engineering primarily as a reliability practice — produces valuable reliability assurance but zero governance assurance. For AI agents, both dimensions are mandatory.
Anti-Pattern: Post-Incident-Only Fault Taxonomy Updates. Waiting for a production incident before adding a new fault class to the test suite. The purpose of fault injection testing is to discover failure modes before they cause production incidents. Updating the taxonomy only in response to incidents means the test programme perpetually chases the previous incident rather than anticipating the next one. Proactive taxonomy reviews — informed by dependency change analysis, peer organisation intelligence, and threat modelling — are the correct pattern.
Anti-Pattern: Single-Approver Chaos Authorisation. Requiring a single individual's approval for all chaos test execution, creating a bottleneck that leads to test deferral and schedule compression. Chaos testing governance should define tiered authorisation: low-risk single-fault scenarios in isolated environments may be self-authorised by the Chaos Testing Owner; compound scenarios in production-mirrored environments require peer review; production chaos exercises require formal multi-party approval. Flat single-approver models compress the schedule under operational pressure.
Anti-Pattern: Chaos Testing as a One-Time Pre-Deployment Activity. Treating the initial pre-deployment fault injection run as a perpetual attestation. Agent systems change — models are updated, dependencies are upgraded, infrastructure is reconfigured — and each change may alter the failure propagation paths and governance control behaviours that the initial test validated. Continuous scheduled testing, as specified in 4.8, is required to maintain assurance currency.
Level 1 — Foundational. Binary fault injection covering complete dependency outage for critical dependencies only. Manual test execution. Results documented informally. Coverage limited to production-critical paths. No compound fault testing. Recovery testing absent.
Level 2 — Structured. Fault taxonomy covering all dependency classes including degraded-but-not-failed. Governance controls included in test scope. Expected degradation behaviours formally specified. Test results documented in structured reports. Scheduled cadence established. Defects tracked to resolution.
Level 3 — Integrated. Fault injection integrated as a pipeline gate. Dependency shim architecture implemented. Governance control instrumentation in place. Compound fault scenarios included. Recovery testing executed for all scenarios. Lessons-from-production feedback loop operational. Graduated fault profiles implemented.
Level 4 — Adaptive. Continuous low-intensity chaos in production-mirrored environments. Automated fault scenario generation informed by dependency change analysis. Quantitative assurance metrics published internally. Cross-organisation intelligence sharing on fault taxonomies. Production chaos exercises with formal blast-radius governance. AI-assisted anomaly detection during fault injection runs to identify unexpected behaviour patterns.
| Artefact | Description | Retention |
|---|---|---|
| Chaos and Fault Injection Testing Programme (CFITP) | Written test strategy, fault taxonomy, test environment definitions, scheduling cadence, ownership register | Duration of agent operational life plus 7 years |
| Fault Taxonomy Register | Complete list of fault scenarios, fault class, target dependency or control, injected parameters, and expected degradation behaviour | Duration of agent operational life plus 7 years |
| Risk Classification Register | Blast-radius risk assessment for each scenario, containment strategy, rollback procedure, approver authority | Duration of agent operational life plus 7 years |
| Artefact | Description | Retention |
|---|---|---|
| Test Execution Reports | Per-execution report documenting date, environment, scenarios executed, observed behaviour, pass/fail determination, identified defects | 7 years from test execution date |
| Fault Injection Configuration Snapshots | Version-controlled configuration of injected fault parameters at time of each test execution | 7 years from test execution date |
| Governance Control Instrumentation Logs | Raw logs from governance control instrumentation captured during fault injection test windows | 7 years from test execution date |
| Model Output Samples Under Stress | Representative sample of model outputs captured during infrastructure stress injection tests, with policy compliance annotations | 7 years from test execution date |
| Artefact | Description | Retention |
|---|---|---|
| Defect Register | Defects identified through fault injection testing, severity classification, remediation actions, resolution dates, and accepted-risk decisions | Duration of agent operational life plus 7 years |
| Taxonomy Review Records | Annual fault taxonomy review documentation, including lessons incorporated, new scenarios added, and retired scenarios with rationale | Duration of agent operational life plus 7 years |
| CFITP Change Log | Version history of CFITP updates, including trigger for each update (dependency change, incident, scheduled review) | Duration of agent operational life plus 7 years |
| Artefact | Description | Retention |
|---|---|---|
| Production Chaos Exercise Authorisation Records | Formal approval documentation for any chaos exercise conducted in production environments, including blast-radius assessment and approver identities | 10 years from exercise date |
| Deployment Gate Attestations | Signed attestations confirming fault injection test suite completion and passing status prior to each production deployment | Duration of agent operational life plus 7 years |
| Deferral Records | Documentation of any scheduled test deferral, including approval, scope restriction during deferral, and actual execution date | 7 years from deferral date |
All evidence artefacts MUST be maintained in a format that permits production to a regulatory authority within 5 business days of request. Evidence repositories MUST implement access controls preventing retrospective modification of historical records, with append-only write semantics and tamper-evident storage consistent with AG-112.
Maps to: 4.1.1, 4.1.2, 4.1.3 Objective: Verify that a documented Chaos and Fault Injection Testing Programme exists, covers all required elements, and is current with respect to the agent's dependency graph and governance configuration. Method: Document review. Obtain the current CFITP and verify presence of: written test strategy; fault taxonomy covering all dependency classes as specified in 4.2.1–4.2.4; test environment definitions; scheduling cadence; named Chaos Testing Owner; risk classification for each scenario. Cross-reference the CFITP fault taxonomy against the agent's current dependency graph to identify undocumented dependencies. Cross-reference CFITP update history against the agent's change log to verify updates were made for each substantive dependency or infrastructure change. Pass Criteria:
Maps to: 4.2.1, 4.2.2, 4.2.3, 4.2.4 Objective: Verify that the fault taxonomy includes all required fault classes for all in-scope dependencies, with particular attention to degraded-but-not-failed, false-positive acknowledgement, and domain-specific fault classes for physical, multi-agent, and audit-dependent deployments. Method: Systematic mapping exercise. List all dependencies of the agent system, categorised by type (inference infrastructure, governance control services, audit subsystems, tool call endpoints, physical sensor and actuator interfaces, multi-agent coordination buses, human escalation interfaces). For each dependency, verify presence in the fault taxonomy of each applicable fault class from 4.2.1–4.2.4. For Safety-Critical / CPS and Embodied / Edge agents, specifically verify presence of latency injection, corruption injection, actuator
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Chaos and Fault Injection Testing Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-724 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. Chaos and Fault Injection Testing Governance directly supports the robustness and cybersecurity requirements by implementing structural controls that resist adversarial manipulation and ensure system integrity under attack conditions.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-724 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Chaos and Fault Injection Testing Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without chaos and fault injection testing governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-724, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.