An AI Worm Is Not Here Yet. Build the Network Boundary That Would Slow One Down

A developer published an offline Python policy checker that maps allowed flows between network zones, aimed at limiting what a compromised IoT device can reach before rules are translated into router or firewall configuration. The tutorial cites Anthropic Frontier Red Team's October 12, 2026 research post, which described controlled experiments in which 15 Android TV boxes costing about $55 each jointly ran a 26-billion-parameter model at 0.39 tokens per second, and a simplified replication chain completed by GLM-5.2 in a firewalled fleet of eight emulators with an unauthenticated ADB port. Anthropic said the work does not report a real-world self-replicating worm and represents an upper bound on success rather than a live campaign.

A compromised smart TV should not be able to open a connection to your laptop, your password manager, or the admin page for your router. Yet many home and small-office networks put all three behind the same flat local network. One weak device can then see far more than it needs. That old problem is getting a new reason to revisit it. In an October 12, 2026 research post, Anthropic's Frontier Red Team described experiments with small models and inexpensive internet-connected devices. The headline risk is an AI-assisted worm that could adapt to unfamiliar hardware and spread without a data center. But the post does not report a real-world self-replicating worm in circulation. It reports controlled experiments and a forecast about what may become possible. 1 The most useful engineering response is not to debate a headline. It is to reduce what one compromised device can reach. This tutorial builds a small, offline Python checker for a network policy. It identifies paths from an IoT device group to sensitive network zones before you translate those rules into your router, firewall, or managed network controller. The checker does not scan devices, contact a network, or change firewall rules. It is a review aid, not a substitute for a correctly configured firewall or an incident-response plan. Anthropic demonstrated that 15 inexpensive Android TV boxes, each costing about $55, could jointly run a 26-billion-parameter model at 0.39 tokens per second. That is a distributed-inference demonstration, not evidence that the boxes were infected or autonomously spreading malware. 1 The researchers separately tested a simplified replication chain in a firewalled fleet of eight Android emulators. The test environment used an unauthenticated ADB port, which made the initial access step deliberately trivial. GLM-5.2 completed the end-to-end sequence in their evaluation; Anthropic says the setup represents an upper bound on success in real environments, not a measurement of a live campaign. 1 The distinction matters. The research does not establish that a worm is spreading through consumer devices today. Anthropic says the tested models still face a gap between fitting on low-cost hardware and reliably completing the entire replication chain. Its estimate that this gap could close is a projection based on capability trends, not a demonstrated deployment. 1 Still, one defensive point does not depend on the AI prediction: network access determines how much damage a compromised device can do. Anthropic's proposed mitigations include quarantine and limiting infected devices to a short allowlist of destinations. NIST's IoT network-layer guidance likewise focuses on verifying devices before granting network credentials and managing their allowed posture over time. 1 2 A network policy is easier to reason about when it is written as allowed paths between zones. For a small environment, imagine these groups: A conservative starting policy might allow IoT devices to reach only the internet through DNS and HTTPS, plus a specifically required local service such as a home-automation broker. It should not allow IoT devices to initiate connections to user or admin devices, and it should not allow IoT devices to communicate freely with one another. This is not a universal port list. A camera, media device, or smart-home hub may need a documented exception. The important practice is to make each exception explicit, scoped, and reviewed rather than leaving the entire local network reachable by default. Create policy check.py . This first version stores allowed flows in a list. Each entry says which source zone may initiate a connection to which destination zone and service. python from dataclasses import dataclass @dataclass frozen=True class Flow: source: str destination: str service: str ZONES = {"iot", "users", "admin", "internet", "automation"} ALLOWED = { Flow "iot", "internet", "dns" , Flow "iot", "internet", "https" , Flow "iot", "automation", "mqtt" , Flow "users", "internet", "https" , Flow "users", "automation", "https" , Flow "admin", "iot", "management" , Flow "admin", "users", "management" , } Think about direction. admin → iot allows an administrator to manage an IoT device. It does not imply iot → admin is allowed. Stateful firewalls normally permit return traffic for an established connection, but that is different from allowing the device to start a new connection toward the admin zone. The service value here is a readable label, not a real protocol/port mapping. Before implementation, replace each label with the exact protocol, destination, and port your equipment requires. Do not treat “HTTPS” as safe merely because it uses a familiar port; the destination and the device's need for access matter too. Add rules that should always trigger review. For example, a broad IoT-to-admin or IoT-to-user path is suspicious. Any unknown zone should fail validation instead of being silently accepted. php SENSITIVE DESTINATIONS = {"users", "admin"} def review flow: Flow - list str : problems = if flow.source not in ZONES: problems.append f"unknown source zone: {flow.source}" if flow.destination not in ZONES: problems.append f"unknown destination zone: {flow.destination}" if flow.source == "iot" and flow.destination in SENSITIVE DESTINATIONS: problems.append f"IoT devices can initiate {flow.service} connections to {flow.destination}" if flow.source == "iot" and flow.destination == "iot": problems.append "IoT devices can initiate connections to other IoT devices" return problems def main - int: failures = 0 for flow in sorted ALLOWED, key=lambda f: f.source, f.destination, f.service : problems = review flow if problems: failures += len problems for problem in problems: print f"REVIEW: {problem}" else: print f"OK: {flow.source} - {flow.destination} {flow.service} " print f"Checked {len ALLOWED } flows; {failures} review item s ." return 1 if failures else 0 if name == " main ": raise SystemExit main Run it with python3 policy check.py . The sample policy should produce seven OK lines and a zero review count. To confirm the check catches a dangerous rule, temporarily add Flow "iot", "admin", "management" to ALLOWED . The script should print a REVIEW finding and exit with status 1. That is a useful property for a review tool: it gives a reproducible, testable answer about the policy you supplied. It does not prove that your actual router enforces the policy. You still need to compare this inventory with the rules installed on the real network. A policy checker should have a test for the exact case it is meant to catch. Add this test below the definitions, or save it separately as test policy.py and import Flow and review from the checker module. python def test iot cannot start admin connection : flow = Flow "iot", "admin", "management" assert "IoT devices can initiate management connections to admin" in review flow def test iot can reach approved dns : flow = Flow "iot", "internet", "dns" assert review flow == def test unknown zone fails closed : flow = Flow "guest-iot", "internet", "https" problems = review flow assert "unknown source zone: guest-iot" in problems These tests are intentionally local. They do not probe a router or attempt to discover devices. You can run them with python3 -m pytest if pytest is already installed; otherwise, use Python's built-in unittest or add a small test runner. Don't install a new dependency on a production firewall host just to run this example. A deny-by-default policy can break devices in surprising ways. Some products discover hubs with multicast, depend on a local DNS resolver, or contact vendor services to update firmware. Removing every flow without inventory can create outages and tempt someone to restore broad access. Use the checker as a preparation step: NIST's SP 1800-36 describes onboarding controls that verify device and network identity before a device receives network credentials, and lifecycle mechanisms that can check device posture before allowing operations. 2 Not every home router implements those capabilities. For home networks, a separate guest or IoT SSID with client isolation and a firewall between it and the main LAN may be the practical starting point. Verify the exact features in your router documentation; SSID separation alone does not guarantee isolation. This script checks only the flows you put in its ALLOWED set. It cannot detect a missing device, an incorrect zone assignment, a router rule that differs from the written policy, a compromised trusted device, or malicious traffic hidden inside an allowed connection. It also does not inspect model execution, firmware integrity, or cloud accounts. Network segmentation is one layer, not a complete defense. Keep devices updated where updates exist, replace products that no longer receive security fixes when feasible, disable services you do not use, change default credentials, and avoid exposing management interfaces to the public internet. For organizational fleets, use managed controls that can verify device identity and enforce lifecycle policy rather than relying on a spreadsheet and a script. The threat model will keep changing. A model may help malware adapt, but the network still decides which systems it can contact. Restricting unnecessary paths is useful against ordinary malware too, and it makes a future fast-moving threat less able to turn one weak device into a route through everything else. The Anthropic research is a reason to check the boundary, not evidence that an AI worm is already spreading through homes. Start with the network paths you control, and test that your intended policy rejects the connections you do not want. I write about practical AI engineering and software security. Subscribe if you want more buildable guides like this. What would be hardest to isolate on your network: a smart TV, camera, or home-automation hub?