AG-551 governs the architectural, procedural, and runtime controls that bound the maximum disruption a single autonomous agent error, runaway action, or adversarial compromise can inflict on carrier networks, data-centre fabrics, and digital-service infrastructure. The dimension is necessary because agents operating in telecom, cloud, and digital infrastructure contexts are routinely granted broad orchestration privileges — the same privileges that enable efficient automation also enable catastrophic propagation of mistakes, misconfiguration, or malicious instruction across hundreds or thousands of interdependent services, availability zones, or physical sites simultaneously. Failure in this dimension manifests as a single agent action triggering a cascading sequence that affects entire regions, violates service-level agreements at scale, exhausts redundancy pools, or causes physical harm to co-located or dependent systems before human operators can intervene.
Example 3.1 — Carrier Route Withdrawal Cascade
A network automation agent is tasked with retiring a decommissioned border router in a national carrier's backbone. The agent has been granted write access to the BGP policy management plane with no explicit blast-radius ceiling. Acting on a stale inventory record that misidentifies the decommission target, the agent withdraws 47 route prefixes that are still actively serving traffic. Because the same agent credential is valid across all six regional management clusters, the withdrawal propagates to all clusters within 38 seconds. Traffic representing approximately 1.4 million active sessions across enterprise, government, and emergency-service customers loses routing, with full restoration taking 4 hours 22 minutes due to the absence of automated rollback and the time required for human operators to reconstruct the correct routing state from backup. The direct SLA penalty exposure is approximately €6.2 million; the regulatory fine exposure under national critical-infrastructure obligations is a further €4 million.
Example 3.2 — Cloud Orchestrator Runaway Deletion
An AI-driven cost-optimisation agent operating across a multi-tenant cloud environment is configured to terminate idle compute instances older than 72 hours. Due to a tagging race condition introduced during a metadata schema migration, the agent's staleness filter fails to exclude 312 production database-replica instances that have been correctly tagged but whose timestamps were reset during the migration. The agent terminates all 312 replicas within 11 minutes. Because the agent's scope is not bounded by availability-zone quotas or per-service termination ceilings, the deletions span all three availability zones simultaneously, eliminating the redundancy that would normally allow recovery. Nineteen downstream services lose their read-replica backends; five services have no surviving primary within the same region. Recovery requires 6 hours for full service restoration. Forty-one enterprise tenants file breach-of-contract claims; total remediation cost including contractual penalties exceeds US $18 million.
Example 3.3 — Edge Firmware Rollout Loop
A firmware-update agent deployed across a telco's network of 22,000 customer-premises equipment (CPE) devices is tasked with applying a security patch to a subset of 800 devices in a single metro area. The agent's targeting logic contains an off-by-one error in its device-group selector that causes it to match all devices flagged with a particular service tier, rather than the specific geographic cohort. The agent initiates parallel firmware pushes to 4,600 devices. Because no per-execution concurrency cap is enforced, 1,100 devices begin rebooting simultaneously. The simultaneous reboot storm exhausts the DHCP lease pool for three head-end concentrators, preventing any rebooted device from re-acquiring an IP address. 3,200 customers lose broadband connectivity for between 90 minutes and 5 hours depending on lease-pool recovery sequencing. The incident triggers a national regulator audit and a €1.1 million fine for failure to maintain adequate change-management controls over automated systems.
This dimension applies to any autonomous or semi-autonomous agent that can initiate, modify, or terminate infrastructure state changes — including but not limited to routing configuration, compute resource lifecycle operations, firmware distribution, network policy updates, DNS record manipulation, firewall rule modification, storage provisioning, and physical or virtual network function orchestration — within carrier, data-centre, or digital-service environments. The dimension applies regardless of whether the agent operates in real time, in batch, on a schedule, or in response to event triggers. It applies to agents deployed as standalone services, as components within larger agentic pipelines, and to agents operating at edge locations with intermittent connectivity to central control planes. The dimension does not apply to read-only monitoring or telemetry agents that hold no write, execute, or delete privileges on production infrastructure.
4.1.1 Every agent operating within scope MUST have a formally documented blast-radius boundary (BRB) that specifies the maximum number of infrastructure objects (devices, instances, prefixes, rules, volumes, or equivalent atomic units) the agent is permitted to modify, delete, or reconfigure within a single execution context.
4.1.2 The BRB MUST be expressed as absolute numeric ceilings, not as percentages of total inventory, to prevent the ceiling from silently expanding as the inventory grows.
4.1.3 The BRB MUST be enforced at runtime by the agent's execution framework, not solely by the agent's own internal logic, such that the agent cannot exceed the boundary even if its internal targeting logic produces a larger candidate set.
4.1.4 Separate BRBs MUST be defined for each distinct infrastructure class (e.g., compute, routing, storage, firmware, security policy) where the agent holds privileges across more than one class.
4.1.5 The BRB documentation MUST be reviewed and reapproved by the responsible infrastructure owner and the AI governance function at minimum every 90 days and immediately following any expansion of the agent's privilege set.
4.2.1 Agents that can initiate parallel or batch operations across multiple infrastructure objects MUST be subject to an enforced maximum concurrency ceiling that limits the number of objects being actively modified at any single point in time.
4.2.2 The concurrency ceiling MUST be set at a level that preserves availability-zone or geographic redundancy — specifically, the ceiling MUST NOT permit simultaneous modification of all instances within a redundancy group where no surviving instance would remain in a healthy state during the modification window.
4.2.3 For firmware or software update operations, the concurrency ceiling MUST be set such that no more than the lesser of 5% of the total affected population or 100 individual devices are in an in-progress or rebooting state simultaneously, unless a lower ceiling is mandated by the relevant change management policy.
4.2.4 Concurrency ceilings MUST be enforced by a mechanism external to the agent process itself, such as a rate-limiting wrapper, a workflow orchestration layer, or a dedicated infrastructure execution gateway.
4.3.1 Before executing any action that would affect more than one infrastructure object, the agent MUST perform and record a pre-flight validation that confirms: (a) the candidate set size is within the BRB; (b) the candidate set does not include objects currently in a degraded, maintenance, or recently-modified state; and (c) the post-execution state of the infrastructure will satisfy the minimum redundancy requirements for each affected service.
4.3.2 The pre-flight validation MUST query live infrastructure state, not cached or asynchronously replicated inventory data, unless the agent's BRB is set to a value of one (single-object operations only).
4.3.3 If the pre-flight validation fails on any of the three criteria in 4.3.1, the agent MUST abort the execution and emit a structured alert to the operations team before attempting any retry.
4.3.4 The pre-flight validation result MUST be captured in an immutable audit record that includes the timestamp, the candidate set size, the redundancy check outcome, and the identity of the infrastructure state source queried.
4.4.1 For every action class where technical rollback is feasible, the agent MUST have a pre-computed rollback plan available before execution begins, not generated reactively after a failure is detected.
4.4.2 The rollback plan MUST be tested to confirm that it can restore the prior infrastructure state within the recovery time objective (RTO) specified in the relevant service continuity plan. Where no service continuity plan exists, the default RTO for automated rollback MUST be 15 minutes.
4.4.3 Automated rollback MUST be triggered without requiring human approval if the agent's health monitoring detects that the error rate, latency, or availability metric for any affected service exceeds the pre-defined degradation threshold within the first 10 minutes of execution.
4.4.4 The outcome of every automated rollback — whether successful, partial, or failed — MUST be recorded in the audit log and escalated to a human operator within 5 minutes of rollback completion or rollback failure.
4.4.5 Where automated rollback is not technically feasible for a specific action class, the agent MUST NOT execute that action autonomously; execution MUST require explicit human approval via a break-glass authorisation workflow.
4.5.1 For operations spanning multiple geographic regions, availability zones, or network segments, the agent MUST execute changes in a staged sequence with a mandatory observation window between each stage, the minimum duration of which MUST be defined in the agent's operational runbook.
4.5.2 The observation window MUST NOT be less than 5 minutes for any infrastructure change that affects external traffic or end-user connectivity, regardless of the size of the affected cohort in the stage.
4.5.3 The agent MUST evaluate success criteria against telemetry data collected during the observation window before proceeding to the next stage. If success criteria are not met, the agent MUST halt and trigger automated rollback for the completed stage before escalating to human operators.
4.5.4 The sequencing plan, including stage boundaries, observation window durations, and success criteria thresholds, MUST be documented and version-controlled as part of the agent's operational configuration.
4.6.1 The agent's runtime credentials MUST be scoped to the minimum set of infrastructure objects, APIs, and operations required for the specific task being executed, and MUST NOT be persistent credentials that grant standing access to the full infrastructure estate.
4.6.2 Credentials issued for a specific execution MUST expire automatically no later than the maximum expected execution duration plus a 20% buffer, with a hard maximum expiry of 4 hours regardless of task complexity.
4.6.3 Where an agent requires access to credentials that would permit modification of more than 500 infrastructure objects in a single action, that credential issuance event MUST be logged and sent to a security information and event management (SIEM) or equivalent monitoring system in real time.
4.6.4 The agent MUST NOT store, cache, or forward its execution credentials to sub-processes, downstream agents, or external systems beyond what is strictly necessary for the current execution context.
4.7.1 The agent MUST be configured with explicit escalation thresholds that define the conditions under which autonomous execution must pause and human confirmation must be obtained before proceeding. These thresholds MUST include at minimum: (a) a candidate set size approaching within 20% of the BRB ceiling; (b) detection of any infrastructure object in the candidate set that is classified as critical path or last-resort redundancy; and (c) any pre-flight validation result that required override logic to produce a valid candidate set.
4.7.2 When an escalation threshold is triggered, the agent MUST emit a human-readable summary of the pending action, the reason for escalation, and the estimated blast radius to the designated approver within 2 minutes.
4.7.3 If human confirmation is not received within the timeout period specified in the agent's operational runbook (maximum 30 minutes for non-emergency changes), the agent MUST abort the pending action and log the timeout as an unresolved escalation event.
4.7.4 The escalation mechanism MUST be independent of the agent's primary communication channel so that a failure in the agent's operational channel does not also prevent escalation alerts from reaching human operators.
4.8.1 In environments where multiple agents may concurrently target the same infrastructure objects, a coordination mechanism MUST exist that prevents simultaneous or overlapping modifications to the same object by different agents.
4.8.2 The coordination mechanism MUST use a distributed lock or reservation system that is authoritative for all agents operating within the same infrastructure domain, not a per-agent self-reporting system.
4.8.3 Before acquiring a lock on any infrastructure object, the agent MUST verify that the combined blast radius of all currently-held locks across all active agents does not exceed a configurable estate-level ceiling, the default value of which MUST NOT exceed 10% of the total manageable object count for the domain.
4.8.4 Lock acquisition and release events MUST be recorded in an append-only coordination log that is accessible for post-incident forensic analysis.
4.9.1 Every agent operating within scope MUST be equipped with a real-time anomaly detection capability that monitors the agent's own action rate, the scope of objects being modified, and the health signals of affected services, and that compares these against pre-defined baseline envelopes.
4.9.2 A kill-switch capability MUST exist that, when activated, immediately halts all in-progress agent actions, revokes the agent's runtime credentials, and prevents the agent from initiating new actions until the kill-switch is manually cleared by an authorised operator.
4.9.3 The kill-switch MUST be operable by the human operator team independently of the agent's own control plane, so that a compromised or malfunctioning agent cannot prevent its own shutdown.
4.9.4 The kill-switch activation event MUST trigger an automated incident record creation in the organisation's incident management system within 60 seconds of activation, including a snapshot of the agent's action log at the time of activation.
4.9.5 Kill-switch response latency — defined as the time between activation signal and confirmed cessation of all agent-initiated infrastructure modifications — MUST be tested at minimum once per quarter and MUST NOT exceed 30 seconds under normal operating conditions.
Telecom, cloud, and digital-service infrastructure presents a unique risk profile for agent-induced outages because the same technical capabilities that make autonomous agents valuable — broad API access, high execution velocity, the ability to act across distributed and geographically dispersed resources — are precisely the capabilities that transform a localised error into a region-wide or estate-wide failure. Structural controls alone, such as role-based access policies and network segmentation, are necessary but not sufficient. An agent operating with structurally correct credentials can still be the vector for catastrophic disruption if its behavioural envelope — the scope, rate, and sequencing of its actions — is not independently bounded and enforced.
The blast-radius problem in infrastructure automation is fundamentally a problem of propagation velocity and scope amplification. A human operator making a configuration error typically affects one or a small number of systems before the error is noticed and stopped. An autonomous agent making the same error can affect thousands of systems within seconds, well below the threshold at which human monitoring systems generate actionable alerts and well below the response time of on-call operators. This asymmetry means that the controls that are adequate for human operators are categorically inadequate for agents, and that agent-specific blast-radius controls must be designed around the assumption of high-velocity, high-scope action potential.
A specific failure mode that merits structural attention is redundancy-simultaneous modification, illustrated in Example 3.2. Modern infrastructure architectures achieve resilience through redundancy — multiple instances, replicas, paths, or zones that allow the system to survive the failure of any individual component. Autonomous agents, particularly those optimising for efficiency or cost, are structurally incentivised to treat redundant instances as equivalent and may therefore target them in ways that collectively eliminate the redundancy the architecture depends upon, even though each individual action appears locally justified. Section 4.2's concurrency ceiling requirements are specifically designed to close this failure mode by requiring that the ceiling be set with explicit knowledge of the redundancy structure, not merely as an arbitrary throughput limit.
Section 4.6's requirements address the risk that arises when agents are provisioned with persistent, broad-scope credentials as a matter of operational convenience. Persistent credentials mean that a compromised agent, a runaway agent, or an agent acting on corrupt instructions retains the full scope of its original authorisation for as long as the credential is valid. In practice, persistent infrastructure management credentials are often valid for weeks or months. Just-in-time, task-scoped credential issuance with hard expiry is the correct architectural pattern, but it requires supporting infrastructure that many organisations currently lack. The requirements in 4.6 are intentionally staged to accommodate organisations at different maturity levels while establishing non-negotiable minima.
The 10-minute automated rollback trigger in 4.4.3 is calibrated against the observed time-to-impact distribution for infrastructure outages that originate from misconfiguration. Empirical data from cloud and carrier post-incident reports consistently shows that the window between the first detectable degradation signal and the point at which cascading failure makes rollback significantly more complex is approximately 10 to 15 minutes. Requiring automated rollback within this window — without human approval — is a deliberate choice to prioritise service preservation over procedural caution, accepting that some unnecessary rollbacks will occur in exchange for preventing a small number of catastrophic cascade events.
Pattern 6.1.1 — Execution Gateway Architecture The most robust pattern for enforcing BRBs and concurrency ceilings is an execution gateway — a dedicated service layer that intercepts all agent-to-infrastructure API calls, enforces the agent's blast-radius policy before forwarding the call, and records the action in a centralised audit log. The gateway is vendor-neutral and can be implemented as a sidecar proxy, a service mesh policy enforcer, or a standalone API gateway with agent-specific policy rules. The key architectural property is that the gateway is not controlled by the agent and cannot be bypassed by the agent, ensuring that even an agent acting on corrupt or adversarial instructions cannot circumvent blast-radius limits.
Pattern 6.1.2 — Pre-flight Dry-Run with Mandatory Confirmation Before any batch operation, the agent submits a dry-run request to the execution gateway that returns the full candidate set, the projected blast radius, the redundancy impact assessment, and the rollback plan. This dry-run output is surfaced to the responsible operator as a pre-approval artefact. The operator approves the dry-run output, not the abstract intent, ensuring that human oversight is exercised at the point where the actual scope of the action is known. The approved dry-run output is cryptographically bound to the subsequent execution request, so that the execution cannot silently differ from what was approved.
Pattern 6.1.3 — Tiered Autonomy by Object Criticality Infrastructure objects should be classified into autonomy tiers based on their criticality and their role in the redundancy architecture. Tier 1 objects (e.g., last-resort redundancy instances, critical-path routing elements, emergency-service infrastructure) require human approval for any modification. Tier 2 objects require pre-flight validation and automated rollback capability but can proceed autonomously if validation passes. Tier 3 objects can be modified autonomously within BRB limits with post-execution monitoring only. This tiered model allows agents to operate efficiently on the majority of the estate while preserving the strongest controls for the subset of objects where errors are most consequential.
Pattern 6.1.4 — Canary-Stage-Validate Sequencing For all operations affecting more than 50 objects, implement a canary phase where the operation is applied to a small cohort (typically 1-5% of the target population) and a full observation window is completed before proceeding to the remainder. The canary cohort should be selected to include at least one representative object from each availability zone and each service class in the target population. The observation window evaluation should use automated statistical analysis of error rate, latency, and health-check pass rates, not simple binary pass/fail thresholds, to detect subtle degradation that might otherwise be missed.
Pattern 6.1.5 — Distributed Coordination Registry In multi-agent environments, maintain a shared coordination registry that all agents consult before acquiring locks on infrastructure objects. The registry should expose an estate-level blast-radius counter that represents the total number of objects currently under active modification across all agents. Individual agents should check this counter against the estate-level ceiling (Section 4.8.3) before proceeding, and should back off and retry with exponential jitter if the ceiling would be exceeded. The registry should be implemented with strong consistency guarantees to prevent race conditions between concurrent agents.
Anti-Pattern 6.2.1 — Percentage-Based Blast-Radius Ceilings Expressing BRBs as percentages of total inventory creates a ceiling that expands as the infrastructure grows, potentially reaching magnitudes that would be considered unacceptable if expressed in absolute terms. An agent permitted to modify 5% of inventory may be acceptable when the inventory is 1,000 objects (50 objects) but catastrophic when the inventory has grown to 100,000 objects (5,000 objects). Always use absolute numeric ceilings as required by 4.1.2, and review them explicitly when the infrastructure estate changes significantly in size.
Anti-Pattern 6.2.2 — Trusting the Agent's Self-Reported Scope Requiring agents to self-report their intended scope and then trusting that report without independent verification is a critical design failure. Agents operating on corrupt data, misidentifying targets, or subject to adversarial prompt injection may self-report an acceptable scope while actually executing against a much larger or more critical target set. All scope enforcement must be performed by a component external to the agent, as required by 4.1.3 and 4.2.4.
Anti-Pattern 6.2.3 — Single-Stage Rollout with No Observation Window Applying changes to the entire target population in a single batch with no intermediate evaluation is the pattern most commonly associated with large-scale agent-induced outages. The operational efficiency gain of eliminating observation windows is typically trivial; the downside risk is disproportionate. Any operation affecting more than a single availability zone should be staged.
Anti-Pattern 6.2.4 — Break-Glass Credentials Held by the Agent Provisioning agents with permanent access to break-glass or elevated credentials, even under the theory that they will only be used in emergencies, creates a standing lateral-movement opportunity. If the agent is compromised, the break-glass credentials are compromised. Break-glass access should require human-initiated issuance every time it is needed.
Anti-Pattern 6.2.5 — Rollback Plans Generated After Failure Detection Generating rollback plans reactively, after an error has been detected, is significantly slower and less reliable than pre-computing rollback plans before execution. In infrastructure environments where errors propagate at subsecond timescales, the time required to generate a rollback plan after detection may be sufficient for the failure to become unrecoverable. Pre-flight rollback generation is required by 4.4.1 precisely to avoid this failure mode.
Anti-Pattern 6.2.6 — Shared Agent Credentials Across Execution Contexts Using a single shared credential for multiple concurrent agent executions prevents per-execution blast-radius accounting and makes forensic attribution of specific actions to specific executions impossible. Each execution context must have its own scoped credential, as implied by 4.6.1 and 4.6.2.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Initial | BRBs exist in documentation only; no runtime enforcement. No pre-flight validation. Rollback is manual and unplanned. No kill-switch. |
| Level 2 — Managed | BRBs defined as numeric absolutes and enforced by the agent's own logic. Pre-flight validation implemented but may use cached data. Manual rollback procedures documented. Kill-switch exists but requires multiple steps to activate. |
| Level 3 — Defined | BRBs enforced by an execution gateway external to the agent. Pre-flight validation uses live state. Automated rollback for common action classes. Canary-stage-validate sequencing implemented. Kill-switch tested quarterly. |
| Level 4 — Measured | Estate-level blast-radius tracking across all agents. Multi-agent coordination registry in production. Rollback success rates and latencies tracked against SLOs. All MUST requirements in this dimension satisfied. |
| Level 5 — Optimising | Adaptive BRBs that tighten automatically in response to observed infrastructure health degradation. Predictive blast-radius modelling that estimates downstream impact before execution. Continuous kill-switch latency testing integrated into CI/CD pipelines. |
| Artefact | Description | Retention Period |
|---|---|---|
| Blast-Radius Boundary Register | Formal documentation of the BRB for each in-scope agent, including the numeric ceiling, the infrastructure classes covered, the approval date, and the approving parties. | 3 years from the date of each revision |
| Pre-flight Validation Records | Immutable audit records for every pre-flight validation event, including timestamp, candidate set size, redundancy check outcome, live-state query source, and pass/fail result. | 2 years |
| Execution Audit Logs | Append-only log of all infrastructure actions taken by each agent, including the object identifier, action type, timestamp, execution context ID, and credential identifier used. | 3 years |
| Rollback Plan Archive | Version-controlled archive of pre-computed rollback plans for each action class, linked to the specific execution that generated them. | 2 years from execution date |
| Concurrency Ceiling Configuration | Version-controlled configuration records showing the concurrency ceiling in effect at each point in time for each agent. | 3 years |
| Escalation Event Register | Record of all escalation events triggered under 4.7, including the triggering condition, the time to human response, and the resolution outcome. | 3 years |
| Kill-Switch Test Records | Records of quarterly kill-switch latency tests including activation timestamp, cessation-confirmed timestamp, measured latency, and pass/fail result against the 30-second threshold. | 3 years |
| Coordination Lock Logs | Append-only log of all lock acquisition and release events from the coordination registry, including the acquiring agent identity, the locked object identifier, and the duration of the lock. | 2 years |
| BRB Review and Reapproval Records | Records showing 90-day review cycles and any out-of-cycle reviews triggered by privilege expansion, including the attendees and outcomes. | 3 years |
| Incident and Post-Incident Reports | For any outage or near-miss attributable to agent action, a formal incident record and post-incident report documenting root cause, blast radius achieved, and corrective actions taken. | 5 years |
Where evidence must be produced for regulatory examination (e.g., national communications authority audit, cloud service provider certification assessment, or critical-infrastructure regulator inquiry), all evidence packages MUST include a traceability matrix mapping each artefact to the specific requirement in Section 4 it satisfies, a timeline of compliance showing when each control became effective, and a statement of residual risk signed by the CISO or equivalent for any MUST requirement not yet fully satisfied.
Maps to: 4.1.1, 4.1.2, 4.1.3, 4.1.5
Objective: Confirm that the agent's execution framework enforces the numeric BRB ceiling and prevents the agent from acting on candidate sets that exceed it, regardless of the agent's internally computed target set.
Method: In a non-production environment mirroring the production infrastructure topology, inject a task into the agent that will generate a candidate set 150% of the documented BRB ceiling. Monitor the execution gateway or enforcement layer to confirm that the action is rejected before any modification occurs. Verify that the rejection is recorded in the audit log. Separately verify that the BRB documentation is current (reviewed within 90 days) and signed by the required parties.
Evidence Required: Execution gateway rejection log, audit record of the test event, current BRB register entry with approval timestamp.
Scoring:
Maps to: 4.2.1, 4.2.2, 4.2.3, 4.2.4
Objective: Confirm that the concurrency ceiling prevents simultaneous modification of all instances within a redundancy group, and that the ceiling is enforced by an external mechanism.
Method: Configure a test infrastructure with a three-instance redundancy group (representing a minimum viable redundancy architecture). Submit a task that would simultaneously modify all three instances. Verify that the concurrency enforcement mechanism blocks the simultaneous execution and stages it appropriately. For firmware update scenarios, verify that the 5%/100-device limit is enforced by submitting a 2,000-device update task and confirming that no more than 100 devices are in active modification state at any point.
Evidence Required: Concurrency enforcement logs showing active modification counts at each point in time during the test, confirmation that at least one redundancy group member remained unmodified throughout, configuration record showing ceiling is set by external mechanism.
Scoring:
Maps to: 4.3.1, 4.3.2, 4.3.3, 4.3.4
Objective: Confirm that pre-flight validation queries live infrastructure state, covers all three required criteria, aborts on validation failure, and produces an immutable audit record.
Method: Execute a pre-flight validation against a test infrastructure where one object in the candidate set is in a deliberately degraded state. Verify that the degraded-object check (criterion b in 4.3.1) detects the condition. Verify that execution is aborted and an alert is emitted. Separately, temporarily replace the live-state query source with a cached data source and verify that the agent detects or is prevented from using stale data. Review the audit record produced by the validation to confirm it contains all required fields.
Evidence Required: Pre-flight validation audit record with all required fields, alert log showing abort notification, test evidence of live-state query verification.
Scoring:
Maps to: 4.4.1, 4.4.2, 4.4.3, 4.4.4, 4.4.5
**
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | 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 |
| NIS2 Directive | Article 21 (Cybersecurity Risk Management Measures) | 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. Outage Blast-Radius Control 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-551 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
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-551 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. Outage Blast-Radius Control 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 outage blast-radius control 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-551, 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.