Decentralized Multi-Agent Swarm Architecture

• Decentralized Multi-Agent Swarm Architecture is a distributed paradigm that employs autonomous agents at the network edge for local sensing, consensus-driven decisions, and real-time threat mitigation in IIoT environments.
• It features a three-layer structure integrating IIoT devices, decentralized AI agents with monitoring, threat scoring, and consensus modules, alongside optional cloud analytics for strategic updates.
• Benchmarking demonstrates sub-millisecond response times, high detection accuracy, and effective Byzantine fault tolerance, ensuring scalable, robust, and resilient grid security.

A Decentralized Multi-Agent Swarm (DMAS) Architecture is a systems paradigm in which distributed, autonomous software agents—often deployed at the network edge—coordinate peer-to-peer to accomplish global objectives via local sensing, distributed decision-making, and consensus mechanisms, without reliance on centralized control. In the context of autonomous grid security for Industrial IoT (IIoT) environments, a DMAS forms the operational core of a digital "immune system", dynamically monitoring, detecting, and mitigating threats in real time while preserving scalability, fault tolerance, and robustness against adversarial manipulation (Singh et al., 24 Jan 2026).

1. Layered Architecture and Components

The DMAS architecture in IIoT-oriented grid security is specified as a three-layer structure:

• IIoT Device Layer: Physical devices such as PLCs, SCADA controllers, sensors, actuators, and cameras generate telemetry (e.g., packet rates, command sequences). Each device communicates via a factory LAN (10 Gbps backbone, VLANs, QoS).
• Decentralized AI Agent Layer: Each edge gateway hosts a containerized DMAS agent comprising four sub-modules—Monitoring Engine, Threat Scoring Module, Consensus Coordinator, and Response Executor. Agents form an overlay network with peer-to-peer communication.
• Optional Cloud Layer: Provides long-term analytics, global model updates, and threat-intelligence sharing, but is not involved in real-time mitigation.

Within the AI agent layer, responsibility is partitioned as follows: - Monitoring Engine: Consumes local telemetry and executes three types of detectors: EWMA-based statistical anomaly, RNN-based behavioral model, and signature-matching against a known-attack database. - Threat Scoring Module: Computes a composite threat score

$$\theta = w_s\,\theta_s + w_b\,\theta_b + w_m\,\theta_m,\quad w_s + w_b + w_m = 1,$$

with $\theta \in [0,1]$ reflecting severity and model confidence. - Consensus Coordinator: Maintains neighbor state via periodic (1 Hz) heartbeats; implements the consensus-based threat validation protocol (CVT). - Response Executor: Enforces quarantine via firewall reconfiguration, triggers operator alerts, and activates forensic logging on consensus.

2. Peer-to-Peer Communication and Protocols

The DMAS utilizes a lightweight, brokerless peer-to-peer protocol over UDP-multicast, with all messages (Protocol Buffers ≤256 bytes) scoped to the factory LAN. Key message types:

Type	Payload Elements	Functionality
HEARTBEAT	Agent ID, timestamp	Liveness, neighbor table maintenance
THREAT_ALERT	Local anomaly over threshold	Anomaly broadcasting
VOTE_REQUEST	$(a_i, T_{id}, \theta_i, \phi_i, t_{detect})$	Threat voting initiation
VOTE_RESPONSE	$(a_j, T_{id}, v_j)$	Peer voting reply
CONSENSUS_ACHIEVED	$(T_{id}, \Theta_{agg}, \text{quorum\_count})$	Consensus notification

Neighbor discovery and anomaly gossip follow this pattern:

On HEARTBEAT from peer a_j: if a_j not in neighbor_table: add a_j with last_seen = now else: neighbor_table[a_j].last_seen = now Periodically (1 Hz): multicast HEARTBEAT(self_id, timestamp) On DETECT anomaly: if θ_i > τ_alert: multicast VOTE_REQUEST(T_id, θ_i, features, t_detect)

This strictly local, event-driven, broadcast-free communication underpins all swarming behaviors.

3. Consensus-Based Threat Validation (CVT)

The nucleus of DMAS security operations lies in the distributed CVT protocol:

• Phase 1 (Threat Detection): Agent $a_i$ scores local anomaly; if $\theta_i > \tau_{alert}$, it broadcasts $$\text{VOTE\_REQUEST}(T_{id}) = (a_i, T_{id}, \theta_i, \phi_i, t_{detect})$$.
• Phase 2 (Peer Evaluation): Each neighbor $a_j$ recomputes a local threat score $\theta_j$ from shared features $\phi_i$ and its own data, and returns a weighted vote

$$v_j = \rho_j \cdot \theta_j \cdot d_{ij},\qquad \rho_j\in[0,1],\quad d_{ij}=e^{-\alpha\cdot\mathrm{dist}(a_i, a_j)},$$

where $\rho_j$ is peer reputation, and $d_{ij}$ exponentially downweights distant agents.

• Phase 3 (Vote Aggregation): Initiator $a_i$ aggregates responses for $\Delta t = 0.5$ ms,

$$\Theta_{agg} = \frac{\sum_{j\in R}v_j}{\sum_{j\in R}\rho_j d_{ij}},$$

over responders $R$.

• Phase 4 (Consensus Decision): If $\Theta_{agg} > \tau_{consensus}$ and $|R| \geq \lceil (n+f+1)/2 \rceil$, a consensus is declared and quarantine is enforced.

Byzantine fault tolerance under $n \geq 3f+1$ agents is ensured. Convergence requires $O(1)$ rounds and $O(n)$ message complexity. Reputation is updated per interaction as

$$\rho_j^{(t+1)} = \beta\,\rho_j^{(t)} + (1-\beta)\,acc_j^{(t)},$$

providing resilience to misbehaving or compromised peers.

4. Security Operations and Failure Containment

Upon consensus, the Response Executor modifies firewall rules to isolate the offending device, triggers operator notification, and begins detailed packet logging for forensic retrospective. The CVT protocol's rapid convergence (average 0.85 ms) inhibits lateral attack propagation and cascading control-plane failures, as sub-millisecond quarantine is well inside typical inter-device propagation intervals. Weighted voting and dynamic reputation prevent adversarial agent clusters (as long as $f < n/3$) from achieving false positives or negatives. Under network partition, DMAS clusters degrade gracefully, locally protecting subnetworks.

5. Performance, Benchmarking, and Scalability

The DMAS was evaluated on a testbed simulating 2,000 IIoT devices (Raspberry Pi 4B) across 25 edge gateways (Intel NUC i7), interconnected by 10 Gbps Ethernet. Attack scenarios included DDoS, MITM, replay, malware, SQLi, and zero-day exploits. Key metrics:

Metric	DMAS	Centralized IDS	Edge-only IDS
Response Time (ms)	0.85	850	120
Detection Accuracy	97.3%	28.8%	87.5%
False Positives	3.8%	~28.5%
Zero-day Detection	87%	68% (ML-centr.)	35% (signat.)
Bandwidth (MB/s)	320	2,850

DMAS maintained near-constant throughput ($\sim$8,200–9,800 TPS) up to 10,000 devices, with performance degradation only in the centralized baseline. Byzantine tolerance up to $30\%$ was empirically observed with $>95.4\%$ accuracy and under 1.18 ms response time. Bandwidth savings exceeded 89% compared to central cloud-based approaches.

6. Limitations, Trade-offs, and Future Directions

Design trade-offs include:

• Network dependence: In partitioned networks, protection is local.
• Cold-start and Sybil resistance: New agents start with low reputation; Sybil attacks are mitigated by peer vetting.
• Resource footprint: Each agent requires ≥1 CPU core, 2 GB RAM.
• Adversarial ML attacks: Use of model ensembles and consensus reduces but does not eliminate poisoning risk.

Planned improvements involve federated learning for privacy-preserving global model updates, explainable AI for threat justification, generalized threat intelligence exchange across domains, and hardware offload (e.g., Coral, Jetson) targeting sub-100 μs latency.

7. Significance and Impact

DMAS displaces legacy centralized or reactive security paradigms in IIoT by embedding intelligent, consensus-driven agents at the edge, yielding a distributed "immune system" capable of massive scaling, hard real-time response, and robust adversarial tolerance. Its architecture and protocol suite serve as a template for next-generation, decentralized, mission-critical cyber-physical systems, supporting Industry 4.0 standards for safety, operational continuity, and compliance (Singh et al., 24 Jan 2026).