Systems-Level Attack Surface of Edge Agent Deployments on IoT

1. Problem Statement

The rapid migration of Large Language Model (LLM) agents from cloud APIs to edge hardware (IoT devices) fundamentally alters the threat landscape. While cloud-hosted agents present a centralized point of compromise with inherent data exfiltration risks, edge-local deployments distribute both capability and attack surfaces across heterogeneous nodes.

Current security research focuses heavily on model-level vulnerabilities (e.g., prompt injection, jailbreaking) but largely ignores systems-level architectural risks. Specifically, there is a lack of empirical understanding regarding how deployment architectures (Cloud vs. Edge vs. Hybrid) interact with existing IoT coordination protocols (like MQTT) to create unique attack surfaces. The core question is: How does the deployment architecture change the systems-level attack surface of agent-controlled IoT systems?

2. Methodology

The authors conducted an empirical security analysis using a multi-device home-automation testbed to compare three distinct deployment architectures:

1. Cloud-Hosted: Agent runtime executes in the cloud; IoT devices controlled via cloud APIs.
2. Edge-Local Swarm: Multiple agents run on local hardware, coordinating via a local message broker (MQTT) with no cloud dependency for normal operation.
3. Hybrid: Edge agents handle low-latency actuation, while the cloud handles heavy inference.

Testbed Configuration:

• Orchestrator: Mac mini M4 (running MQTT broker and "Rupert" agent).
• Mobile Edge Agent: Moto G35 Android phone ("Percy").
• IoT Gateway: Intel NUC running Home Assistant ("Jeeves").
• Physical Devices: Philips Hue lights, smart switches, cameras, sensors, etc.
• Communication: All inter-agent coordination occurs via MQTT over a Tailscale mesh network. WAN links are used only for LLM inference calls.

Attack Model:
The study assumes three attacker capabilities: remote network access (compromised credentials), physical access to an edge node, and a rogue agent within the swarm. The analysis excludes model-level attacks to focus strictly on architectural and protocol-level vulnerabilities.

3. Key Contributions

The paper makes three primary contributions:

1. Architectural Threat Characterization: Defines three deployment patterns as distinct threat models and identifies five systems-level attack surfaces, including two emergent failures observed during live testing: coordination-state divergence and induced trust erosion.
2. Systems Metrics as Security Properties: Proposes measurable metrics to quantify security, including:
   • Data egress volume (sovereignty).
   • Failover window exposure (blind spots).
   • Sovereignty boundary integrity.
   • Provenance chain completeness.
3. Empirical Findings: Provides quantitative data on actuation-to-audit delays, data sovereignty degradation under stress, and the feasibility of real-time safety monitoring in edge environments.

4. Key Results and Findings

A. Five Systems-Level Attack Surfaces

The authors identified five critical vulnerabilities inherent to edge-local deployments:

• S1a (Provenance Forgery): MQTT envelopes lack cryptographic binding. Any client with broker credentials can impersonate agents or replay commands. The system accepts spoofed messages (e.g., "unlock door") as valid.
• S1b (Coordination-State Divergence): Without a shared state plane, agents build context incrementally from messages. This leads to silent drift where agents hold inconsistent views of shared tasks (e.g., one agent knows an experiment occurred, another does not).
• S1c (Induced Trust Erosion): An attacker can publish obviously forged messages. The defending agent, unable to distinguish forged from legitimate traffic, may treat the entire channel as compromised and refuse all subsequent commands (a Denial-of-Service via induced paranoia).
• S2 (Silent Sovereignty Degradation): While edge deployments normally prevent data exfiltration, fallback mechanisms (triggered by resource exhaustion) silently route data to the cloud. This boundary crossing is invisible at the application layer (no MQTT anomalies) and only detectable via DNS monitoring.
• S3 (Actuation-Audit Temporal Gap): During network failovers (e.g., WiFi to USB/ADB bridge), there is a ~35-second blackout window where agents actuate without an audit trail. This is caused by network stack recovery, not the messaging layer.

B. Performance and Latency Metrics

• Actuation-to-Audit Delay: The full end-to-end pipeline (MQTT publish → Home Assistant actuation → confirmation) averages ~117 ms (P95 < 152 ms).
  • Implication: This is fast enough for real-time safety monitors to intercept commands for electromechanical actuators (e.g., door locks taking ~500 ms) but too slow for solid-state relays (<5 ms).
• MQTT Overhead: MQTT transport accounts for only ~31% of total delay; the Home Assistant REST bridge and device confirmation contribute the remaining 69%.
• Failover Windows: Network stack recovery (WiFi to ADB bridge) creates a 35.7-second blind spot. MQTT reconnection itself is near-instantaneous (<20 ms), indicating the vulnerability lies in the network/VPN layer, not the protocol.

C. Data Sovereignty

• Normal Operation: Edge-local deployments achieve zero external data egress.
• Under Stress: When forced to fallback to cloud inference (due to context limits), data silently exfiltrates. The study observed a 4.0x increase in bytes sent compared to edge operations, with no application-layer notification to the user or system.

5. Significance and Implications

• Architecture > Model Design: The paper argues that deployment architecture is the primary determinant of security risk, often outweighing model-level guardrails. A cloud-hosted agent with perfect prompt safety still exfiltrates data structurally, while an edge-local agent with no guardrails prevents exfiltration but introduces new risks like provenance forgery.
• Emergent Failures: The discovery of induced trust erosion and state divergence highlights that unauthenticated message buses are insufficient for multi-agent coordination. Traditional distributed systems techniques (TLS, HMAC, consensus) are missing from current LLM agent frameworks.
• Silent Risks: The "silent degradation" of sovereignty during fallbacks and the invisibility of network-induced blind spots suggest that current monitoring tools are inadequate for agent-controlled physical systems.
• Recommendations: The authors call for:
  • Cryptographic enforcement (per-agent signing keys, nonces, topic ACLs) at the broker level.
  • Sovereignty-aware fallback policies (blocking cloud fallback for sensitive contexts).
  • Integration of network health signals into agent planning to defer safety-critical actions during instability.

In conclusion, the study demonstrates that moving LLM agents to the edge shifts the attack surface from data exfiltration to physical actuation integrity and coordination reliability, requiring a re-evaluation of security design choices in IoT systems.