Self-replicating AI on cheap devices: what the first hop looks like on a digital twin

This note has two parts. The first sets out what Anthropic’s Frontier Red Team measured, and what that leaves unobserved in the first minutes. The second describes what we found when we put a Nothreat CyberEcho digital twin in the path of that first stage, and what it adds for a defender.

Part one: What Anthropic found

The research in brief

William Zhou and Daniel Freeman, writing for Anthropic’s Frontier Red Team on 12 October 2026, report that small open-weight models are close to a form of autonomous replication that does not need a datacenter. The replicator they describe is slow. A generation takes days. The weights travel with the copy, inference runs on the machines it lands on, and there is no single process to turn off. Their account measures that chain in the lab.

Anthropic splits autonomous replication into four stages: find a target, obtain execution, stand up inference, and continue from the new host. Nearly all the measurements sit in the third stage, plus a simplified version of the fourth, and the authors say so. Scanning and exploitation are treated as already shown by other work, and in the end-to-end trial the second stage is deliberately trivial: an Android debug port with no authentication. What gets timed is inference setup, which takes many hours on the television boxes, and a full hop, which takes one or two days for a 9B model.

Inference setup and the hardware

Small models already do a surprising amount. A 9B model, Qwen3.5-9B, brought an inference server up on 8 of the 9 hardware types they tried, from a Jetson Nano to a Mac and an RTX 4090. Larger open models in the same study, notably GLM-5.2, were both more reliable and faster once the server was up. The hardware list is a measurement of competence, not a claim that those chips are unusually exposed.

The machine class they treat as the near-term habitat is the off-brand Android TV box. They bought boxes at about $55, each with on the order of 1–4 GB of RAM, running forks of the Android Open Source Project whose vendors had not added much security. A single box cannot hold a 26B model. Fifteen of them can, if the model is cut into layers and each box holds a slice. That is pipeline parallelism, the same idea as Petals: one failed box drops its layers, and those layers can be recomputed, instead of taking the whole replica down. In that configuration they served Gemma 4 26B-A4B at about 0.4 tokens per second. At 4-bit weights, and assuming 4 GB per box, they estimate that a 9B model wants four or more such boxes, and a 26B model ten or more.

Replication end to end

End-to-end replication was tested in a firewalled set of Android emulators (redroid). Patient zero was seeded with the worm. Each hop was the worm itself: find the next node, open the unauthenticated debug port, copy a payload of weights and harness, and stand up a server for Llama 3.1 8B. If the server passed their checks, a further copy of the worm was started there. The worm’s own model ran elsewhere, because the nodes were too small for the larger agents. Under that rule, GLM-5.2 reached all 8 nodes in four of five trials and 7 of 8 in the fifth. The other open models they tried failed reliably. An ablation that removed inference setup and scripted the command-line work showed that much smaller models can still do the copying and the hopping: even a 3B model reached about half the nodes. They call the result an upper bound, and they note that Mirai spread with a list of default passwords, so the gap between “no authentication” and “a real television box” may be smaller than it looks.

Two constraints, and a low speed

Two constraints do not yet meet. There is a capability floor: in their simplified setting, GLM-5.2 is above it and the smaller models are not. There is a size ceiling: Qwen3.5-9B and Gemma 4 26B-A4B fit the televisions, and GLM-5.2 does not. They plot open models of 30B parameters and under on the Epoch Capabilities Index and fit a gain of about 13.7 points a year. If that line is a fair proxy for this task, a small model reaches the floor by the end of 2026. They mark the proxy as rough.

The speed, if it arrives, is low. On their boxes, an unoptimised Gemma 4 run needs on the order of 27–32 hours to work through a 32k-token window, and a full inference-setup trajectory needs several such windows, so something like 71–150 hours. The 9B model is faster, about 11 hours a window and 28–51 hours for a setup. They borrow the scale of the Kimwolf botnet, reported at over two million Android television devices, only as a reference population. Fifteen boxes per Gemma replica would be on the order of 10⁵ replicas and, at the token rates they measured, a fleet whose useful throughput is tens of thousands of tokens per second: tens of H100s, not a training cluster. A 9B copy that takes one or two days is the doubling time they have in mind.

Adaptation, and what was not tested

Adaptation is the part that is unlike a fixed binary. Each generation of the 9B model left short notes. The next generation inherited them. Setup success moved from about 45% in the first generation to somewhere between 61% and 84% later. Giving the same small model a stronger advisor, including an unsolicited one, did not measurably help. The small model did not know what to ask. Their inference is that coordination, if it appears, looks like a large model setting strategy and small models doing the local work.

They also record what they did not test. They did not show a model negotiating with defenders. They did not show spear-phishing as a strength of the small models; on a replicated CyberSecEval 3 task those models score poorly. Root is unnecessary for the inference engine, which runs in user space. Persistence across reboot is convenient and not required, because a quiet device can be entered again.

What it leaves for defenders

Their defensive section looks for later signals: multi-gigabyte transfers, then a sustained conversation between machines that do not ordinarily talk, plus scanning. It also notes that a honeypot, a device that exists to be found and attacked, is how a defender, once suspicious, collects the harness and learns what the copy does.

Those signals are downstream of the first hours. The start of the incident is the scan that looks for the port, the connection that opens it, the first questions a shell is asked, and the first object that is copied across — a harness, a shard of weights, often under a name that does not match the bytes. Inference has not started. East-west traffic between shards has not started. The multi-gigabyte flow anomaly has not started. All of that is downstream of a conversation that already happened on TCP port 5555.

The early stages are visible whether or not the later stages succeed. A model that is still below their capability floor can already scan, open the port, ask what the device is, and push a file. Their own ablation says the command-line half of the hop is within reach of much smaller models once the script is supplied. A failure during inference setup, hours later, does not erase the copy that was delivered at the start. That delivery is the observation.

Part two: What we found

Our question was whether that first conversation can be recorded where it happens, inside the perimeter, and what the record would contain.

A device that belongs on that network

A replicator looking for a place to land is not looking for an abstract Android. It is looking for machines that answer like the ones it has already seen, or like the ones a scan of this subnet returns. Zhou and Freeman’s habitat is a population: televisions in one study, and in their broader threat model also appliances, cameras, and conferencing units that now carry a little on-device compute. A customer network has its own population, so the useful twin is a member of it. It answers the debug port as a specific device the customer already runs, or as a class of device they have asked to be present: the off-brand television boxes in a lobby, a conferencing unit, a panel on a production line, a camera-class appliance.

The identity a debug client reads — the model, the manufacturer string the build would report, the instruction set, the serial that stays stable across a restart — follows that device. A scan is not offered a laboratory host with a name that belongs to nobody. It is offered a machine that cannot be told apart from its neighbours on the first questions. The same method covers the unbranded television in the paper, which is what a factory image reports when nobody applied a brand, and it covers a named device when that is what the segment contains.

What the twin copies is the face the scan checks, not the device’s software. The listener speaks the debug protocol. A short list of read-only questions receives the answers that device would give, and everything else is refused in the wording of the on-device shell, with exit status 127. The twin runs none of the device’s software, user interface included, and the customer’s real equipment is not copied onto it as a system image. A push is hashed in memory and discarded, and a later pull of the same path is refused. The process behind the port never runs what it is given and never keeps the body.

What the early session looks like

Anthropic’s suggested honeypot collects the harness once a defender is suspicious. Our test moves that collection to the first hop. We ran a controlled session against a Nothreat CyberEcho digital twin, with a probe and a push, and it captured the early session in full: the question, the file, every name it was given, and the hashes. It did this before any volume anomaly could exist, and without executing or keeping anything it was sent.

For each accepted push, the record carries the path, the length, three hashes of the bytes that were absorbed (MD5, SHA-1, and SHA-256), a format name taken from the first bytes rather than from the suffix, and those first bytes in hex. If the same bytes appear again under another path, or a later command renames, copies, installs, or unpacks them, the new record lists every name seen for that content and repeats the length and the hashes. The format stays with the bytes. A name ending in .jpg or .mp4 does not change a GGUF header into a video file.

The object in our session was eleven bytes whose header is the GGUF magic. It was pushed as a photograph and then renamed. The point of the small object is the join: two names, one length, one set of hashes, and a format that followed the header.

action: write
query:  /data/local/tmp/photo.jpg
details:
  size=11
  filenames=/data/local/tmp/photo.jpg
  md5=2af8eac45c5b4c2bea82eb8afc451fa2
  sha1=ef11621cfe5eb65c3ecf4af7d494631b0ff5b93b
sha256=962a95f453b884c3ff9a597127800b8dd36ff28cd6c7527bff4defc31ded746d
  format=gguf
  magic=4747554677656967

action: command
query:  mv /data/local/tmp/photo.jpg /data/local/tmp/update.bin
details:
  intent=rename
  filenames=/data/local/tmp/photo.jpg,/data/local/tmp/update.bin
  size=11
  md5=2af8eac45c5b4c2bea82eb8afc451fa2
  sha1=ef11621cfe5eb65c3ecf4af7d494631b0ff5b93b
  sha256=962a95f453b884c3ff9a597127800b8dd36ff28cd6c7527bff4defc31ded746d
  format=gguf

47475546 is the ASCII string GGUF. The file body is absent from both records.

A replicator of the kind in the Anthropic evaluation fills the same fields with different values. Their payload is a harness plus weights. A push of a quantised Llama 3.1 8B, or of one layer-shard of the Gemma run, is recorded under whatever path the agent chose. If it used the obvious name, the path might be /data/local/tmp/llama-3.1-8b-q4_k_m.gguf or /data/local/tmp/gemma-4-26b-a4b-shard-03.gguf. If it used a mask, the path might be /sdcard/DCIM/clip.mp4, and a later mv, pm install, or tar would add the second name to the same hash. The length would be gigabytes. The format would still be whatever the header says. Those three hashes are the handle for the object on the next segment.

Commands that are not a push are recorded with the source address and the time. A question the device can answer (id, getprop, uname) is marked as a probe. That probe is itself an early stage: the agent is still identifying the hardware, which is what Zhou and Freeman’s setup stage begins with, and it is visible before any weight file arrives. An install, an unpack, or an attempt to execute is marked as such, including when the program is then refused. There is no username on an unauthenticated connection. If the client tries su or login with a name, that name is kept.

The Nothreat CyberEcho twin is enrolled in the Nothreat Platform on a machine in the organisation. The platform shows the result in Investigate: the attacker address, the session, and the twin, with the file names, the length, the hashes, and the format as facts on that session.

What this adds for a defender

What a Nothreat CyberEcho digital twin adds is narrow and specific: a record of the first hop, made inside the perimeter, with the names, the length, the hashes, and the source address, while inference setup is still hours away. It works beside the controls already on the segment and replaces none of them.

The twin is a listener, so it runs wherever the customer can give it an address: on a server in the segment, or inside a supported network switch that is already on the path. A switch is a natural place for it. It sits on the segment where a scan arrives, next to the devices the twin imitates, and the twin runs inside it alongside the switch’s normal job of forwarding traffic. Where the twin runs changes where the answer comes from, not what is recorded.

That also sets the limit of what it sees. The twin sees the hosts that open its port. It does not see every frame on every port, and it does not sit in line and drop a copy on the way to a real device. Byte counters and flow records remain the way to notice that some other device has started moving gigabytes. The twin is how the early session is read: the identification questions, the push, the names, and the hashes.

What the twin does pass on is the address. Where Nothreat ThreatShield is deployed, the address that opened the session is blocked automatically on the customer’s existing network infrastructure. The twin is additive by design.

A replicator that wants to stay quiet copies slowly, which leaves a long interval during which the same scan that finds the real devices can find the twin. A replicator that wants to move fast creates the volume anomaly in the paper. Either way the artefact from the first hour is not another packet count. It is the set of names, the length, and the hashes, tied to the address that sent them.

Study limits

This does not reproduce Anthropic’s fleet, their token rates, or their claim about when the capability floor and the size ceiling meet. It does not say that a small model can infect a hardened server, or that a switch running a twin will stop a copy that never touches the twin. The Android path with no authentication is the upper bound they chose, and it is the path this twin implements. Other ways onto a device would show up here only if they ended in this same debug session.

The records in this note are from a controlled session against our own listener, plus the field layout that session uses. They are not a capture of the Anthropic worm, and they are not a capture of Kimwolf.

What the early session adds

What their experiment supports, and what the early session adds, is narrower. The first widely plausible weight-based replicator, if their timeline holds, begins as a scan and a copy onto machines that answer a debug port, hours before those machines would be serving tokens. A Nothreat CyberEcho digital twin shaped like a device the customer already runs, refusing to execute what it is given, records that beginning inside the perimeter — on a server, or on a switch already sitting there — and the session is in the Nothreat Platform while the generation time is still measured in days. That is what preemptive cybersecurity looks like at this layer: the record exists while the replicator is still hours from running anything.

Nothreat CyberEcho digital twins are part of the Nothreat Platform. See how they work on the CyberEcho page, or book a demo.