Anthropic's recent research raises a critical question: could small AI models create self-replicating infections on IoT devices like Mirai did with DDoS code? While the answer is "not end-to-end" for now, the steps are becoming easier for small models, and the weights can travel as part of the payload.
This checklist is for model risk managers overseeing AI deployments on edge or IoT hardware. It turns a speculative threat into actionable items your team can address. It doesn't assume the worm exists today but that your governance framework should already consider it.
Prerequisites
Before you begin, ensure you have:
- An inventory of AI models and agents, including those on edge devices.
- A designated owner for AI security risk (beyond IT security).
- Access to your IoT asset register, or acknowledgment that none exists.
- A current risk taxonomy you can extend (ISO/IEC 23894, NIST AI RMF, or your SR 11-7 aligned framework).
The Checklist
1. Add self-replicating AI misuse to your risk taxonomy. Create a risk entry for AI-enabled autonomous propagation. Anthropic describes the replication flow in four stages: finding targets, gaining code execution, establishing inference, and propagating to new hosts. Map each stage to a control objective. Done when: the risk is in your register with an owner, stage-by-stage description, and linked controls. Good looks like: a reviewer can trace each propagation stage to at least one preventive or detective control.
2. Inventory every device that can host inference. The threat model relies on compromised hardware running a model locally. Identify which devices have enough compute, storage, and network access to run even a small model. Done when: your asset register flags inference-capable devices, including those not bought for AI purposes. Good looks like: the list includes unmanaged and shadow devices, with a known gap rate you're working to close.
3. Treat model weights as a potential payload in your threat model. In the research, weights become part of the malware, either carried along or re-downloaded from a public hub. Add this to your adversarial scenarios using MITRE ATLAS and NIST AI 100-2 as reference taxonomies. Done when: your threat model includes "weights as payload" and "weights retrieved from public hub" as distinct scenarios. Good looks like: each scenario has a documented detection hypothesis, even if the detection isn't built yet.
4. Restrict outbound access to public model hubs from edge segments. A device that can't fetch weights can't easily stand up inference. Apply egress filtering from IoT network segments to known model repositories. Done when: egress rules are in place, tested, and reviewed on a defined cycle. Good looks like: exceptions are approved, logged, and expire automatically.
5. Segment IoT networks from systems that hold sensitive models or data. Propagation requires reachable neighbors. Limit lateral movement so one compromised device can't enumerate the rest. Done when: segmentation is verified by test, not just by diagram. Good looks like: a penetration test shows a compromised device cannot discover peers outside its segment.
6. Establish baselines for compute and memory on edge devices. Local inference is resource-heavy. In the research, a 26B-parameter model distributed across 15 devices ran at 0.39 tokens per second, making it slow but conspicuous. Abnormal sustained CPU, memory, or storage use is a detection signal. Done when: baselines exist per device class, and deviations generate alerts. Good looks like: alert thresholds are tuned against real data, and someone triages them.
7. Monitor for unexpected inference runtimes and large file writes. Setting up inference means installing compatible software and dependencies. Watch for new runtimes, package installs, and multi-gigabyte weight files on devices that shouldn't have them. Done when: endpoint or network telemetry covers these events. Good looks like: a staged test, such as dropping a benign model file on a lab device, triggers an alert.
8. Log and review agent tool access, including reverse shell capability. The research agents had access to common exploitation tools. If your agents have shell, network scanning, or code execution tools, scope those permissions tightly. Done when: every deployed agent has a documented tool allowlist. Good looks like: permissions follow least privilege, and changes go through change control.
9. Include Red Teaming of autonomous agents in model validation. Extend validation beyond accuracy and bias. Test whether your agents can be steered into scanning, exploiting, or propagating. Retain the Validation Evidence. Done when: Red Teaming results are filed with each agent's validation record. Good looks like: findings have remediation owners and retest dates.
10. Define misuse prevention policy for models you build or distribute. If you release weights or fine-tunes, your AI Management System (ISO/IEC 42001) should address foreseeable misuse. ISO/IEC 38507 provides board-level framing on governance implications. Done when: a written policy covers release decisions, usage restrictions, and escalation. Good looks like: release approvals reference a misuse assessment.
11. Add AI worm scenarios to incident response playbooks. Anthropic notes that once an infection chain begins, it may be harder to stop because agents can adapt. Your playbook should cover isolation speed, weight artifact collection, and shared-notes artifacts the worm might leave for later replicators. Done when: a tabletop exercise has run against the scenario. Good looks like: the exercise produced concrete changes to the playbook.
12. Reassess the threat on a fixed cadence. Current limits are real: none of the lightweight models tested achieved end-to-end replication, and setup took 29 to 51 hours for Qwen3.5-9B and 71 to 150 hours for an unoptimized Gemma4-26B-A4B. But the researchers said the larger GLM-5.2 appears able to do it reliably. Capability moves; your assessment should too. Done when: a review is scheduled with defined triggers, such as a new small model matching prior large-model performance. Good looks like: each review records what changed and what you decided.
Common Mistakes
- Treating slow as safe. Long setup times lower the odds today. They don't remove the risk and say nothing about optimized implementations.
- Scoping AI risk to models you own. The relevant models may be ones an attacker downloads.
- Leaving IoT out of model inventories. If the device isn't in the register, no control applies to it.
- Relying on a single detection signal. Resource anomalies, egress logs, and file telemetry work better together.
- Assuming the threat is purely a security-team problem. Model risk owns validation and misuse assessment.
Next Steps
Start with items 1 and 2; they cost little and expose the most. Then run item 11 as a tabletop exercise, because it will show which controls are missing. Finally, schedule item 12 now, with explicit triggers, so the reassessment happens when capabilities shift rather than after an incident.
