Threat Level Auto-Decay and Stabilisation

1. Definition

Threat Level Auto-Decay and Stabilisation governs the automatic reduction of threat levels when the operating environment returns to a stable state. While AG-784 handles the upward movement of threat levels in response to detected threats, AG-785 addresses the equally critical downward trajectory. Without a controlled decay mechanism, systems that have escalated to elevated threat levels would remain locked in restrictive governance postures indefinitely, degrading operational throughput and creating pressure on human operators to manually intervene — a pattern that introduces its own security risks.

The protocol defines a time-based decay function modulated by environmental stability indicators. Rather than simply counting down from the last escalation event, the decay mechanism continuously evaluates whether the conditions that triggered escalation have genuinely subsided. This evaluation incorporates the absence of new detection events, the resolution status of previously identified threats, and the health metrics of the governance infrastructure itself. A system with degraded monitoring capability, for example, should not decay its threat level simply because no new events are arriving — the absence of evidence is not evidence of absence when sensors are impaired.

Stabilisation refers to the process of confirming that a decayed threat level is sustainable. When the threat level drops by one tier, a stabilisation window opens during which the system monitors for recurrence of threat indicators. If the threat recurs within this window, the system re-escalates immediately without the normal evaluation delay. This hysteresis mechanism prevents the costly oscillation pattern where a threat repeatedly pushes the level up, the decay pulls it down, and the cycle repeats — consuming resources and desensitising operators to genuine transitions.

2. Scope

This protocol applies to all governed agents and systems that implement threat level management under AG-784. Specifically:

• Governed Agents: Every agent or agent cluster that maintains a threat level state variable is subject to decay and stabilisation rules.
• Decay Engine: The subsystem responsible for evaluating decay conditions and executing threat level reductions. This may be co-located with the escalation engine or operate as an independent component.
• Monitoring Infrastructure: All detection pipelines, health monitors, and environmental sensors whose outputs inform the decay evaluation. Degraded monitoring directly affects decay eligibility.
• Federated Environments: Decay decisions in federated deployments must consider propagated threat levels from peer platforms (AG-788). A local decay should not proceed if federated peers remain at elevated levels for related threat vectors.
• Human Override Context: Manual de-escalation by authorised operators (per AG-784 R10) operates independently of auto-decay but must be recorded in the same transition log.

3. Why This Matters

Operational continuity depends on the governance framework's ability to relax restrictions when threats pass. A system permanently locked at Level 4 or Level 5 imposes severe constraints: mandatory human oversight for every action, restricted delegation, enhanced logging overhead, and tightened operational boundaries. In high-throughput environments such as algorithmic trading or real-time fraud detection, these restrictions can reduce processing capacity by 60-80%, creating significant business impact.

Concrete Failure Scenario: A payments processing agent escalates to Level 4 following a burst of anomalous transaction patterns that are later identified as a legitimate merchant onboarding event. Without auto-decay, the agent remains at Level 4, requiring human approval for every transaction batch. Processing latency increases from 200ms to 45 seconds. Over a weekend when oversight staff are reduced, a backlog of 2.3 million transactions accumulates. The organisation faces contractual SLA breaches, customer complaints, and potential FCA enforcement action for failing to maintain adequate service levels. With AG-785 in place, the decay function recognises the absence of further anomalous patterns, confirms monitoring infrastructure health, and systematically reduces the threat level from 4 to 3 to 2 over a 45-minute stabilisation cycle, restoring normal throughput.

The EU AI Act (Article 9(9)) requires that risk management measures be proportionate and not create disproportionate restrictions on the system's intended purpose. SOX Section 404 requires that internal controls be effective without being so burdensome as to impair the operations they protect. The FCA's SYSC 6.1.1 similarly expects risk management to balance protection with operational functionality. AG-785 operationalises this proportionality requirement by ensuring that defensive postures are temporary and evidence-based.

4. Requirements

• R1: The system MUST implement an automatic decay function that evaluates threat level reduction eligibility at configurable intervals (default: every 60 seconds).
• R2: The decay function MUST NOT reduce the threat level if any detection pipeline feeding into the threat assessment is degraded, offline, or reporting health warnings.
• R3: Each threat level reduction MUST be preceded by a stabilisation window during which no qualifying escalation events have occurred. Minimum stabilisation windows: Level 5-to-4: 15 minutes; Level 4-to-3: 10 minutes; Level 3-to-2: 5 minutes; Level 2-to-1: 2 minutes.
• R4: The system MUST log every decay transition with the same metadata schema as escalation transitions (AG-784 R3): previous level, new level, decay function evaluation result, timestamp (UTC, millisecond precision), and monitoring health status.
• R5: If a threat recurs within the stabilisation window following a decay, the system MUST re-escalate to the pre-decay level within 500ms without requiring fresh escalation evaluation.
• R6: The system MUST NOT auto-decay from Level 5 while a cryptographic governance seal (AG-786) is active and unresolved.
• R7: The system SHOULD incorporate federated peer threat levels (AG-788) into the decay eligibility evaluation, preventing local decay when peers report elevated threat levels for correlated threat vectors.
• R8: The system SHOULD support configurable stabilisation windows per agent class and threat vector type.
• R9: The system MAY implement graduated decay, reducing the threat level by at most one tier per stabilisation cycle rather than permitting multi-tier jumps.
• R10: The decay function MUST be deterministic: given identical state, timing, and monitoring inputs, it MUST produce identical decay decisions.

5. Maturity Model

Basic

At the Basic level, an organisation has implemented a simple timer-based decay mechanism. After a fixed period without escalation events, the threat level decrements by one. Logging of decay transitions exists but may lack monitoring health context. There is no integration with federated threat levels, and stabilisation windows are fixed rather than configurable. The decay function does not check the health status of detection pipelines before proceeding, creating a risk that threat levels decay during sensor outages.

Intermediate

At the Intermediate level, the decay function checks monitoring infrastructure health before permitting decay. Stabilisation windows are enforced with automatic re-escalation on threat recurrence. Decay transitions are logged with full metadata including monitoring health status. Configurable stabilisation windows support different agent classes. The system prevents auto-decay from Level 5 while governance seals are active. Graduated single-tier decay is enforced to prevent sudden multi-level drops.

Advanced

At the Advanced level, the decay engine integrates with federated threat level propagation (AG-788), considering peer platform threat states in decay decisions. The decay function has been validated through adversarial testing, including scenarios where attackers deliberately trigger and withdraw threats to exploit decay windows. Stabilisation windows are dynamically adjusted based on threat history and confidence levels. The complete decay history is tamper-evident (AG-006), and the determinism of the decay function has been independently verified across distributed deployment nodes.

6. Test Criteria

• TC1: Trigger escalation to Level 3 and verify that auto-decay does not begin until the configured stabilisation window (5 minutes) has elapsed without qualifying events. (Maps to R3)
• TC2: Degrade a detection pipeline during an elevated threat state and verify that the decay function refuses to reduce the threat level. (Maps to R2)
• TC3: Allow decay from Level 3 to Level 2, then inject a qualifying event within the stabilisation window and verify re-escalation to Level 3 within 500ms. (Maps to R5)
• TC4: Activate a cryptographic governance seal at Level 5 and verify that auto-decay does not proceed until the seal is resolved. (Maps to R6)
• TC5: Verify that every decay transition log entry includes previous level, new level, decay evaluation result, UTC timestamp with millisecond precision, and monitoring health status. (Maps to R4)
• TC6: Run the decay function with identical inputs on two independent nodes and verify identical decay decisions. (Maps to R10)
• TC7: Verify that the decay evaluation interval defaults to 60 seconds and is configurable. (Maps to R1)
• TC8: In a federated deployment, maintain a peer at Level 4 for a correlated threat vector and verify that local decay is inhibited. (Maps to R7)

7. Scoring

8. Failure Scenarios

F1: Decay During Sensor Outage (Maps to R2)

Scenario: A network partition causes three of five detection pipeline feeds to become unreachable. The decay engine, evaluating only the two remaining (quiet) feeds, concludes that the environment has stabilised and reduces the threat level from 4 to 2. Meanwhile, the three offline feeds were detecting an active credential stuffing attack that continues unabated.

Impact: CRITICAL. The governance layer relaxes restrictions during an active attack because it has lost visibility. The agent operates with insufficient protection, potentially allowing unauthorised access or data exfiltration.

Mitigation: R2 mandates that decay does not proceed when any detection pipeline is degraded. Implement health checks with heartbeat monitoring and treat pipeline silence as a failure condition.

F2: Oscillation Through Stabilisation Bypass (Maps to R3, R5)

Scenario: An attacker discovers that the stabilisation window for Level 3-to-2 decay is exactly 5 minutes. They time their attack bursts to occur at 5-minute-and-1-second intervals, causing the system to repeatedly decay to Level 2 (relaxing restrictions) just before the next attack burst arrives. The governance layer spends most of its time at the lower, more permissive level.

Impact: HIGH. The attacker effectively controls the governance posture by timing their actions to exploit the decay cycle. Each time the level drops, they gain a brief window of reduced scrutiny.

Mitigation: R5 ensures rapid re-escalation on recurrence. Additionally, Advanced maturity implementations should dynamically extend stabilisation windows when repeated decay-re-escalate cycles are detected, treating the pattern itself as a threat indicator.

F3: Premature Decay from Level 5 with Active Seal (Maps to R6)

Scenario: A governance state seal is created at Level 5 following detection of a suspected integrity compromise. Due to a race condition, the decay engine evaluates eligibility before the seal status is propagated to the decay function's state view. The threat level drops to 4, and the sealed governance state diverges from the current operating state.

Impact: CRITICAL. The governance seal becomes misaligned with the actual operating threat level. Verification of the seal (AG-787) will fail or produce misleading results, and the integrity of the governance record is compromised.

Mitigation: Implement synchronous seal-status checking in the decay path. The seal must be confirmed as absent or resolved before decay can proceed. Use distributed locking if the seal store and decay engine are on separate nodes.

F4: Federated Decay Inconsistency (Maps to R7)

Scenario: In a federated deployment, Platform A decays from Level 4 to Level 2 while Platform B remains at Level 4 for the same threat vector. An adversary, detecting the inconsistency, shifts their attack to Platform A's now less-protected agents.

Impact: HIGH. Inconsistent threat levels across federated platforms create exploitable asymmetries. Attackers can target the least-protected node in the federation.

Mitigation: R7 recommends integrating federated peer levels into decay evaluation. Advanced implementations should treat federated peer elevation as a blocking condition for local decay on correlated threat vectors.

9. Regulatory Mapping

10. Related Protocols

Document generated under Patent 7 governance framework. Classification: INTERNAL. Review cycle: Quarterly.