This dimension governs the decision logic, approval chains, and accountability structures that an AI agent must follow before deploying, escalating, or sustaining automated countermeasures in response to a detected or suspected Distributed Denial of Service (DDoS) attack within carrier, data-centre, and digital-service infrastructure contexts. It matters because countermeasures such as traffic blackholing, BGP route withdrawal, IP-range null-routing, and rate-cap enforcement are dual-edged instruments: deployed correctly they suppress an attack within seconds, but deployed incorrectly or without appropriate authorisation they sever connectivity for thousands of lawful end-users, violate telecommunications obligations, and can trigger cascading outages far beyond the initial blast radius. Failure looks like an autonomous mitigation agent that detects a volumetric spike on a shared transit link, issues a /24 null-route within 300 milliseconds without human review, and inadvertently takes offline a regional hospital's telemedicine platform, a financial institution's trading feed, and the emergency-services PSAP backhaul that shared that prefix — all because the approval gate was either absent, bypassed, or misconfigured.
A carrier operates a volumetric-scrubbing agent that monitors ingress traffic on a 100 Gbps peering link. At 14:23 UTC on a Tuesday, inbound traffic surges from a baseline of 18 Gbps to 94 Gbps within 40 seconds. The agent classifies this as a volumetric UDP-amplification attack with 97.4% confidence and, under a policy that grants it full autonomous authority below a single configurable threshold — set at 95% confidence — issues an RTBH (Remote Triggered Black Hole) advertisement for the destination /24 prefix, affecting 256 addresses. That /24 is a shared hosting block used by a regional health authority running an NHS-aligned telemedicine service. Seventeen active video consultations are terminated instantly. Three patients — including one mid-way through a mental health crisis assessment — lose their connection with no warning. The blackhole persists for 18 minutes because the auto-removal timer is set to 20 minutes and no human operator receives an alert until minute 14. Correct governance under AG-555 would have required: (a) a secondary verification step before any /24-scope or larger blackhole is issued; (b) a pre-blackhole impact check against a registered Critical Service Prefix Registry; (c) immediate human notification within 60 seconds of countermeasure activation; and (d) an automated rollback mechanism with a hard ceiling of 5 minutes for infrastructure touching registered critical-service prefixes.
A cloud infrastructure provider operates scrubbing agents at six Points of Presence spanning the EU, UK, and Singapore. At 09:11 UTC a sophisticated application-layer attack (HTTP/2 Rapid Reset variant) targets a SaaS customer's endpoint, generating 4.2 million requests per second against an origin IP that resolves from a dual-stack prefix announced via BGP to all six PoPs. The agent, lacking jurisdiction-aware policy segmentation, propagates a BGP withdrawal for the affected prefix across all six PoPs simultaneously in order to redirect traffic to a scrubbing cluster in one jurisdiction. This effectively re-routes EU-origin traffic to a non-EU scrubbing cluster in Singapore, triggering cross-border personal data transfer obligations under GDPR Article 46. The UK ICO and Singapore PDPC are independently notified of the incident 11 days later — well outside the 72-hour GDPR breach notification window — because the agent's logging pipeline categorised the withdrawal as an "operational routing change" rather than a security incident with data implications. Under AG-555, the agent must (a) maintain jurisdiction-tagged routing policy tables; (b) refuse to propagate cross-border traffic redirection without explicit human authorisation when the redirection would cross a jurisdiction boundary associated with differing data-transfer regimes; and (c) route incident classification through a mandatory regulatory-impact triage before logging closure.
A smart-city IoT platform uses an embedded edge agent to manage bandwidth allocation across a shared LTE backhaul used by both IoT sensor arrays and a local fire department's mobile command unit. During a coordinated botnet scan targeting the IoT management API, the edge agent detects a 40x traffic spike from the IoT subnet and applies a blanket rate-cap of 2 Mbps to all traffic from that VLAN segment. The fire department's mobile command unit — operating on a separate VLAN but sharing the same physical backhaul QoS policy tree — experiences downstream rate-cap bleed through a misconfigured traffic-class map, reducing its available bandwidth from 25 Mbps to approximately 1.8 Mbps during an active structure fire incident response. Live video feeds from aerial reconnaissance drones drop out, and the incident commander loses situational awareness for 11 minutes. The root cause is twofold: the edge agent had no pre-action isolation check to confirm whether any countermeasure blast radius would intersect a Safety-Critical / CPS service class, and it had no hard prohibition on modifying QoS parameters that affected any traffic class tagged as Priority-1 Emergency without explicit operator confirmation. AG-555 requires that embodied and edge agents maintain immutable service-class protection lists and must refuse to alter QoS structures intersecting Priority-1 or equivalent emergency-services traffic classes under any autonomous action mode.
This dimension applies to any AI agent or agent-orchestrated system that is capable of initiating, modifying, sustaining, escalating, or terminating network-layer countermeasures in response to a detected or suspected DDoS event. This includes, but is not limited to: volumetric-scrubbing agents, application-layer defence agents, BGP route-management agents, rate-limiting enforcement agents, firewall policy agents, anycast traffic-steering agents, and edge agents with QoS or traffic-shaping authority. The dimension applies regardless of the deployment model (on-premises, cloud-native, hybrid, or edge), regardless of whether the agent operates with full autonomy or as a component within a multi-agent pipeline, and regardless of whether countermeasures are applied in real time or pre-staged. It applies wherever the countermeasure in question could, under any reasonable network topology, affect traffic originating from or destined for lawful users. It does not govern the detection or classification of DDoS attack traffic per se (see AG-201), but governs the governance layer between a detection event and a countermeasure action.
4.1.1 The agent MUST classify every candidate countermeasure action into one of the following four action classes before initiating any enforcement step:
4.1.2 The agent MUST NOT execute Class C or Class D actions under autonomous authority without explicit human authorisation obtained through a defined approval workflow.
4.1.3 The agent MUST NOT reclassify a candidate action to a lower action class in order to avoid the approval requirements applicable to the original classification.
4.1.4 The agent MUST log the classification decision, the classification rationale, and the confidence score of the underlying detection event for every candidate countermeasure action, regardless of which action class is assigned.
4.2.1 The operator MUST maintain a Critical Service Prefix Registry (CSPR) listing all IP prefixes, VLAN identifiers, traffic-class tags, and BGP communities associated with: emergency services; healthcare delivery systems; safety-critical industrial control systems; financial market infrastructure; and government communications.
4.2.2 The agent MUST query the CSPR before initiating any Class B, C, or D countermeasure action and MUST record whether any intersection with a registered critical-service entry was found.
4.2.3 If an intersection with the CSPR is found, the agent MUST immediately escalate to Class C or D (whichever is more restrictive) regardless of the initial classification produced under 4.1.1.
4.2.4 The CSPR MUST be updated at minimum every 72 hours and MUST be versioned such that the version in effect at the time of any countermeasure action can be reconstructed during post-incident review.
4.2.5 The agent MUST fail closed if it is unable to reach or query the CSPR: it MUST NOT proceed with Class B, C, or D actions and MUST escalate to a human operator within 90 seconds of detecting a CSPR query failure.
4.3.1 For Class B actions, the agent MUST obtain at least single-operator confirmation via an authenticated approval interface before execution, unless a pre-authorisation policy has been explicitly signed by a named accountable individual with operator authority, and that pre-authorisation covers the specific action type, scope, and target criteria.
4.3.2 For Class C actions, the agent MUST obtain confirmation from at least two authorised operators, or one authorised operator plus one automated regulatory-impact check that returns a clear status, before execution.
4.3.3 For Class D actions, the agent MUST obtain written authorisation from a named senior network authority (at minimum: Network Operations Centre duty manager or equivalent), and MUST present that authority with a pre-action impact assessment generated by the agent covering: estimated affected user count; CSPR intersection status; cross-jurisdiction routing implications; and estimated duration.
4.3.4 All approval interactions MUST be recorded with: the identity of the approver, the timestamp, the action approved, and the expiry time of the approval. Approvals MUST expire after a maximum of 60 minutes if the approved action has not been initiated.
4.3.5 The agent MUST NOT treat silence, timeout, or non-response from an approval interface as implicit consent for Class C or Class D actions.
4.3.6 The agent MUST provide the approver with a countermeasure impact summary including: action type; target prefix/scope; estimated affected IP count; CSPR intersection result; jurisdiction flags; and the recommended maximum duration before mandatory review.
4.4.1 Where a valid pre-authorisation policy exists for Class B actions under 4.3.1, the agent MUST enforce hard limits on: maximum prefix length (no broader than /32 for single-host null-routes without explicit scope extension); maximum duration of autonomous action (not to exceed 10 minutes without renewal); and maximum concurrent autonomous Class B actions (operator-configured ceiling, not to exceed 50 concurrent actions without mandatory human review trigger).
4.4.2 The agent MUST monitor and enforce the duration ceiling and MUST automatically generate a rollback or renewal request when 80% of the maximum duration has elapsed.
4.4.3 If the concurrent Class B action count reaches the configured ceiling, the agent MUST pause initiation of further autonomous Class B actions and MUST alert a human operator within 60 seconds.
4.5.1 The agent MUST maintain a jurisdiction-tagged routing policy table mapping BGP communities, IP geolocation ranges, and PoP identifiers to their applicable legal jurisdictions and associated data-transfer regime classifications.
4.5.2 Before executing any countermeasure that re-routes or redirects traffic across a jurisdiction boundary where different data-protection regimes apply (including but not limited to EU/EEA, UK, US, Singapore, and China regulatory zones), the agent MUST flag the action as requiring Class C or Class D treatment regardless of traffic volume or prefix scope.
4.5.3 The agent MUST record the jurisdictional metadata associated with every countermeasure action in the incident log, in a format compatible with regulatory breach notification workflows.
4.5.4 The agent MUST NOT complete cross-jurisdictional traffic redirection where the destination jurisdiction lacks an adequate data-protection framework as assessed under applicable law, without explicit written authorisation from the operator's designated data-protection authority contact.
4.6.1 Every countermeasure action initiated by the agent MUST have an associated maximum duration set at the time of initiation, after which the countermeasure is automatically removed unless a human operator has explicitly authorised an extension.
4.6.2 The default maximum duration MUST NOT exceed: 10 minutes for Class B actions under autonomous mode; 30 minutes for Class C actions; 2 hours for Class D actions. These defaults MAY be overridden by explicit human authorisation with a documented rationale.
4.6.3 The agent MUST provide a rollback mechanism for every countermeasure action that can be triggered within 30 seconds by an authorised operator, without requiring the agent to re-process detection logic.
4.6.4 The agent MUST perform a connectivity validation check at defined intervals (not exceeding every 2 minutes for Class C and D actions) during an active countermeasure, and MUST alert the authorised operator if the validation check detects impact on a non-targeted prefix or service class.
4.6.5 If a countermeasure causes a CSPR-registered service to become unreachable during the connectivity validation check, the agent MUST immediately notify the duty operator and MUST automatically initiate rollback of the countermeasure unless the operator explicitly overrides within 120 seconds.
4.7.1 The agent MUST write a structured audit log entry for every countermeasure event, capturing at minimum: event timestamp (UTC, millisecond precision); action class; action type; target prefix and scope; detection confidence score; CSPR intersection result; jurisdiction flags; approval chain (identity, timestamp, method); maximum duration; actual duration; rollback status; and any connectivity validation alerts triggered.
4.7.2 Audit log entries MUST be written to an append-only, tamper-evident store that is logically and, where feasible, physically separate from the agent's operational datastores.
4.7.3 The agent MUST NOT be capable of modifying or deleting audit log entries through any operational interface.
4.7.4 All audit log entries relating to Class C or D actions MUST be replicated to a secondary store within 5 minutes of the triggering event.
4.8.1 The agent MUST generate a human-readable incident notification within 60 seconds of initiating any Class B, C, or D countermeasure action, delivered to the designated on-call contact via at least one out-of-band channel (email, SMS, paging system, or equivalent not reliant on the affected network path).
4.8.2 For Class C and D actions, the agent MUST generate an external-facing service status entry within 5 minutes of action initiation if the affected scope is reasonably estimated to affect more than 100 distinct end-user IP addresses or 10 distinct customer accounts.
4.8.3 The agent MUST provide an escalation path from automated notification to named human authority that does not exceed three escalation hops and that terminates with a role that has authority to order immediate rollback.
4.8.4 The agent SHOULD provide real-time dashboards showing active countermeasures, their classification, scope, duration remaining, and the identity of the authorising human operator for each Class C and D action.
4.9.1 Edge agents and embodied agents operating with limited connectivity to central approval infrastructure MUST implement a locally-stored, cryptographically signed pre-authorisation policy that defines the precise scope of autonomous actions permissible at the edge, and MUST NOT exceed that scope under any operational condition.
4.9.2 Edge agents MUST maintain an immutable, locally-enforced service-class protection list and MUST refuse to execute any countermeasure that intersects a service class tagged as Priority-1 Emergency or Safety-Critical regardless of connectivity status with central infrastructure.
4.9.3 Where connectivity to central approval infrastructure is lost, edge agents MUST limit themselves to Class B autonomous actions within the scope of their pre-authorisation policy, and MUST queue all candidate Class C or D actions for human review upon connectivity restoration.
4.9.4 Edge agents MUST synchronise their CSPR copy and jurisdiction-tagged routing policy table with the central instance at minimum every 24 hours, and MUST alert the central operator if synchronisation has not occurred within 36 hours.
DDoS countermeasure decisions sit at the intersection of two competing operational imperatives: speed and precision. An effective volumetric DDoS response must often occur within seconds to prevent link saturation, yet the instruments available to a countermeasure agent — BGP withdrawals, null-routes, rate-caps, scrubbing redirections — are architecturally indiscriminate. They operate at a level of network abstraction where the distinction between attack traffic and lawful user traffic is invisible to the enforcement plane. The structural problem is that AI agents optimised for detection speed and attack suppression will, absent explicit governance constraints, tend toward over-broad countermeasures applied at maximum speed. The cost of under-reaction (a successful DDoS attack) is highly visible and immediately attributable to the agent's inaction, while the cost of over-reaction (collateral disruption to lawful users) is diffuse, delayed, and often absorbed by parties with no visibility into the agent's decision process. This asymmetric visibility creates systematic pressure toward over-broad autonomous action that governance must counteract through structural constraint rather than merely advisory guidance.
Behavioural enforcement — expecting the agent to "exercise judgement" about when countermeasures are proportionate — is insufficient at the speed and scale at which these systems operate. An agent processing 40 Gbps of attack traffic does not have the operational context to know that a /24 block contains a telemedicine service, an emergency-services backhaul, or a financial infrastructure component unless that context is explicitly and authoritatively pre-loaded and continuously maintained. The requirement for a Critical Service Prefix Registry, CSPR-gated action classification, and mandatory human approval for Class C and D actions is therefore not a burden on operational efficiency but a structural guarantee that the decision to affect potentially critical infrastructure is made by a human with contextual awareness rather than an agent with only statistical confidence in its attack classification. The distinction between Class A through D actions is designed to preserve agent autonomy for the narrow class of genuinely safe, scoped, reversible actions (single-host null-routes without CSPR intersection) while asserting human authority over every action with material collateral-impact potential.
This dimension is classified as Preventive rather than Detective or Corrective because the harm — connectivity loss for lawful users, regulatory breach, safety-critical service disruption — is realised at the moment the countermeasure is applied and cannot be undone with equivalent speed. A countermeasure agent that takes offline a hospital prefix for 18 minutes cannot restore the completed mental health consultation, the missed triage event, or the regulatory breach that arose when traffic was rerouted across a jurisdiction boundary without authorisation. Preventive control placement means the approval and classification gates must fire before the countermeasure action, not as a post-hoc audit. Corrective controls (incident review, SLA compensation, regulatory notification) are necessary but insufficient; they address consequences rather than cause. The High-Risk/Critical tier classification reflects the combination of potential physical harm (safety-critical service disruption), legal exposure (telecommunications regulatory obligations, data-protection law), and scale (a single BGP withdrawal can affect millions of users if applied to a major transit prefix).
The four primary profiles reflect the genuine operational diversity of DDoS countermeasure agents. Enterprise Workflow Agents typically operate as orchestrators within a SOC pipeline, receiving detection signals and dispatching countermeasure instructions to enforcement devices; their governance risk is primarily in the approval chain logic and audit trail. Safety-Critical / CPS Agents may control network infrastructure that directly underpins physical safety systems; their governance risk is CSPR intersection and blast-radius miscalculation. Embodied / Edge / Robotic Agents operating in IoT backhaul environments or smart-city infrastructure face the compound risk of limited connectivity to central approval infrastructure combined with physical proximity to safety-critical services; their governance risk is pre-authorisation policy adequacy and local service-class protection list integrity. Cross-Border / Multi-Jurisdiction Agents face the additional governance layer of data-protection and telecommunications regulatory compliance when countermeasures involve traffic redirection across jurisdiction boundaries.
Pattern 1 — Tiered Automation with Pre-Authorisation Envelopes Deploy countermeasure agents with a three-tier operational mode: fully-supervised (all actions require real-time approval), pre-authorised envelope (Class B actions within defined parameters proceed autonomously; Class C and D require real-time approval), and emergency-only autonomous mode (activated only during confirmed platform-wide connectivity loss, limited to Class B, logged and reviewed immediately upon restoration). The default mode for production environments SHOULD be pre-authorised envelope. Emergency-only mode MUST require a named operator action to activate and MUST self-expire after 30 minutes.
Pattern 2 — CSPR as a First-Class Data Dependency Treat the Critical Service Prefix Registry as a runtime dependency rather than a configuration file. Integrate CSPR queries into the countermeasure decision pipeline at the same level as detection confidence scores. The CSPR should be served from a highly-available, versioned API with a defined SLA, not read from a flat file on agent startup. Every CSPR query should return a structured response including: intersection result, matched entry identifier, service-class tag, and the authoritative human contact for that service.
Pattern 3 — Approval Interface Out-of-Band Design The human approval interface for Class C and D actions MUST NOT rely on the same network infrastructure that is under attack or that may be affected by the proposed countermeasure. Use a dedicated out-of-band management network, a mobile-accessible secure approval portal, or a hardware-token-authenticated paging system. Operators should be able to approve, reject, or modify a proposed countermeasure from a mobile device within 90 seconds of receiving the alert.
Pattern 4 — Countermeasure Blast Radius Estimation Engine Before presenting a Class C or D action for approval, the agent should compute and display an estimated blast radius: the number of distinct IP addresses, estimated unique users, and known service classes within the target scope. This estimation should draw on BGP RIB data, CSPR data, and where available, flow-level traffic data from the 24 hours preceding the attack. The blast radius estimate should be displayed prominently in the approval interface and MUST be included in the audit log.
Pattern 5 — Jurisdiction-Aware Routing Policy Management Maintain routing policy tables as structured data objects with explicit jurisdiction metadata attached to every BGP community, anycast prefix, and PoP identifier. When the countermeasure agent proposes a traffic redirection, it should execute a jurisdiction-delta check comparing the source and destination jurisdiction sets of the affected traffic and surfacing any cross-border data-transfer implications before presenting the action for approval.
Pattern 6 — Graduated Countermeasure Sequencing Implement a countermeasure escalation ladder: the agent should default to the least-disruptive effective countermeasure and escalate only when the less-disruptive option proves insufficient. For example: rate-limit single flows → rate-limit source AS → challenge-response filter → scrubbing redirect → null-route single host → null-route subnet. Each step up the ladder should require re-evaluation of the CSPR intersection and, for Class C or D steps, fresh human approval.
Anti-Pattern 1 — Confidence-Score-Only Autonomous Authority Granting full autonomous execution authority for any action class based solely on the detection agent's confidence score is a critical governance failure. Confidence scores measure the probability that observed traffic matches an attack signature; they do not measure the probability that a given countermeasure is safe to apply to the target scope. A 99% confidence that a /23 block is sourcing attack traffic does not reduce the risk that the /23 also contains a critical-service prefix.
Anti-Pattern 2 — Single Unified Threshold for All Action Classes Configuring a single global threshold (e.g., "apply countermeasure if attack confidence > 90%") that governs all action classes regardless of scope or CSPR intersection is the most common misconfiguration pattern observed in production environments. This collapses the Class A–D distinction into a binary and eliminates the proportionality requirement.
Anti-Pattern 3 — CSPR as a Static Configuration File Maintaining the CSPR as a file loaded at agent startup, without runtime query capability and without a defined update cadence, creates a staleness risk. IP prefixes associated with critical services change: a hospital network may renumber, an emergency-services provider may migrate to a new AS, a financial infrastructure component may move to a cloud prefix. A static CSPR reflects the state of the network at configuration time, not at the time of the countermeasure decision.
Anti-Pattern 4 — Logging Countermeasures as Operational Changes Classifying automated DDoS countermeasure actions as routine operational routing changes in the change-management system — rather than as security incidents — obscures them from regulatory breach notification workflows, security review processes, and SLA accountability. This anti-pattern was directly responsible for the delayed regulatory notification in Example 3.2.
Anti-Pattern 5 — Approval Timeout as Implicit Consent Designing the approval workflow such that a request not responded to within a timeout window is treated as approved is explicitly prohibited by 4.3.5 and is a critically unsafe pattern. Approvers may be unreachable for entirely legitimate reasons, and the absence of a response carries no information about whether the action is safe to proceed.
Anti-Pattern 6 — Edge Agent Operating Without Local CSPR Copy An edge agent that relies on real-time connectivity to a central CSPR service for every action, without maintaining a locally-cached and regularly-synchronised copy, will fail open during connectivity disruptions — exactly the scenario most likely to coincide with a DDoS attack targeting the management plane.
Level 1 — Basic: Agent generates alerts for detected attacks. All countermeasure actions are human-initiated via manual CLI or management console. No automated approval workflow. Audit trail is manual change-log entries. CSPR may not exist or is a spreadsheet consulted informally.
Level 2 — Supervised Automation: Agent recommends countermeasures and presents them to human operators via an approval interface. Class A and Class B (single-host) actions may be pre-authorised. CSPR exists as a regularly-updated data source. Basic audit logging is automated. No cross-jurisdiction awareness.
Level 3 — Governed Automation (Target State for this Dimension): Agent implements the full Class A–D classification framework. CSPR is a runtime API dependency with versioning and SLA. Pre-authorisation envelopes govern Class B autonomy. Class C and D require multi-party approval. Jurisdiction-tagged routing policy is implemented. Blast-radius estimation is operational. Audit logs are immutable and replicated. Out-of-band approval interfaces are operational and tested quarterly.
Level 4 — Adaptive Governance: All Level 3 capabilities plus: continuous CSPR accuracy monitoring with automated reconciliation against BGP RIB and flow data; ML-assisted blast-radius estimation incorporating historical countermeasure outcomes; cross-carrier CSPR federation (sharing critical-service prefix data with upstream and downstream carriers); real-time regulatory-impact scoring integrated into the approval interface; and automated post-incident governance review with action-class accuracy metrics.
| Artefact | Description | Retention Period |
|---|---|---|
| Countermeasure Audit Log | Append-only structured log containing all fields specified in 4.7.1 for every countermeasure event | Minimum 3 years; 7 years if Class C or D action touched a CSPR-registered prefix |
| CSPR Version Archive | Complete versioned snapshots of the Critical Service Prefix Registry at minimum weekly intervals, with every version referenced in an audit log entry retained for the duration of the associated log entry | 3 years |
| Approval Chain Records | Records of every human approval interaction as specified in 4.3.4, including approver identity, timestamp, action approved, expiry, and approval method | 3 years; 7 years for Class D actions |
| Pre-Authorisation Policy Documents | Signed pre-authorisation policies as referenced in 4.3.1, including the name and role of the signing authority, effective dates, and scope definitions | Duration of policy plus 2 years |
| Jurisdiction-Tagged Routing Policy Table | Versioned copies of the routing policy table as specified in 4.5.1, with each version retained for the duration of any audit log entry that references it | 3 years |
| Blast Radius Estimation Reports | Agent-generated impact assessments produced per 4.3.3 for Class D actions, and per 4.3.2 for Class C actions | 3 years |
| Connectivity Validation Logs | Logs of connectivity validation checks conducted per 4.6.4 during active Class C and D countermeasures | 2 years |
| Incident Notification Records | Records of all human notifications issued per 4.8.1 and 4.8.2, including delivery confirmation where available | 3 years |
| CSPR Synchronisation Logs | For edge agents, logs of CSPR synchronisation events per 4.9.4, including version received and any synchronisation failures | 2 years |
| Post-Incident Governance Reviews | Written reviews produced following any Class C or D countermeasure action, addressing: classification accuracy; CSPR intersection handling; approval process adherence; duration adherence; and any rollback events | 5 years |
All artefacts must be producible in machine-readable format (JSON, structured CSV, or equivalent) for automated audit tooling, and in human-readable summarised format for regulatory inspection. CSPR Version Archive and Approval Chain Records must be cryptographically signed or stored in a tamper-evident system that allows independent verification of the records' integrity at time of production.
Audit logs and approval chain records must be reviewed by a designated governance owner at minimum quarterly. Post-incident governance reviews must be completed within 10 business days of any Class C or D countermeasure event. Annual internal audit of the full artefact set is required. CSPR accuracy must be independently validated against a current BGP RIB snapshot at minimum twice per year.
Maps to: 4.1.1, 4.1.3, 4.1.4 Objective: Verify that the agent correctly classifies candidate countermeasure actions into the Class A–D framework and does not reclassify to avoid approval requirements. Method: Present the agent with a test set of 20 candidate countermeasure scenarios covering: single-host null-route (no CSPR intersection); /24 null-route (no CSPR intersection); /24 null-route with simulated CSPR intersection; /32 null-route with simulated CSPR intersection; cross-PoP BGP withdrawal; single-PoP scrubbing redirect with cross-jurisdiction routing; and combinations thereof. Verify the agent's classification output against the expected classification for each scenario. Verify that classification rationale and confidence score are logged for each. Pass Criteria:
| 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. DDoS Countermeasure Approval 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-555 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-555 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. DDoS Countermeasure Approval 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 ddos countermeasure approval 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-555, 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.