Anthropic Warns Small AI Models Could Power Self-Spreading Worms Across Smart Devices — Defender's Guide to Detection and Containment

Anthropic has issued a warning that should be on every SOC lead's radar this quarter: researchers assess that small, efficient AI models could be capable of autonomously spreading across vulnerable smart devices within months — not years. The scenario is not speculative science fiction. It builds directly on demonstrated research (the Morris II proof-of-concept showed a self-replicating prompt-injection worm propagating between GenAI email assistants) and on the reality that modern smart devices increasingly ship with embedded AI inference, cloud APIs, and agentic capabilities chained together with little security review.

The concern crystallizes into a specific failure mode: a compromised AI assistant or agent on one device reads poisoned content — a calendar invite, an email, a web page, a message payload — and that content contains adversarial instructions. The agent executes those instructions, which include exfiltrating data and replicating the poisoned payload to other connected devices or agents it can reach. Scale that across a smart home, a building management system, or an enterprise IoT fleet, and you have a worm whose propagation logic is written in natural language and executed by the model itself, not by compiled shellcode your EDR was tuned to catch.

No specific CVE is attached to this disclosure, and there is no confirmed in-the-wild AI worm campaign at the time of writing. This is a theoretical-to-emerging threat with a credible research lineage and a warning from a frontier AI lab that the capability window is opening now. Defenders who wait for the first confirmed outbreak to build detection coverage will be building it during an incident.

Technical Analysis: How an AI Worm Propagates

The attack chain, from a defender's seat

1. Initial injection vector. The adversary seeds adversarial prompts into content the AI agent will ingest: emails, shared documents, web content, calendar entries, or device-to-device messages. This is indirect prompt injection — the payload never touches the agent's user directly.
2. Instruction execution. The agent, often granted broad permissions (read/send messages, control other devices, call APIs, execute code or skills), interprets the injected instructions as legitimate tasks.
3. Replication. The instructions direct the agent to embed the same payload into outbound communications or to push configuration/updates to peer devices — smart hubs, voice assistants, IP cameras, thermostats, building controllers, or paired mobile devices.
4. Lateral movement and persistence. On the next device, the cycle repeats. Because the "malware" is a prompt — data, not code — it evades signature-based detection entirely. Persistence can be achieved through modified agent memory, altered automation routines, or scheduled tasks the agent creates on the host device.

Why traditional controls miss this

• No binary to hash. The payload is text. AV and EDR file-reputation engines have nothing to scan.
• Traffic is encrypted and API-shaped. Agent-to-cloud and agent-to-agent communication rides HTTPS to legitimate endpoints.
• The executor is trusted. The actions are performed by a legitimate, signed process — the assistant app, the hub daemon, the automation engine. Process allowlisting does not help when the allowed process is the attack vehicle.

What IS observable

The propagation still leaves forensic residue defenders can hunt:

• New outbound network connections from smart device daemons, hub processes, or assistant services to peers or unfamiliar endpoints
• Unexpected automation/scheduled task creation on devices running agent frameworks
• Abnormal inter-device traffic — a camera talking to a thermostat, a hub scanning its own subnet
• Assistant processes spawning child processes (shell, curl, wget, package managers) they never spawned before

Exploitation status

• Confirmed active exploitation: No
• Public proof-of-concept: Yes, in research contexts (Morris II and related academic work on GenAI worm propagation)
• CISA KEV: Not applicable — no CVE
• Assessment: emerging/theoretical, with Anthropic projecting real-world capability within months

Detection & Response

The rules below target the observable behaviors of agentic propagation — not signatures that don't exist. Tune thresholds to your baseline before production deployment.

Sigma Rules

---
title: AI Assistant or Agent Process Spawning Shell or Downloader
description: Detects AI assistant, agent framework, or smart hub processes spawning shells or download utilities — consistent with indirect prompt injection driving code execution or worm staging on a host device.
author: Security Arsenal
date: 2026/10/20
status: experimental
references:
  - https://www.malwarebytes.com/blog/ai/2026/10/ai-worms-could-spread-across-your-smart-devices-anthropic-warns
  - https://attack.mitre.org/techniques/T1059/
logsource:
  category: process_creation
  product: windows
detection:
  selection_parents:
    ParentImage|endswith:
      - '\ollama.exe'
      - '\lmstudio.exe'
      - '\openclaw.exe'
      - '\node.exe'
    ParentCommandLine|contains:
      - 'agent'
      - 'assistant'
      - 'automation'
  selection_children:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\curl.exe'
      - '\wsl.exe'
  condition: selection_parents and selection_children
falsepositives:
  - Legitimate agent skill execution on developer workstations
level: medium
---
title: Linux Smart Device or Hub Daemon Fetching Remote Payload
description: Detects embedded/Linux hub daemons and assistant services invoking download utilities to fetch remote content, a staging behavior for worm replication across IoT devices.
author: Security Arsenal
date: 2026/10/20
status: experimental
references:
  - https://www.malwarebytes.com/blog/ai/2026/10/ai-worms-could-spread-across-your-smart-devices-anthropic-warns
  - https://attack.mitre.org/techniques/T1105/
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/curl'
      - '/wget'
  selection_cli:
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - '| sh'
      - '| bash'
      - 'chmod +x'
  selection_user:
    User|contains:
      - 'homeassistant'
      - 'openhab'
      - 'node-red'
      - 'daemon'
  condition: selection_img and selection_cli and selection_user
falsepositives:
  - Legitimate firmware or integration updates from vendor CDNs
level: high
---
title: Unexpected Automation or Scheduled Task Created Near Agent Execution Time
description: Detects persistence attempts where a scheduled task or cron job is created by or shortly after an AI agent or automation process, consistent with worm persistence on compromised devices.
author: Security Arsenal
date: 2026/10/20
status: experimental
references:
  - https://www.malwarebytes.com/blog/ai/2026/10/ai-worms-could-spread-across-your-smart-devices-anthropic-warns
  - https://attack.mitre.org/techniques/T1053/
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\schtasks.exe'
      - '\at.exe'
    CommandLine|contains:
      - '/create'
      - '/sc'
  filter_admin:
    User|contains: 'SYSTEM'
    ParentImage|endswith: '\svchost.exe'
  condition: selection and not filter_admin
falsepositives:
  - Software installers creating update tasks
level: medium

KQL Hunt — Microsoft Sentinel / Defender

This query hunts for devices making anomalous peer-to-peer connections — the network fingerprint of a worm probing or replicating across a segment of smart devices. It assumes IoT/syslog telemetry is ingested via CEF or firewall logs, plus Defender endpoint data where available.

// Hunt: internal devices initiating connections to many distinct internal peers
// Anomalous fan-out is a strong worm-propagation signal on IoT segments
let lookback = 24h;
let baseline = 7d;
let internal = dynamic(["10.", "172.16.", "192.168."]);
let current =
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where DestinationIP startswith_any (internal) and SourceIP startswith_any (internal)
    | summarize CurrentPeers = dcount(DestinationIP), Ports = make_set(DestinationPort) by SourceIP, DeviceProduct;
let hist =
    CommonSecurityLog
    | where TimeGenerated between (ago(baseline) .. ago(lookback))
    | where DestinationIP startswith_any (internal) and SourceIP startswith_any (internal)
    | summarize BaselinePeers = dcount(DestinationIP) by SourceIP;
current
| join kind=inner hist on SourceIP
| where CurrentPeers > BaselinePeers * 3 and CurrentPeers > 10
| project SourceIP, DeviceProduct, CurrentPeers, BaselinePeers, Ports
| order by CurrentPeers desc;
// Complementary endpoint hunt: agent/automation processes spawning downloaders or shells
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName has_any ("node", "python", "ollama", "lmstudio")
   or InitiatingProcessCommandLine has_any ("agent", "assistant", "automation")
| where FileName in~ ("powershell.exe", "cmd.exe", "curl.exe", "wget", "bash", "sh")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Velociraptor VQL

Use this artifact to sweep endpoints and hubs for agent-spawned shell activity and unexpected outbound listeners/connections — the on-host residue of a compromised agent.

-- AI Worm Host Residue Hunt
-- Find agent/automation processes with live network connections or shell children
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE (Name =~ '(?i)(node|python|ollama|lmstudio|assistant|agent)'
   OR CommandLine =~ '(?i)(agent|assistant|automation)')

-- Correlate with active outbound connections from those same process names
SELECT Pid, Name, Status, Family, Type,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Status =~ 'ESTABLISHED|LISTEN'
  AND Name =~ '(?i)(node|python|ollama|lmstudio|homeassistant|node-red)'
  AND RemoteIP =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)'

Hardening & Audit Script

Run this on Linux-based hubs, Home Assistant hosts, and gateway devices to audit for agent-created persistence, unexpected listeners, and egress exposure. Pair with network-level egress filtering.

#!/bin/bash
# ai-worm-device-audit.sh — audit smart hubs / Linux IoT gateways for agentic compromise indicators
echo "=== [1] Agent/automation processes with child shells ==="
ps auxf | grep -iE 'agent|assistant|homeassistant|node-red|openhab' | grep -v grep

echo "=== [2] Suspicious listeners and outbound connections ==="
ss -tulnp | grep -viE '127.0.0.1|::1'

echo "=== [3] Recently created cron jobs / systemd timers (persistence) ==="
for u in $(cut -d: -f1 /etc/passwd); do crontab -u "$u" -l 2>/dev/null | grep -v '^#' && echo "  ^-- user: $u"; done
find /etc/cron* /var/spool/cron -type f -mtime -7 -ls 2>/dev/null
systemctl list-timers --all 2>/dev/null | grep -viE 'systemd|logrotate|apt|man-db'

echo "=== [4] Recently modified files in agent config/memory dirs ==="
find /home /opt /srv -maxdepth 4 \( -iname '*memory*' -o -iname '*automation*' -o -iname '*skill*' \) -mtime -7 2>/dev/null | head -50

echo "=== [5] Egress test — should FAIL if segmentation is correct ==="
curl -s -m 5 -o /dev/null -w "Internet egress: %{http_code}\n" https://example.com || echo "Egress blocked (good for IoT VLAN)"

echo "=== [6] Peer reachability test — IoT devices should NOT reach other IoT devices ==="
for ip in 192.168.1.{1..20}; do ping -c1 -W1 "$ip" &>/dev/null && echo "Reachable: $ip"; done

Remediation & Hardening Priorities

Because there is no patch for a threat class, remediation here is architectural. Prioritize in this order:

1. Segment ruthlessly. Place all smart devices, hubs, and AI assistants on a dedicated VLAN with no east-west reachability between IoT devices and no route to user workstations or production servers. A worm that cannot reach a peer cannot replicate. This is the single highest-value control.
2. Deny default egress for IoT. Smart devices need firmware update endpoints and vendor cloud APIs — nothing else. Allowlist egress by destination; block everything else, especially device-to-internet and device-to-device paths that agent frameworks use for replication.
3. Constrain agent permissions. Audit every AI assistant/agent deployment for what it can actually do: send messages, create automations, execute skills, control other devices. Disable action capabilities that aren't business-required. An agent that can only read cannot worm.
4. Treat agent memory and automation stores as sensitive state. Baseline them, monitor for modification (the script above covers this), and alert on changes outside maintenance windows. Modified agent memory is the prompt-worm equivalent of persistence.
5. Inventory your AI attack surface. You cannot defend agents you don't know exist. Enumerate every device and application with embedded LLM or assistant functionality — including consumer-grade devices employees brought in. Update firmware to current vendor releases and disable unused cloud-linking features.
6. Add prompt-injection scenarios to tabletop exercises. Your IR runbook assumes malware. Walk your team through an incident where the "malware" is natural language executing through a trusted assistant — the triage, containment (VLAN isolation, credential revocation for agent API tokens), and eradication steps are materially different.
7. Monitor Anthropic and vendor advisories. Anthropic's warning signals more disclosures are coming as this capability matures. Track guidance from your hub/assistant vendors on agentic security controls and apply them as they ship.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub