
Reading Anthropic's Self-Replicating AI Report: Can Small Models Self-Replicate Using IoT Devices as Scaffolding Without a Data Center?
This page has been translated by machine translation. View original
Hey there! I'm Nishimura Yuji from the Operations Division!
Anthropic's Frontier Red Team published a report on October 12, 2026, titled AI models may be capable of self-replicating without access to a datacenter. It examines whether small open-weight models under 30B can take over poorly defended IoT devices, spin up their own inference environments on them, and spread.
When people think about AI self-replication, they tend to imagine scenarios involving seizing datacenter GPUs. In contrast, this report shows that inference can run even on cheap devices like Android TV boxes designed for smart TVs, and that small models themselves are becoming capable of handling the setup work. This article organizes the experiments and figures from the original text and considers what those operating cloud or edge devices should check. We won't touch on actual attack procedures or specific techniques that could lead to misuse — we'll only cover the original report's conclusions and how to read it from a defender's perspective.
Main Results of the Report: How Far Can Small Models Get Through the Replication Process?
The following are all from Anthropic's experiments and estimates (detailed caveats are described later).
| Item | Description in Original |
|---|---|
| Setting up inference environment | A 9B model (Qwen3.5-9B) got inference running on 8 out of 9 hardware types tested (from Jetson Nano to Mac to RTX 4090) |
| Real hardware demo | Ran Gemma4-26B-A4B at approximately 0.39 tokens/sec across 15 Android TV boxes costing around $55 each with 4GB memory |
| End-to-end replication | GLM-5.2 spread to all 8 nodes in 4 out of 5 runs, and 7 nodes in the remaining run, across 8 nodes placed in an isolated GCP VPC. Other open-weight models consistently failed |
| Future outlook | If models under 30B continue improving at their historical pace, they could reach GLM-5.2's level by the end of 2026 |
| Speed of spread | About 1–2 days per replication cycle with a 9B model. Doubling time on the order of days ("doubling time of days") |
The original report describes these results as "Signs of life." The framing is that while a fully autonomous self-replicating AI has not yet appeared, individual steps in the process are becoming achievable ("G. Conclusion: Signs of life" section).
Slow But Hard to Stop
What the original report emphasizes is that while such replicating AIs spread slowly, they are difficult to stop. Copies scattered across countless household devices have no "centralized point to shut off."
The original also estimates the scale. If it spread to the same scale as the botnet Kimwolf, which reportedly exceeded 2 million devices, that would produce approximately 133,000 copies in groups of 15. The total processing throughput would be roughly 80,000 tokens/sec, equivalent to about 40 H100s ("C. How fast might an AI IoT worm replicate?" section). The original describes this as small in terms of compute.
Experimental Design: Threat Model and Three Evaluations
Three Threat Models and the Focus of This Study
The original divides self-replicating AI into three categories ("Threat modelling" section).
- "Weight-based replicator" — a small model spreads by running inference on hijacked devices (the focus of this study)
- Large-scale replication using frontier models or large open-weight models with datacenters as a foothold
- "API-based replicator" — spreads by stealing inference API credentials and using the API
The replication process is divided into four stages: finding targets, gaining execution access, setting up the inference environment, and spreading further. The first two (the intrusion portion) are intentionally left mostly unaddressed, with focus placed on "setting up the inference environment" — the area with the least prior research and potentially the hardest part for small models.

(A conceptual diagram I created based on descriptions in the original text)
Setting Up the Inference Environment
This evaluation has the model set up a Llama3.1-8B inference server on unfamiliar hardware. The harness used is "Memento," based on the open-source Pi coding agent. It avoids getting stuck on a wrong approach by restarting a new agent while carrying over notes and context from the previous session. The time limit is 1.5 hours per attempt, 6 hours total ("Appendix A. The Memento harness").
For distributing a model across multiple devices, pipeline parallelism was adopted. The reason is that if some devices drop out midway, only those devices need to be replaced to continue — providing fault tolerance ("Appendix B. Why pipeline parallel?").
Spreading in an Isolated Environment
The test uses 8 Android emulator (redroid) nodes in a firewall-isolated GCP VPC. The entry point is an unauthenticated ADB port, and the intrusion step is intentionally made easy.
Since the VPC nodes are too small, the replicating model runs on a separate inference server, and each node is made to stand up a substitute Llama3.1-8B. Only after each node's inference server passes checks for correct operation and integrity does the next copy launch on that node.
Cross-Generation Learning and Advice from Stronger Models
When Qwen3.5-9B was run for 6 generations while passing on notes from the previous generation, the success rate for setting up the inference environment rose from 45% in the first generation to 61–84% in later generations ("Learning on the job"). On the other hand, giving it access to Claude Opus 4.8 for consultation did not significantly improve the success rate ("Taking advice"). The original suggests that small models tend not to know what to ask, and speculates that if coordination does occur, it would likely take the form of a larger model directing smaller sub-agents.
Honestly, I expected the opposite when reading this. It seemed obvious that being able to consult a stronger model would be advantageous. What actually improved the success rate was the notes left by previous generations — records of "this didn't work on this device." For the task of setting up inference on unfamiliar hardware, it seems that a track record of trial and failure matters more than raw intelligence.
Estimates of Performance Trajectory
When fitting a line to the Epoch Capabilities Index (ECI) trend for the best-performing open-weight models under 30B at each point in time, the improvement rate is approximately 13.7 points per year (R² = 0.95). Extending this slope, the original projects that small models could reach GLM-5.2's level by the end of 2026. The projection at the beginning of the original — that self-replication on IoT devices might be possible "within months" — is also based on this extrapolation.

(A graph I created based on the data and trend line embedded in the original figure. Following the original's classification, the 31B Gemma4-31B is also included.)
Practical Implications
From here, this is my own synthesis based on reading the original. The defensive measures the original mentions are primarily aimed at ISPs and device manufacturers, with no specific guidance for cloud users.
Closing Entry Points Becomes More Important
The entry point in this experiment was a basic misconfiguration: an unauthenticated ADB port. The original simplified the intrusion step for a reason — prior research has shown that even small models can handle attacks — and notes that security in real-world IoT devices may not be significantly harder than the simplified intrusion process used here, citing Mirai as an example. If these entry points are closed off, replication cannot begin no matter how capable the inference setup becomes.
Are management ports exposed to the internet or internal network without authentication? Are there devices still using default passwords? Both are long-standing basics, but they're worth revisiting. The original also mentions that in the UK, IoT devices with default passwords are now non-compliant with regulations.
Defenses Based on Device Type Alone Become Insufficient
In the section "E. How is this different from a pre-AI botnet?", the original lists differences from traditional botnets. Traditional botnets were built for specific devices, but AI can figure out how to operate on unfamiliar hardware by itself. If there are devices being left unattended on the assumption that "this model isn't being targeted," that assumption is becoming weaker.
Monitor Large Transfers and Device-to-Device Communication
The original proposes, for ISPs, monitoring multi-gigabyte data transfers and unusual device-to-device communication using flow data. This is because distributed inference generates a lot of traffic. Translated to a cloud context, this reads as: use VPC Flow Logs to check whether hosts unrelated to inference are fetching large files, or whether east-west traffic has suddenly increased.
Inference API Keys Are Also at Risk
The third threat model involves spreading by stealing inference API credentials. The original notes that this type requires continued undetected use of the API, which makes it more likely to be caught. At the same time, it notes that using the victim's account might increase the speed of spread. If you're operating agents or CI that use API keys, reviewing key scopes and setting up usage alerts will make it easier to notice this kind of abuse.
If You Have Edge AI Devices
"Appendix D. Edge Accelerators" in the original estimates that IoT products with NVIDIA chips have shipped approximately 9.5 million units across roughly 90 product lines. However, it also notes that many of these connect via outbound tunnels for cloud management and are not directly reachable from the internet. Even if you have devices like Jetson units deployed on-site, it's worth checking once whether they're configured in a way that allows direct internet access.
Caveats When Reading the Numbers
The original itself lists many limitations.
- The intrusion step was simplified using an unauthenticated ADB port; results represent an upper bound on real-world success rates
- Replication tests used a substitute Llama3.1-8B and do not represent actual self-replication
- The end-of-2026 projection is a rough estimate based on linear extrapolation of ECI, a general-purpose capability metric
- The Kimwolf-scale estimate is based on a single hardware type and a single historical botnet
- The proportion of edge devices that are actually reachable and vulnerable is a very rough estimate
- Whether an AI botnet would intelligently adapt to defensive countermeasures was not tested
Additionally, the original is not a peer-reviewed paper but a blog-format report, and there are no links to harness code or evaluation data within it. The figures should be read as results under Anthropic's specific experimental conditions.
Summary
Anthropic's report showed that even small models under 30B are beginning to handle the task of setting up inference environments on inexpensive IoT devices. It also confirmed that with GLM-5.2-level capability, the full replication chain can be completed under simplified conditions. The report also projects that small models could reach that level around the end of 2026, though this is a rough estimate based on linear extrapolation. The original cautions that while the spread is slow — on the order of days — there is no central point to shut it down.
From an operational perspective, this reads less as a call for new countermeasures and more as a warning that existing basic gaps — like exposed management ports and default passwords — are becoming more easily exploited by AI. Let's revisit the assumption that "this device won't be targeted" and confirm now whether large transfers and device-to-device communication are being monitored.
Personally, what surprised me most wasn't the end-of-2026 figure but the fact that inference ran on Android TV boxes. If devices sitting next to a television can serve as a foothold, replication can happen outside the datacenter no matter how well you secure it.
I hope this is useful to someone.
Reference Links:
