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.
What Anthropic tested, and what it did not
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]
The policy we want to check
A network policy is easier to reason about when it is written as allowed paths between zones. For a small environment, imagine these groups:
- iot: TVs, cameras, speakers, plugs, and other less-trusted devices.
- users: laptops and phones.
- admin: router, switch, and device-management interfaces.
- internet: approved outbound destinations, usually through a gateway.
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.
Step 1: Describe allowed flows as data
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.
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.
Step 2: Flag risky paths
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.
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.
Step 3: Add a safe test for the guardrail
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.
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.
Step 4: Turn the review into an operational change safely
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:
- Inventory devices and owners. Record the device, its network zone, who depends on it, and how to update or reset it.
- Observe before restricting. Review router or firewall logs to learn which destinations and services are actually used. Treat observed traffic as evidence to investigate, not automatic permission.
- Write the narrow policy. Name the destination and service for each necessary flow. Avoid rules like “IoT can reach LAN.”
- Stage and validate. Apply changes to one low-impact device or a test segment first. Check expected functions, DNS, updates, and management access.
- Keep a rollback path. Save the prior configuration and make sure someone can restore it without exposing the admin interface to the IoT zone.
- Plan quarantine. Decide in advance how to isolate one suspicious device without disconnecting the entire network, and where it can be sent for cleanup or replacement.
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.
What this check cannot catch
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.
A checklist to save
- Inventory: Do you know every IoT device and which zone it occupies?
- Isolation: Can a device initiate connections to laptops, management interfaces, or other devices without a documented need?
- Exceptions: Does each allowed flow name a specific destination and service?
- Observation: Have you checked real traffic before cutting access?
- Enforcement: Do the installed firewall rules match the written policy?
- Recovery: Can you isolate one device and restore service without opening the whole LAN?
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?
Top comments (0)