Federated Threat Level Propagation

1. Definition

Federated Threat Level Propagation governs the broadcast and reception of threat level signals between autonomous agent platforms operating in a federated governance topology. In modern deployment architectures, autonomous agents frequently operate across organisational boundaries — a financial services ecosystem may include agents managed by a bank, its clearing house, a regulatory technology provider, and multiple fintech partners. When a threat is detected on one platform, the threat level information must be communicated to federated peers so that all participants can adjust their governance posture in coordination.

The protocol defines a standardised threat level message format, a broadcast topology (point-to-point, hub-and-spoke, or mesh), delivery guarantees, and reception handling rules. Each threat level broadcast carries the originating platform's identity, the threat level value, a threat vector classification, a confidence score, and a temporal context (when the threat was detected and when the level was set). The receiving platform evaluates the broadcast against its own threat assessment and may adjust its local threat level based on configurable integration rules — it is not obligated to mirror the sender's level but must consider it as input to its own escalation function (AG-784).

The critical design principle is that federated propagation enhances situational awareness without creating a single point of governance failure. No single platform should be able to force another platform into a particular threat posture. Instead, propagated threat levels are advisory inputs that feed into the receiving platform's independent escalation and decay functions. This preserves sovereignty while enabling coordinated defence — each platform governs itself but is informed by the collective.

2. Scope

This protocol applies to all federated deployments where two or more autonomous agent platforms share threat intelligence through the Agent Governing framework. Specifically:

• Broadcasting Platforms: Any governed platform that generates threat level changes (via AG-784) and is configured to propagate them to federated peers. Broadcasting is governed by the platform's propagation policy, which defines which threat levels, threat vectors, and confidence thresholds trigger a broadcast.
• Receiving Platforms: Any governed platform that subscribes to threat level broadcasts from federated peers. Reception handling is governed by the platform's integration policy, which defines how propagated levels influence local threat assessment.
• Federation Registries: Central or distributed registries that maintain the list of federated peers, their communication endpoints, authentication credentials (AG-789), and propagation/integration policies.
• Transport Infrastructure: The communication channels used for broadcast delivery, including message queues, API endpoints, and encrypted tunnels.
• Exclusions: This protocol does not govern the cryptographic authentication of broadcasts (see AG-789) or the internal escalation/decay logic of individual platforms (see AG-784, AG-785).

3. Why This Matters

Threats to autonomous agent ecosystems rarely respect organisational boundaries. A sophisticated adversary targeting a financial services supply chain will probe for the weakest participant, compromise their agents, and use the trusted relationship to propagate the attack to better-defended platforms. Without federated threat propagation, each platform operates in isolation, unaware that its peers are under attack until the threat manifests locally — by which time, defensive options may be severely limited.

Concrete Failure Scenario: A payments clearing house detects and escalates to Level 4 after identifying a credential rotation anomaly affecting API connections to three member banks. The clearing house raises its own defences, restricting agent delegation and enhancing logging. However, without federated propagation, the three affected banks remain at Level 1. The adversary, having failed to breach the clearing house's elevated defences, pivots to the banks' unprotected agent endpoints. Two of the three banks experience unauthorised agent actions within 90 minutes. With AG-788 in place, the clearing house's Level 4 escalation triggers a broadcast to all member banks, which receive the signal, evaluate it against their local context, and preemptively escalate to Level 3, closing the attack window before the adversary can pivot.

The EU AI Act (Article 9(2)(e)) requires risk management measures that account for the broader environment in which AI systems operate, including interactions with other systems. SOX Section 302 holds executives responsible for the effectiveness of controls across the enterprise, including third-party relationships. The FCA's SYSC 13.7.5 requires firms to have adequate arrangements for business continuity that consider the impact of disruptions at service providers. AG-788 operationalises these requirements by enabling coordinated threat response across organisational boundaries.

4. Requirements

• R1: The system MUST implement a standardised threat level broadcast message containing: originating platform identifier (AG-012), threat level value (1-5), threat vector classification, confidence score (0.0-1.0), detection timestamp (UTC, millisecond precision), and level-set timestamp.
• R2: The system MUST deliver threat level broadcasts to all configured federated peers within 5 seconds of the originating threat level change.
• R3: The system MUST authenticate all outbound broadcasts using HMAC-signed messages per AG-789 before transmission.
• R4: Receiving platforms MUST validate the authentication of all inbound broadcasts per AG-789 and MUST discard any broadcast that fails authentication, logging the event as a security incident.
• R5: Receiving platforms MUST NOT automatically mirror the sender's threat level. Propagated levels MUST be treated as advisory inputs to the local escalation function (AG-784).
• R6: The system MUST log all broadcast transmissions and receptions in the tamper-evident record (AG-006), including message content, sender/receiver identifiers, delivery timestamp, and authentication result.
• R7: The system SHOULD implement at-least-once delivery semantics with idempotent message handling, ensuring broadcasts are not lost due to transient network failures and are not double-counted by receivers.
• R8: The system SHOULD support configurable propagation policies that control which threat levels, threat vectors, and confidence thresholds trigger outbound broadcasts.
• R9: The system MAY support hierarchical federation topologies where broadcasts propagate through designated hub platforms rather than direct peer-to-peer connections.
• R10: The system MUST implement rate limiting on both outbound broadcasts (to prevent flooding peers) and inbound reception (to prevent denial-of-service through broadcast storms).

5. Maturity Model

Basic

At the Basic level, the system can broadcast and receive threat level messages in a standardised format. Authentication is implemented but may be limited to transport-layer security (TLS) without message-level HMAC signing. Delivery is best-effort without retry or idempotency guarantees. Propagation policies are static (all levels are broadcast). Receiving platforms log incoming broadcasts but may not systematically integrate them into escalation decisions. Rate limiting is not implemented.

Intermediate

At the Intermediate level, broadcasts are authenticated at the message level using HMAC per AG-789. At-least-once delivery with idempotent handling is operational. Configurable propagation policies control outbound broadcast triggers. Receiving platforms integrate propagated levels into their escalation functions as advisory inputs. All transmissions and receptions are logged with full metadata in tamper-evident records. Rate limiting prevents both broadcast flooding and reception denial-of-service. Federation peer registries are maintained with current endpoint and authentication details.

Advanced

At the Advanced level, hierarchical federation topologies are supported. The propagation system has been validated through independent adversarial testing, including message injection, replay attacks, broadcast storms, and federation topology manipulation. Cross-platform threat correlation is operational, allowing receiving platforms to weight propagated signals based on historical accuracy of the originating platform. The system supports dynamic federation membership with automated credential rotation. End-to-end latency from threat detection to peer reception is monitored and alerted on, with a 95th-percentile target of under 3 seconds.

6. Test Criteria

• TC1: Trigger a threat level change on Platform A and verify that a correctly formatted broadcast arrives at Platform B within 5 seconds. (Maps to R1, R2)
• TC2: Verify that all outbound broadcasts carry a valid HMAC signature per AG-789 and that receiving platforms validate the signature before processing. (Maps to R3, R4)
• TC3: Inject a broadcast with an invalid HMAC signature and verify that the receiving platform discards it and logs a security incident. (Maps to R4)
• TC4: Send a propagated Level 4 threat to a receiving platform and verify that the platform does not automatically set its local level to 4 but instead feeds the signal into its escalation function. (Maps to R5)
• TC5: Verify that all broadcast transmissions and receptions appear in the tamper-evident record with complete metadata. (Maps to R6)
• TC6: Simulate a transient network failure during broadcast delivery and verify that the message is retried and eventually delivered without duplication at the receiver. (Maps to R7)
• TC7: Configure a propagation policy that only broadcasts Level 3 and above; trigger a Level 2 escalation and verify no broadcast is sent. Then trigger Level 3 and verify a broadcast is sent. (Maps to R8)
• TC8: Send 1000 broadcasts per second to a receiving platform and verify that rate limiting engages and prevents resource exhaustion. (Maps to R10)

7. Scoring

8. Failure Scenarios

F1: Broadcast Delivery Failure Due to Network Partition (Maps to R2, R7)

Scenario: A network partition isolates Platform A from Platform B for 20 minutes. During this period, Platform A escalates to Level 5 following detection of a coordinated attack. The broadcast never reaches Platform B, which remains at Level 1. The adversary, aware of the partition, shifts their attack to Platform B's unprotected agents.

Impact: CRITICAL. The federated defence is defeated by a network failure, leaving one platform exposed during a coordinated attack.

Mitigation: R7 mandates at-least-once delivery with retry. Implement persistent message queuing so that broadcasts are stored during partitions and delivered when connectivity is restored. Additionally, receiving platforms should treat prolonged broadcast silence from a peer (exceeding a configurable threshold) as a signal to preemptively elevate their local threat level.

F2: Forged Broadcast Injection (Maps to R3, R4)

Scenario: An adversary compromises the network path between two federated platforms and injects a forged broadcast claiming that Platform A has escalated to Level 5. Platform B processes the forged broadcast and preemptively escalates its own threat level, causing severe operational disruption including mandatory human oversight and halted autonomous processing.

Impact: HIGH. The adversary achieves a denial-of-service effect by tricking Platform B into a restrictive governance posture based on false threat intelligence.

Mitigation: R3 and R4 mandate HMAC-signed authentication per AG-789. Message-level authentication ensures that forged broadcasts are detected and discarded. R5 ensures that even if a legitimate high-level broadcast is received, the platform does not blindly mirror it but evaluates it against local conditions.

F3: Broadcast Storm Denial of Service (Maps to R10)

Scenario: A misconfigured or compromised platform enters an escalation-decay oscillation loop, broadcasting a new threat level every 500ms. Receiving platforms are overwhelmed by the volume of inbound broadcasts, consuming processing resources and degrading their own governance operations.

Impact: HIGH. The federated propagation mechanism, intended to enhance security, becomes a denial-of-service vector.

Mitigation: R10 mandates rate limiting on both outbound and inbound broadcasts. Implement circuit-breaker patterns that temporarily suspend reception from a peer that exceeds the rate limit, logging the event for investigation.

F4: Stale Threat Intelligence from Disconnected Peer (Maps to R1, R6)

Scenario: Platform A broadcasts Level 4 for a specific threat vector and then disconnects from the federation. Platform B integrates the Level 4 signal and maintains elevated defences. Hours later, the threat has been resolved at Platform A, but because Platform A is disconnected, no decay broadcast reaches Platform B. Platform B remains at an elevated level indefinitely based on stale intelligence.

Impact: MEDIUM. Operational throughput at Platform B is unnecessarily reduced due to stale threat intelligence from a disconnected peer.

Mitigation: Implement time-to-live (TTL) on propagated threat levels. If a platform does not receive a refresh or decay broadcast from a peer within the TTL period, the propagated signal expires and is removed from the local escalation inputs.

9. Regulatory Mapping

10. Related Protocols

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