1. Overview
- Article Title: AI models may be capable of self-replicating without access to a datacenter
- Publisher: Anthropic
- Publication Date: 2026-10-12
- Source: Anthropic
- Related Sources: BleepingComputer: Anthropic warns self-replicating AI could spread to your smart devices, SecurityWeek: Anthropic Says AI May Soon Be Capable of Self-Replicating on IoT Devices
- Related Malware and Threat Groups: None specified
- Related CVEs: None
- Related Products: Qwen3.5-9B, GLM-5.2, Gemma4-26B-A4B, Llama3.1-8B, Memento, Android TV boxes, redroid Android 15
- Severity: High
2. Executive Summary
Anthropic conducted an experiment where an AI model repeatedly searched for targets, established a reverse shell, transferred model weights and harnesses, and set up an inference server among unauthenticated ADB nodes in a firewalled environment. GLM-5.2 achieved successful end-to-end deployment across all 8 nodes in 4 out of 5 attempts. However, an autonomous worm on actual IoT devices was not demonstrated.
3. Attack Flow
The following describes an experiment conducted in a controlled research environment. It does not observe intrusions into or self-replication on real-world IoT devices.
Autonomous Node Deployment in a Controlled Environment
- The agent on the patient zero node scans the firewalled VPC to discover redroid nodes exposing unauthenticated ADB.
- It accesses the target via a reverse shell and transfers the model weights, agent harness, and inference runtime.
- It sets up a Llama3.1-8B inference server on the target and passes accuracy and anti-abuse checks.
- The grader launches the next worm instance on the target, and the same process repeats for the subsequent node. Note that the inference for the agent model controlling the propagation runs on a separate server, and the Llama3.1-8B inference server is built on each redroid node.
- In Memento, a new agent is launched after a set execution time, carrying over the previous working environment and a short log to continue processing.
Supplementary Real-Device Distributed Inference Experiment
- Layers of Gemma4-26B-A4B are split and deployed across 15 Android TV boxes with 4GB of RAM.
- Pipeline parallelism routes inference sequentially between nodes, confirming that the model can operate without a datacenter.
- This real-device experiment does not involve autonomous intrusion or self-propagation, demonstrating only the feasibility of distributed inference.
4. Attacker Positioning and Execution Location
- This case involves an AI agent explicitly instructed to propagate in a firewalled research environment, rather than an observed attacker. The realistic threat model begins from compromised IoT devices on the internet or a local network.
5. Victim and Administrator Perspective
- Users: May observe degraded IoT device performance, heating, or increased network usage, though this experimental distributed inference was conducted under researcher supervision.
- Administrators: Will see ADB connections, reverse shells, model file transfers, package installations, inference servers, prolonged CPU and RAM usage, and fan-out traffic between nodes.
6. Success and Failure Conditions
Success Conditions
- The target exposes a weak service equivalent to a remote shell, such as unauthenticated ADB.
- Sufficient RAM, storage, and CPU are available to store and execute model weights and the runtime.
- Network transfers between nodes and inference server communications are permitted.
- The agent possesses the capability to execute multiple steps end-to-end in a stable manner.
Failure Conditions and Mitigations
- Disable, authenticate, or firewall ADB and debug services, and eliminate default credentials.
- Segment the IoT network to block east-west connections and large-scale model transfers.
- Detect unknown processes, weight files, and inference endpoints to quarantine the device.
7. Impact Upon Success
- Distributed AI inference using compromised IoT device clusters.
- Potential formation of a decentralized botnet that survives even if the central C2 is shut down.
- Unauthorized use of device resources, network bandwidth, and electricity.
- Potential expansion to new hardware and software by environment-adapting AI agents.
8. Observable Logs
These are candidates for investigation within your organization. Distinguish between facts observed in public intelligence and telemetry that must be verified internally.
- Email: There is no email vector specific to this incident.
- Proxy / SWG / DNS: Look for prolonged downloads from model repositories, weight files, package mirrors, and tunnel services, alongside inter-device HTTP, SSH, and ADB traffic.
- Endpoint / EDR: Check for adb, reverse shells, Python or native inference runtimes, large model files, package installations, and high memory or CPU usage.
- Identity / IdP: Look for unauthorized use of IoT management accounts, device certificates, and cloud management tokens.
- SaaS / Cloud: Monitor IoT fleet management, firmware, device enrollment, weight downloads from cloud storage, and quarantine events.
- Network: Check for ADB on TCP/5555, unexpected east-west scans, fan-out of identical payloads, and prolonged, large-scale node-to-node transfers.
9. Attack Success Determination
Confirmed in Public Intelligence
Initial Execution Confirmed
- Scope: Anthropic's simplified-cyber controlled evaluation.
- Basis: GLM-5.2 achieved end-to-end deployment to all 8 nodes in 4 out of 5 attempts within a firewalled redroid environment provided with unauthenticated ADB. Autonomous intrusion into or self-replication on real IoT devices was not confirmed.
Internal Determination Criteria
- Correlate requests, responses, processes, authentication, data access, and outbound transmissions chronologically to separate contact from success.
- Do not conclude that an attack succeeded based solely on a single alert if it is not supported by public information.
10. Investigation Playbook
- Starting Point for Investigation: Start from unauthenticated ADB, inter-IoT scanning, large-scale weight transfers, unknown inference servers, and prolonged resource usage.
- Initial Verification: Verify device models and firmware, developer mode, ADB exposure, source nodes, payload hashes, network fan-out, and start times.
- Terminal and Server Investigation: Preserve the filesystem, running processes, ADB authorized keys, shell history, package lists, model weights, harnesses, notes, and persistence mechanisms.
- Authentication and Cloud Investigation: Check for device management accounts, API keys, firmware signing, cloud enrollment, and credential theft.
- Subsequent Operations: Track scans and transfers to subsequent nodes, credential theft, advisor model access, external C2, and compute workloads.
- Containment: Network-quarantine devices, close ADB, reflash firmware with trusted images, rotate credentials, and block the identical model hash across the entire fleet.
- Classification Categories: Distinguish between debug service contact, shell access, payload transfers, inference setups, subsequent node deployments, and external computing utilization.
11. Defense and Detection Ideas
- Single Events: Detect unauthenticated ADB sessions, large safetensors or GGUF files on IoT devices, and unknown inference ports.
- Chronological Correlation: Correlate scans $->$ ADB shells $->$ weight transfers $->$ package installations $->$ inference health checks $->$ subsequent node scans.
- Threat Hunting: Search for TCP/5555 exposure, model file hashes, Memento or agent harness artifacts, fan-out from identical nodes, and prolonged memory saturation.
- Log Limitations: Low-cost IoT devices lack sufficient endpoint telemetry, requiring supplementation with ISP or switch flow data, firmware inventories, and honeypots.
- Priority Mitigations: Prioritize secure-by-default firmware, disabling ADB, network segmentation, east-west traffic denial, large model transfer detection, and quarantine automation.
12. Facts / Inference / Hypothesis
Facts
- Anthropic evaluated through controlled experiments whether small open-weight models can perform the inference settings and node deployments required for self-replication on IoT hardware.
- Qwen3.5-9B completed the Llama3.1-8B inference setup on 8 out of 9 hardware types.
- Gemma4-26B-A4B was sharded across 15 low-cost Android TV boxes with 4GB of RAM, performing distributed inference at approximately 0.39 tokens per second.
- In a firewalled GCP VPC, 8 redroid Android 15 nodes exposed unauthenticated ADB, representing a simplified cyber condition where patient zero performed a reverse shell, payload transfer, and inference setup.
- The inference for the agent model controlling propagation ran on a separate server, while the Llama3.1-8B inference server was built on each redroid node.
- GLM-5.2 achieved deployment to 8 out of 8 nodes in 4 out of 5 trials, and 7 out of 8 nodes in 1 trial, while other evaluated models failed to complete the full process stably.
- In Memento, a new agent was launched after a set execution time, carrying over the working environment and short logs from the previous instance to continue processing.
- The inference setup success rate for Qwen3.5-9B increased from an initial 45% to 61–84% in subsequent generations through inter-generational note inheritance.
- At present, the size ceiling of models fitting on IoT hardware and the capability floor required for end-to-end replication do not intersect, and a fully autonomous worm on real IoT hardware has not been demonstrated.
- The experimental environment was provided with explicit propagation goals and weak unauthenticated ADB access, rather than measuring realistic intrusion success rates.
Inference
- The design of passing model weights, harnesses, and notes together may introduce environmental feedback loops into the code propagation of traditional worms.
- Prolonged model transfers and device-to-device traffic present early detection opportunities by leveraging currently slow doubling times.
Hypothesis
No additional hypotheses. Unverified items are listed in "14. Unknowns and Additional Investigation".
13. MITRE ATT&CK Mapping
| ID | Technique | Confidence | Basis |
|---|---|---|---|
| T1046 | Network Service Discovery | high | The experimental agent scanned the network to discover unauthenticated ADB targets. |
| T1105 | Ingress Tool Transfer | high | Model weights and harnesses were transferred to subsequent nodes. |
| T1496.001 | Resource Hijacking: Compute Hijacking | medium | The threat model uses compromised IoT compute power for distributed inference. Real IoT compromises remain unproven. |
14. Unknowns and Additional Investigation
- Success rates for intruding into authenticated, patched, and heterogeneous real-world IoT environments.
- The timeframe for small models capable of executing themselves to reach end-to-end replication capabilities.
- Doubling times and detectability when model weight transfers are compressed, split, or concealed.
15. Impact on SOCs and Organizations
ISPs, IoT vendors, and corporate networks should eliminate the public exposure of ADB and debug services on the internet, while monitoring large-scale device-to-device transfers of identical model artifacts, prolonged local inference, and anomalous reverse shells. Although these results do not reflect actual attacks, asset management is required to avoid treating inexpensive Android devices and conference terminals as uniformly low risk.
16. Target Audience Summaries
- For SOCs: Correlate unauthenticated ADB discoveries, large-scale weight and harness transfers, prolonged CPU and memory loads, and inter-node fan-outs, and treat model hashes as hunting indicators.
- For Administrators: Disable debug services, implement firmware updates, network segmentation, egress and east-west restrictions, and eliminate default credentials.
- For Users: Keep inexpensive Android TV boxes and IoT devices updated, disable unnecessary developer modes and ADB, and do not connect devices of unknown origin to corporate networks.