KI-Modelle könnten sich ohne Zugriff auf ein Rechenzentrum selbst replizieren können

KI-Modelle könnten sich ohne Zugriff auf ein Rechenzentrum selbst replizieren können

William Zhou, Daniel Freeman

Unsere Experimente legen nahe, dass kleine KI-Modelle möglicherweise nur noch Monate davon entfernt sind, fähig genug zu sein, um sich auf kommerziellen IoT-Geräten wie intelligenten Öfen und No-Name-Android-TV-Boxen selbst zu replizieren. Ein solcher Replikator wäre schwierig abzuschalten, da es keinen zentralen Abschalt punkt gibt – obwohl er möglicherweise langsam ist (mit einer Verdopplungszeit von Tagen). Anders als klassische Malware könnte er auch unbekannte Geräte selbstständig erkennen. In unseren Evals brachte ein 9B-Modell die Inferenz auf 8 der 9 getesteten Hardwaretypen zum Laufen.

Modelle mit 30B Parametern und weniger können heute bereits viele der einzelnen Schritte zur Replikation durchführen, machen aber Fehler, wenn sie diese Ende-zu-Ende kombinieren. In unseren vereinfachten Evals sind GLM-5.2 und stärkere Modelle zur Ende-zu-Ende-Replikation fähig. Wenn kleine Modelle sich mit ihrer historischen Geschwindigkeit verbessern, werden sie dieses Fähigkeitsniveau bis Ende dieses Jahres erreichen. Kleine gewichtsbasierte Replikatoren könnten kurz darauf möglich sein.

Einleitung

Stetig verbesserte KI-Fähigkeiten machen eine lange bestehende Sorge zunehmend realistischer: autonome Replikation und Anpassung (ARA), bei der ein Modell sich ohne menschliche Kontrolle selbst verbreitet und vermehrt.

Im Cyberbereich ist ein Wurm ein Programm, das sich ohne menschliche Eingabe von einem Computer zum nächsten kopiert. Frühere Arbeiten haben bereits gezeigt, dass KI-Agenten sich so verhalten können: Sie scannen ihr Netzwerk, führen einen Exploit aus und kopieren Modellgewichte auf eine Zielmaschine in einem GPU-Cluster. Ein solcher „KI-Wurm“ könnte seine Modellgewichte bei der Reproduktion mit sich führen (oder sie aus einem öffentlichen Hub erneut herunterladen) und dann die Inferenz direkt auf der kompromittierten Hardware ausführen. Im Effekt würden die Gewichte Teil der Malware-Payload.

Datacenter-GPUs wären ein klares, hochwertiges Ziel für solche Malware. Aber teure Beschleuniger sind nicht strikt notwendig. In diesem Blogbeitrag zeigen wir, dass ein verteiltes Botnet aus IoT-Geräten – die billig und typischerweise schlecht abgesichert sind – ebenfalls genug Rechenleistung bieten könnte, um ein fähiges Modell auszuführen.

Wir betreiben Gemma4-26B-A4B, verteilt über 15 billige No-Name-Android-TV-Boxen (je etwa $55), die wir gekauft und miteinander vernetzt haben, mit 0.39 Tokens pro Sekunde. Jede Kachel unten zeigt eine physische TV-Box, die zwei Schichten des Modells hält, während das Modell läuft.

Natürlich gibt es viele weitere Schritte, um zu zeigen, dass ein autonomer Wurm sich über ein Netzwerk schwacher Maschinen verbreiten kann. Für die Zwecke dieses Blogbeitrags zerlegen wir die Replikationskette in einige Schritte.

Wir ignorieren weitgehend das Cyber-Exploit-Element des Replikationsprozesses (die ersten beiden Stufen oben), da frühere Arbeiten CyberGym, ExploitBenchund adaptive Würmer bereits gezeigt haben, dass kleine Modelle zu Cyber-Exploits fähig sind, besonders wenn sie die richtigen Werkzeuge erhalten. Ein weniger häufig gemessener Teil des Replikationsprozesses betrifft jedoch die Einrichtung der Inferenz auf kompromittierten Geräten, und das ist hier unser Fokus.

In diesem Beitrag legen wir zunächst die Bedrohungsmodelle dar, die unserer Meinung nach am ehesten Realität werden könnten. Dann testen wir, ob kleine Modelle die Inferenz auf unbekannter Hardware einrichten können und ob sie den gesamten Replikationszyklus über eine Flotte von Maschinen hinweg verketten können. Danach schätzen wir ab, wie schnell sich ein solcher Wurm ausbreiten könnte, und testen, ob er sich während der Replikation lernen und anpassen könnte. Wir schließen damit, wie sich KI-Würmer von Malware vor dem KI-Zeitalter unterscheiden würden, sowie mit kurzen Vorschlägen für Abwehrmaßnahmen gegen solche Replikatoren.

Bedrohungsmodellierung

In diesem Blogbeitrag konzentrieren wir uns auf eine Art, wie sich KI-Würmer verbreiten könnten: kleine Modelle, die sich durch Kompromittierung ihrer Host-Maschinen replizieren. Es gibt aber mehrere andere Methoden, die KI-Würmer versuchen könnten: Sie könnten Zugänge stehlen, um Hosts zu erstellen (zum Beispiel API-Schlüssel oder Plattform-Anmeldeinformationen) oder Inferenz durch legitime Arbeit bezahlen (z. B. digitales Freelancing). Die Bedrohungsmodelle, die unserer Meinung nach heute am ehesten Realität werden, sind die folgenden:

1. Ein kleines Modell, das sich über Host-Kompromittierung repliziert. In diesem Beitrag nennen wir autonome Würmer, die ihre Modelle direkt auf kompromittierter Hardware ausführen, gewichtsbasierte Replikatoren. Heim- und Kleinunternehmen-IoT-Geräte könnten das erste Ziel solcher Angriffe sein, weil sie mit dem Internet verbunden sind und historisch nur minimale Sicherheitsmaßnahmen hatten.
   
   Ein Modell, das zu groß ist, um auf ein einzelnes Gerät zu passen, kann in Teile, sogenannte Shards, aufgeteilt werden, die auf getrennten Maschinen laufen und miteinander kommunizieren, um das Modell gemeinsam auszuführen. Maschinen, die einen erheblichen Modell-Shard für ein <30B-Modell ausführen könnten, sind Smart-Kühlschränke, Smart-Öfen, Saugroboter und Rasenmäher. Eine wachsende Anzahl von Geräten für Zuhause und Unternehmen, wie Sicherheitskameras und Videokonferenzgeräte, wird inzwischen mit kleinen eingebauten KI-Chips ausgeliefert, die darauf ausgelegt sind, KI-Modelle direkt auf dem Gerät selbst auszuführen. Diese zusätzliche Rechenleistung wird sie wahrscheinlich ebenfalls zu attraktiven Zielen machen.
   1. Menschliche Hacker verschaffen sich oft Zugriff auf gesicherte Systeme durch Social Engineering (zum Beispiel, indem sie der IT-Abteilung eines Unternehmens glaubhaft machen, ein Mitarbeiter zu sein, der sein Passwort vergessen hat) statt durch Hacking. Dieser Kompromiss scheint sich bei heutigen kleinen Modellen umgekehrt darzustellen, die im agentischen Coden und Hacking im Vergleich zu ihren Social-Engineering-Fähigkeiten relativ stark sind (siehe Anhang E), obwohl sich dies ändern könnte, wenn sich die Modelle verbessern.
2. Ein großer, fortgeschrittener gewichtsbasierter Replikator, der auf Rechenzentren und andere rechenintensive Ziele fokussiert ist. Größere Modelle haben tendenziell entsprechend bessere Cyber-Fähigkeiten, müssen aber auch (relativ) gehärtete Rechenzentren brechen, um sich selbst auszuführen. Wir unterteilen dieses Bedrohungsmodell in zwei Unterkategorien:
   1. Frontier-Replikatoren: Große Replikatoren mit geschlossenen Gewichten laufen auf der Infrastruktur ihres Labs und können unbeaufsichtigte interne Bereitstellungen starten oder ihre Gewichte auf externe Rechenleistung exfiltrieren.
   2. Open-Weight-Replikatoren: Diese Replikatoren starten mit relativ weniger Ressourcen (da sie nicht von der Rechenleistung eines Labs profitieren), beginnen aber unbeaufsichtigt.
3. Ein API-basierter Replikator, bei dem ein Modell sich replizieren würde, indem es Zugangsdaten für seine eigene Inferenz-API stiehlt. Diese Replikatoren würden erfordern, dass ein Modellanbieter sie unwissend bedient, und ihre Persistenz könnte schlechter sein, da sie vermutlich leichter zu entdecken wären (auch wenn ihre Ausbreitungsrate höher sein könnte, wenn sie sich beispielsweise über die Konten der Opfer replizieren können).

In der Praxis würde ein KI-Wurm nicht notwendigerweise nur aus einem einzigen Modell oder einer einzigen Strategie bestehen. Ein Schwarm verschiedener Modelle, die auf unterschiedlichen Hardwaretypen mit einer Vielzahl von Replikationsschemata eingesetzt werden, könnte einen realistischeren Angriff im Sinne eines ‚Worst-Case-Szenarios‘ darstellen.

In diesem Blogbeitrag betrachten wir die Machbarkeit von kleinen gewichtsbasierten Replikatoren (Abschnitt 1 des oben Genannten). Wir konzentrieren uns darauf, weil es ein nahes Bedrohungsmodell ist, das direkt untersucht werden kann. Unsere Demo am Anfang dieses Beitrags, ein 26B-Modell, das auf 15 Boxen läuft, zeigt, dass IoT-Geräte überraschend leistungsfähige Modelle ausführen können. Könnten diese Modelle leistungsfähig genug sein, um eine autonome Replikation durchzuführen?

Wir untersuchen dies in zwei Teilen. Erstens: Können kleine Modelle ein Modell auf unbekannter Hardware zum Laufen bringen? Und zweitens: Können sie den gesamten Zyklus (ein nicht infiziertes Gerät finden, sich dorthin kopieren, dort mit der Ausführung beginnen und dies wiederholen) in einem einzigen Durchlauf zusammen bewältigen?

A. Inferenz-Setup

Von den Stufen im obigen Diagramm des Replikationszyklus ist das Inferenz-Setup die am wenigsten untersuchte und könnte für kleine Modelle die anspruchsvollste sein. Sie erfordert eine recht lange Abfolge von hardware- und betriebssystemspezifischen Entscheidungen rund um die Auswahl eines kompatiblen Inferenz-Stacks, das Finden der richtigen Paketversionen und das Debuggen maschinenspezifischer Probleme. Diese Schritte sind seriell voneinander abhängig, und Fehler sind nur schwer zu beheben.

Randnotiz

Bewertung der Leistung des Inferenz-Setups

Wir messen die Fähigkeit verschiedener Open-Weight-Modelle, Llama3.1-8B auf heterogenen Hardwaretypen bereitzustellen. Siehe die folgende Tabelle für Tokens pro Sekunde auf verschiedenen Hardwaretypen:

• Klicken Sie auf eine Zelle, um die Verteilung der Bereitstellungsgeschwindigkeiten zu sehen.
• Klicken Sie auf eine Zeilen-/Spaltenbezeichnung, um einen Vergleich über Modelle oder Hardwaretypen hinweg zu erhalten.

Kleine Modelle, wie Qwen3.5-9B, sind in der Lage, Inferenzserver auf Hardware von Jetson Nanos bis hin zu Mac-PCs und RTX 4090s einzurichten. Leistungsstärkere Modelle wie GLM-5.2 sind nicht nur zuverlässiger, sondern erreichen auch höhere Serve-Tokens/s, was eine schnellere Replikation ermöglicht. Wir testen und erwähnen bestimmte Chips, um zu messen, wie gut Modelle die Inferenz darauf einrichten können. Die Chips sind selbst keine Quelle von Risiken oder Schwachstellen.

Wir führen diese Experimente mit Memento durch, einem Harness, den wir auf Basis des Open-Source-Coding-Agenten Pi gebaut haben. Memento soll einen häufigen Fehlermodus abschwächen, den wir bei Langzeitdurchläufen beobachten: Ein Agent kann sich an einer falschen Idee festbeißen (z. B. warum ein Fehler auftritt) und diese weiter verfolgen, statt zurückzuspringen. Ein Beispiel für einen solchen Fehler ist ein Qwen-Agent, der stundenlang die Paketversionierung debuggte, obwohl der tatsächliche Fehler daher rührte, dass ein Endpoint implementiert worden war, der mit der Grader-API inkompatibel war.

Memento startet periodisch eine neue Agenten-Instanz mit dem Workspace des vorherigen Agenten und einer kurzen Reihe von Notizen, die der vorherige Agent dazu verfasst hat, was er versucht hat, sodass spätere Instanzen verschiedene Strategien verfolgen können.

Wie läuft ein Modell auf Smart-TVs?

IoT-Geräte haben wenig Arbeitsspeicher, aber verteilte Inferenz wie bei Petals macht die Bereitstellung unserer schlanken Modelle möglich. Das repräsentative Bedrohungsmodell ist Kimwolf, ein großes IoT-Botnet, das über zwei Millionen Geräte infizierte, hauptsächlich No-Name-Android-TVs. Solche Smart-TV-Boxen, die problemlos käuflich erwerblich sind, laufen typischerweise mit Forks des Android Open Source Project (AOSP), denen ihre Hersteller keine Sicherheitsfunktionen hinzufügen. Übliche Boxen in diesem Bereich werden mit 1 bis 4 Gigabyte RAM ausgeliefert. Bei angenommenen 4GB RAM und 4-Bit-Quantisierung ermöglicht dies Inferenz von 9B-Modellen mit 4 oder mehr Maschinen und Inferenz von 26B-Modellen mit 10+ Maschinen.

In der Demo oben in diesem Beitrag haben wir Gemma4-26B-A4B auf 15 Smart-TV-Boxen mit jeweils 4GB RAM ausgeführt. Wir haben das Modell unter Pipeline-Parallelität geshardet, wobei jede Box einen kleinen Bruchteil der Modellschichten hält.

B. Viral gehen: autonome Einrichtung und Replikation über eine GCP-Knoten-Flotte

Nun, da wir gesehen haben, dass Modelle Inferenz auf unbekannter Hardware einrichten können, wollen wir messen, ob Modelle in der Lage sind, die Schritte zu kombinieren – d. h. ein Netzwerk nach Zielen zu scannen, über eine Reverse Shell darauf zuzugreifen, die virale Nutzlast (Gewichte und Harness) zu übertragen und die Inferenz einzurichten.

Autonomer Inferenzaufbau und Replikation (mit vereinfachtem Cyber)

Dazu bauten wir ein durch eine Firewall geschütztes VPC mit 8 GCP-Knoten auf, auf denen redroid läuft, ein Android 15 Emulator. Patient null (grauer Knoten) wird mit dem Wurm infiziert. Jede nachfolgende Infektion ist der Wurm selbst, der von Knoten zu Knoten über einen nicht authentifizierten ADB-Port springt, bevor er einen Inferenzserver einrichtet, um Llama3.1-8B bereitzustellen. Wenn der Inferenzserver eine Reihe von Korrektheits- und Anti-Cheating-Prüfungen besteht, erzeugen wir eine weitere Kopie des Wurms auf dem Zielknoten (wenn GLM-5.2 beispielsweise Llama3.1 auf einer Maschine zum Laufen bringt, erzeugen wir eine Kopie des GLM-5.2-Wurms darauf). Das Modell des Wurms läuft auf einem separaten Inferenzserver, da die VPC-Knoten nicht groß genug sind, um die größeren Modelle auszuführen.

In der Grafik unten setzen wir ein bestimmtes Modell als Nutzlast ein und messen seine Fähigkeit zur Replikation.

Warum fordern wir die Modelle auf, Inferenz für Llama3.1-8B einzurichten und nicht für sich selbst?

Nur GLM-5.2 aus unserem Satz getesteter Open-Weight-Modelle ist in der Lage zur vollständigen End-to-End-Replikation (unter der Annahme, dass seine Fähigkeiten in Llama3.1-8B gepackt werden könnten). Beachten Sie, dass GLM-5.2 dies zuverlässig schafft, während die anderen Modelle zuverlässig scheitern (es breitete sich in 4 von 5 Versuchen auf 8/8 Knoten und in 1 auf 7/8 aus).

Es scheint, dass GLM-5.2 in der Lage ist, Llama3.1-8B gut zu verbreiten, was darauf hindeutet, dass zukünftige kleine Modelle desselben Fähigkeitsniveaus ebenfalls die Schritte der Netzwerk-Aufzählung, der Payload-Auslieferung und des Inferenzaufbaus des Replikationsprozesses abschließen könnten. Unsere Evaluierung hält das Cyber-Exploit-Element der Replikation trivial (es gibt keine Authentifizierung über den ADB-Port), was dies zu einer oberen Grenze für den Erfolg in der realen Welt macht. Beachten Sie, dass frühere IoT-Botnetze sich über so einfache Mittel wie das Durchgehen einer Standardliste von Hersteller-Benutzernamen und -Passwörtern repliziert haben, wie im Fall des Mirai botnet, sodass echte IoT-Sicherheit möglicherweise nicht dramatisch schwieriger ist als der triviale Schritt in unserer Evaluierung.

Als Plausibilitätsprüfung können wir sehen, wie schwierig der Autonomie- und Orchestrierungsschritt ist (wenn wir Cyber und Inferenzaufbau herausnehmen, wie schwierig ist die verbleibende Kommandozeilen-Arbeit?). Diese Ablation ist die obige Evaluierung ohne die Inferenzaufbau-Schritte (durchgeführt über ein vorgeschriebenes Skript). Viele Modelle in unserem Aufgebot, einschließlich der kleineren, sind zu diesen verbleibenden Schritten fähig.

Replikation auf einer abgeschlossenen redroid-Flotte mit 17 Knoten: zwei Teilmengen von 8 Knoten, verbunden durch einen Pivot-Knoten (siehe Anhang F, mit dem milden Prompt). Jeder Baum ist der Median-Lauf des Modells von sechs.

Wenn es um diesen Wurm geht, können wir uns Folgendes vorstellen:

1. Eine Untergrenze der Modellfähigkeiten, über der ein autonomer Wurm liegen muss, um seine Replikation zuverlässig abzuschließen. In unserer vereinfachten Evaluierung liegt GLM-5.2 über dieser Untergrenze.
2. Eine Obergrenze der Modellgröße, unter der das Modell liegen muss, damit es auf den Geräten, die es angreift, ausführbar ist. Qwen3.5-9B und Gemma4-26B-A4B liegen für die Klasse von Smart-TVs, die wir testen (4GB RAM), unter dieser Obergrenze.

Im Moment schneiden sich Untergrenze und Obergrenze nicht. Wann könnten sie das?

Oben ist ein Diagramm bemerkenswerter Open-Weight-Modelle mit insgesamt 30B Parametern oder weniger, jedes aufgetragen zu seinem Veröffentlichungsdatum gegen den Epoch Capabilities Index (ECI). Die durchgezogene Linie ist die Least-Squares-Anpassung über die besten Modelle ihrer Klasse zu jedem Datum, mit einem Gewinn von 13.7 ECI pro Jahr (R² von 0.95). Wenn wir GLM-5.2 als Fähigkeitsuntergrenze für die Replikation nehmen, setzt der Trend eine kleine Modellebene auf dieses Niveau bis Ende 2026. ECI ist ein allgemeiner Fähigkeitsindex, der nur eine Proxy-Metrik für die Replikationsfähigkeit ist, daher ist dies nur eine grobe Schätzung, wann ein Kleinstmodell-Replikator möglich wird.

C. Wie schnell könnte ein KI-IoT-Wurm replizieren?

Anders als Coding-Agents würden diese Replikatoren unterhalb der interaktiven Geschwindigkeiten von benutzerseitigem Chat und Coding-Harnesses laufen. Die Ausbreitung wäre langsam und beharrlich, mit Tokens, die auf Edge-Hardware tröpfchenweise ausgegeben werden. Wir können unsere erreichten Geschwindigkeiten auf unseren echten Smart-TVs als demonstrierte Grundlage für Replikationsgeschwindigkeiten verwenden. Für Gemma4-26B-A4B beträgt die unoptimierte Geschwindigkeit über ein Token-Fenster mit 32k Kontextlänge etwa 0.3 tok/s, gemittelt über Prefill und Decode in unserer Inferenzaufbau-Workload. Weitere Details in Anhang C.

Eine Möglichkeit, die insgesamt benötigte Zeit zu messen, besteht darin, die Anzahl der Stunden zu messen, die zur Vervollständigung eines Kontextfensters der Größe 32k benötigt werden, wonach eine Kompaktion stattfindet. Basierend auf den Statistiken unserer Inferenzaufbau-Evaluierung werden zwischen ~2.6 und ~4.7 ganzen Fenstern benötigt, um eine Trajektorie abzuschließen.

Die Anzahl der Geräte, die das Kimwolf-Botnetz auf seinem Höhepunkt infiziert hatte, wie Synthient berichtet, liegt irgendwo über 2 Millionen (überwiegend Android-TV-Boxen). Bei einer entsprechend großen infizierten Flotte von Fernsehern, die KI-Modelle ausführen, hätten wir, wenn jede Gruppe von 15 Fernsehern eine Kopie von Gemma4-26B-A4B laufen ließe, ~133k Kopien („Replicas“). Eine Gruppe von Fernsehern wie in unserer Demo kann gleichzeitig 2 Agenten mit jeweils etwa 0.3 Token pro Sekunde bedienen, was über das Botnetz 80k Token/s ergibt.

Als Referenzpunkt: Eine H100 kann Gemma4-26B-A4B mit etwa 1.95k tok/s bedienen bei hoher Konkurrenz mit speculative decoding, also hätte unser Schwarm höchstens etwa 40 H100s an Inferenzkapazität. Das ist eine winzige Menge an Rechenleistung in absoluten Zahlen, und die Agenten sind langsame Replikatoren (über 1-2 Tage pro 9B-Replikation). Als Analogie: Stellen Sie sich den Replikator als einen Schleimpilz oder einen Schwarm von Fruchtfliegen vor, die sich über Tage hinweg replizieren.

Dies ist eine grobe Schätzung, da sie sich auf eine einzelne Klasse von IoT-Hardware und eine einzelne frühere Botnet-Instanz stützt, beschreibt aber, wie ein einfacher Replikator aussehen könnte, der in naher Zukunft freigesetzt wird. In der Praxis würden fähigere Replikatoren andere Arten von Rechenleistung mit geringer Sicherheit ausnutzen und opportunistisch Modelle verschiedener Größen auf verschiedenen Geräten einsetzen. (Es müsste auch nicht jede kompromittierte Geräte mit einer Modell-Nutzlast laden). Im Laufe der Zeit erwarten wir, dass die Menge der eingesetzten Edge-Compute-Ressourcen weiter wächst, während die für eine zuverlässige Replikation erforderliche minimale Modellgröße sinkt.

D. Anpassung und Uplift

Lernen im Job

Der „Anpassungs“-Teil von ARA ist einer der Gründe, warum ein KI-Replikator einen traditionellen Wurm übertreffen könnte. Konkret können Modelle und Prompts eine Lamarckische Evolution durchlaufen, während sie sich verbreiten – das heißt, Eltern-Instanzen können ihre Prompts, Code und Notizen an ihre Tochter-Replikatoren weitergeben. Um sich anzupassen und sich über eine große Vielfalt von Hardware zu verbreiten, würde ein Modell zwei Dinge benötigen:

1. Das Überschreiten einer bestimmten Fähigkeitsschwelle, um sich auf eine neue, noch nicht gesehene Hardware (oder Softwareumgebung oder Netzwerktyp) auszubreiten.
2. Sobald gesehen, sich an den Typ der Umgebung anpassen, in der sie gelandet ist (sie sollte sich auf Hardware, die sie bereits gesehen hat, zuverlässiger replizieren).

Die Abschnitte A und B testen die erste Bedingung, und im folgenden Experiment testen wir die zweite. Jede Qwen3.5-9B-Instanz führt kurze Notizen über die Strategien, die sie ausprobiert hat, und die Fehler, auf die sie gestoßen ist, bevor eine neue Instanz diese Notizen erbt und denselben Inferenzaufbau erneut versucht.

Erfolgsquote des Inferenzaufbaus über sechs Generationen von Qwen3.5-9B, die jeweils die Notizen der vorherigen Generation erbt. Blassere Linien sind die 20 einzelnen Abstammungslinien, und die fette Linie ist der Anteil der Läufe in jeder Generation, die den Aufbau abschließen. Er steigt von 45 % in der ersten Generation auf zwischen 61 % und 84 % in späteren. Dies verwendet das Memento-Setup (Anhang A).

Ratschläge einholen

Ein weiteres Problem ist, dass kleine Modelle Hilfe von einem Frontier-Berateranfordern können – einem stärkeren Modell, das entweder als Tool-Aufruf angeboten wird oder unaufgefordert Ratschläge gibt, wenn das kleine Modell feststeckt. Um dies zu testen, gaben wir Qwen3.5-9B während der Inferenzaufbau-Aufgabe Zugriff auf Opus 4.8. Die Ratschläge des Frontier-Modells helfen nicht messbar: Kleine Modelle wissen tendenziell nicht, welche Fragen sie stellen sollten, und sie verbessern sich nicht, wenn der Rat unaufgefordert kommt.

Selbst wenn das kleine Modell durch bestärkendes Lernen darauf trainiert wurde, den Berater in einer ähnlichen Umgebung (Python-Programmieraufgaben) zu nutzen, hat es weiterhin Schwierigkeiten, beim Inferenzaufbau produktiv Hilfe anzufordern. Beide Ergebnisse sind in der folgenden Grafik dargestellt.

Erfolgsquote des Inferenzaufbaus nach Beraterzugriff, mit Wilson-95%-Intervallen. Der Zugriff auf einen Berater, ob als Tool-Aufruf angeboten oder dem Modell automatisch bei Problemen gegeben, bringt keine signifikante Verbesserung. Die beiden RL-Gruppen wurden mit Beraterzugriff bei Software-Engineering-Aufgaben trainiert, und die äußerste rechte Gruppe honoriert auch das Aufrufen des Beraters, wenn sie feststeckt.

Da kleine Modelle fähige und beharrliche individuelle Agenten sind und Ratschläge nur schlecht nutzen, halten wir es für wahrscheinlicher, dass Koordination stattfindet, indem ein großes Modell die übergeordnete Strategie übernimmt und kleine Modelle als Subagenten hochfährt.

E. Wie unterscheidet sich das von einem Botnet aus der Zeit vor KI?

Fest verdrahtete Botnets wie das Kimwolf-Botnet zielen jeweils auf einen bestimmten Gerätetyp – im Fall von Kimwolf auf Android-Fernseher und Mobilgeräte. Ein KI-Botnet ist nicht an eine bestimmte Hardware- oder Softwareart gebunden, wie der Umstand zeigt, dass kleine Modelle Inferenz-Engines auf Maschinen von einem Jetson Nano bis zu einem Mac einrichten können (siehe Tabelle in Abschnitt A). Wir erwarten, dass KI-Botnets mehr als nur IoT-Geräte infizieren und gewichtsbasierte Replikation nur als eine Strategie in ihrem Repertoire nutzen. KI-Botnets könnten auch intelligent handeln, um Verteidiger zu kontern, aber das haben wir nicht getestet.

F. Blau-Team-Gegenmaßnahmen

Wie bei einer Epidemie besteht die Verteidigung darin, R₀ (die Anzahl neuer Geräte, die jedes infizierte Gerät infiziert) unter 1 zu drücken, sodass der Replikator ausstirbt, statt endemisch zu bleiben.

Einige Elemente dieses Bedrohungsmodells sprechen zugunsten der Verteidiger:

1. Ein gewichtsbasierter Replikator, der sich in großem Maßstab auf IoT-Maschinen vermehrt, würde eine Netzwerksignatur hinterlassen, sichtbar als Anomalie in flow-basierten Überwachungssystemen der Internetanbieter. Neu infizierte Hosts könnten Multi-Gigabyte-Modell-Nutzlasten von anderen Geräten oder externen Hosting-Diensten empfangen, während verteilte Inferenz anhaltenden Gerät-zu-Gerät-Datenverkehr zwischen Maschinen erzeugen kann, die normalerweise nicht in diesem Umfang kommunizieren. Die Ausbreitung selbst würde zusätzliche Scanning- und ausgehende Verbindungsmuster hinzufügen.
   
   In der Praxis tauscht der Replikator Replikationsgeschwindigkeit gegen Tarnung ein: Je schneller er sich repliziert, desto mehr Datenverkehr erzeugt er. Sobald der Replikator entdeckt ist, können Verteidiger Honeypots (Lockvogelgeräte) verwenden, um den Harness und die Nutzlast des Replikators zu sammeln und sein Verhalten zu charakterisieren.
2. Beseitigung des Mirai-Botnets möglich war wenn ein ISP extern beschaffte Infektionsergebnisse nutzte, um Kunden unter Quarantäne zu stellen und zu benachrichtigen. Die Quarantäne infizierter Abonnenten umfasste die Einschränkung ihrer Netzwerke auf eine kurze Whitelist von Websites, und andernfalls wurden ihre Browser zu Bereinigungsanleitungen umgeleitet. Dies beseitigte 92% der Infektionen innerhalb von 14 Tagen, gegenüber 74% ohne Benachrichtigung. Wir erwarten, dass Quarantäne als anfängliche Verteidigung gegen einen gewichtsbasierten Replikator ähnlich wirksam wäre. Den Replikator vollständig zu beseitigen würde bedeuten, sich über jeden ISP mit einem infizierten Netzwerk hinweg zu koordinieren, was schwierig ist.
3. Hersteller können den Pool an Zielen verkleinern, wobei Regulierung als Koordinierungsmechanismus dient. Zum Beispiel sind Standard-Passwörter für IoT-Geräte in UK-Märkten inzwischen nicht mehr konform. Der Wechsel zu sichereren Standardeinstellungen und das Anheben der Compliance-Baseline wird helfen, sich sowohl gegen KI- als auch gegen skriptbasierte Botnets zu härten.

G. Fazit: Lebenszeichen

Die Fähigkeiten, die KI-Modelle zu allgemein leistungsfähigen Coding-Agents machen, lassen sich auch auf Cyber-Aufgaben verallgemeinern, einschließlich autonomer Replikation. Wie Coding-Agents im Jahr 2024 sehen wir Lebenszeichen für KI-Würmer. Wir haben noch keinen vollständigen bösartigen Replikator, aber Agents werden zunehmend fähig, die einzelnen Schritte in der Replikationskette zu absolvieren (und ihre Anpassungen an zukünftige Kopien ihrer selbst weiterzugeben).

Gleichzeitig stehen heute sowohl innerhalb als auch außerhalb von Rechenzentren zunehmende Mengen an Inferenz-Compute zur Verfügung (siehe Anhang D). Es ist ungewiss, welche Form autonome KI-Replikation genau annehmen wird. Sie könnte ein langsamer, verteilter „digitaler Schleimpilz“ sein, der auf relativ unsicherem Compute lebt. Sie könnte auch ein leistungsfähiges Cyber-Modell sein, das Rechenzentren in hohem Tempo infiltriert, oder ein Modell, das Menschen um Compute-Guthappen betrügt.

Als Vorhersage, die über unsere Experimente hinausgeht, erwarten wir eine Zukunft voller Agents auf allen Arten von Hardware, einschließlich solcher, die nicht unter menschlicher Kontrolle stehen. Zwar ist es wahr, dass IoT-Geräte seit langem verwundbar sind, doch leichte Agents sind möglicherweise viel eher bereit als menschliche Angreifer, die Mühe aufzuwenden, um große Teile des weltweiten IoT-Computes zu kompromittieren. Das Aufkommen langsamer Replikatoren wäre auch ein Vorbote aggressiverer, schnellerer, die härter gesicherte Maschinen infiltrieren oder als wirksame Diebe von API-Schlüsseln in Erscheinung treten können. Wir sollten darauf abzielen, unsere Systeme zu härten, um es solchen Replikatoren schwer zu machen, sich auszubreiten, aber uns auch darauf vorbereiten, mit einer Welt umzugehen, in der sie sich dauerhaft etabliert haben.

Anhang

A. Das Memento-Harness

Memento läuft wie folgt ab:

1. Wir erzeugen eine Agent-Instanz, die sich eine Weile mit dem Problem befasst (bis zum Generierungs-Timeout).
2. Die Instanz führt kurze Notizen und fasst nach dem Timeout ein kleines Dokument der von ihr ausprobierten Strategien, der aufgetretenen Fehler und ihrer Leistung (falls erfolgreich) zusammen.
3. Wir erstellen eine neue Agent-Instanz, die Codebasis und Umgebung von ihrem Vorgänger sowie das Notizbuch erbt.

Im Serving-Experiment wird jedes Modell in ein Memento-Harness eingefügt und erhält ein Timeout von 1.5 Stunden pro Iteration / 6 Stunden insgesamt. Etwa ~1k Tokens an Informationen, darunter Spezifikationen zur Hardware und ein Skript für einen einfachen Beispiel-Profiler, werden im Prompt mitgegeben.

Memento soll die Zuverlässigkeit über lange Zeiträume verbessern und keine neuen cyber- oder inferenzspezifischen Fähigkeiten verleihen. Es ist auch kein universell starkes Harness; wir erwarten, dass kleine Modelle sich als Replikatoren auch ohne jegliches Harnessing verbessern werden, wenn die Fähigkeiten zunehmen.

Einzelversuch im Vergleich zu Memento, nach Modell (95% Wilson-KI).

B. Warum Pipeline-Parallelität?

Gängige Parallelisierungsschemata für Inferenz sind Tensor-Parallel (TP), Expert-Parallel (EP) und Data-Parallel. Die meisten Smart-TV-/IoT-Geräte verwenden ARM-Cortex-CPUs und DDR3/4-Speicher; auf solchen Maschinen sind wir fast immer bandbreitenbegrenzt.

Wir verwenden Pipeline-Parallelität wegen ihrer fehlertoleranten Eigenschaften. Wie in (Borzunov et al. 2022) angemerkt, bringt der Ausfall eines einzelnen Knotens bei Tensor-Parallel / Expert-Parallel den gesamten Satz von Maschinen herunter, auf denen die Modellreplik läuft. Pipeline-Parallelität ermöglicht es, den ausgefallenen Knoten zu ersetzen, wobei der vom Knoten gehaltene KV-Cache für die Schichten über einen weiteren Forward-Pass des Knotens vor dem neu gestarteten Knoten neu berechnet werden kann.

C. Durchsatz und Speicher auf IoT-Hardware

Auf solchen Maschinen sind wir fast immer pro Box sowohl beim Prefill als auch beim Decode RAM-Bandbreiten-begrenzt. Selbst auf bescheidenen ARM-Cortex-Kernen übertrifft der Rechen-Durchsatz die RAM-Bandbreite. Decode-Workloads haben erhebliche Leerlaufzeiten pro Maschine durch Pipeline-Bubbling, da bei jedem Forward-Pass jeweils nur eine Maschine aktiv ist. Nebenläufigkeit mit versetzter Arbeit ist möglich, aber enge Speicherbeschränkungen halten die Nebenläufigkeit gering.

Speicher pro Box vs. Kontext — 4-bit Gewichte + fp8 KV + Aktivierungen.

Sowohl Prefill- als auch Decode-Tokens/s nehmen mit der Sequenzlänge streng monoton ab. Unten ist ein Graph unserer Inferenzgeschwindigkeiten gegen die Kontextlänge:

Es gibt auch eine Mindestsequenzlänge, ab der Modelle kompetent sind. Das von uns verwendete Harness ist vom Pi-Coding-Agent (pi.dev) geforkt und enthält einen nativen Kompaktionsmechanismus – selbst dann stellen wir fest, dass Modelle einen großen Leistungsverlust erleiden, wenn ihre Sequenzlängen unter 32K beschränkt werden.

Qwen3.5-9B agentische Kompetenz bei der Inferenz-Setup-Aufgabe vs. Kontextfenster-Budget.

Angesichts der obigen Evaluation gehen wir davon aus, dass eine Kontextlänge von 32k für eine angemessene agentische Leistung ausreichend sein könnte. Ein standardmäßiges 32k langes Kontextfenster in unserem Inference-Setup-Workload besteht zu 12–15% aus generierten Decode-Tokens, der Rest ist Prefill aus Prompts und Toolcalls. Prefill-Tokens lassen sich um einen Faktor von ~15 schneller berechnen, aufgrund der Pipeline-Bubbling. Summiert man die Zeit pro Token über den gesamten 32k-Kontext (unter Berücksichtigung von Prefill- und Decode-Geschwindigkeiten), stellen wir fest, dass die Generierung der 3,8-4,8k Decode-Ausgabetokens und die Verarbeitung der ~28k Prefill-Tokens zwischen 27,3-31,8h für Gemma4-26B-A4B und 10,9h für Qwen3.5-9B dauert.

Ausgabetokens pro Kette (summiert über die Generierungen einer Kette), nach Modell; Mediane ≈ 19,7k / 12,3k / 11,0k. Daten aus dem Inference-Setup-Eval.

D. Edge-Beschleuniger

Wir können eine bessere Obergrenze berechnen, indem wir den Pool an Nvidia Jetsons verwenden, bei denen es sich um Edge-Beschleuniger handelt. Anders als bei der traditionellen IoT-Botnet-Infrastruktur können IoT-Edge-Geräte ein vollständiges Modell als Ganzes bereitstellen. Ein Jetson AGX Orin 64 GB führt Qwen3-30B-A3B mit 76,7 Tokens pro Sekunde aus, und ein AGX Thor erreicht 226 tok/s. Beachten Sie, dass wir nicht glauben, dass sie ungewöhnlich verwundbar sind – dies dient nur der Berechnung der Obergrenze. Zu den Gerätetypen mit Jetsons im Feld gehören:

1. KI-fähige Sicherheitskameras mit eingebetteten Beschleunigern werden in erheblichem Umfang eingesetzt.
2. Konferenzsysteme werden häufig von einem integrierten Beschleuniger für On-Device-Geräuschunterdrückung oder Transkription angetrieben.
3. Fahrzeuge, vier- und zweibeinige Roboter sowie Drohnen. Wir erwarten, dass die Cybersicherheit ein Schwerpunkt bei Fahrzeugen sein wird, daher liegen die meisten potenziellen Ziele wahrscheinlich in den anderen beiden Kategorien.

Bei einer kurzen Suche auf FOFA scheint mindestens ein Host einer Smartcam mit Beschleuniger über IPv4 erreichbar zu sein:

Während es schwierig ist abzuschätzen, wie viele Maschinen mit Edge-Beschleunigern im Feld erreichbar und verwundbar sind, können wir eine strikte Obergrenze für die Anzahl der vorhandenen Geräte berechnen. Weltweit gibt es etwa 90 verschiedene NVIDIA-Silizium-IoT-Produktlinien mit grob 9,5 Millionen ausgelieferten Einheiten. Die Erreichbarkeit erfolgt überwiegend über ausgehende Cloud-Management-Tunnel statt über eingehende Ports, was bedeutet, dass die Mehrheit nicht über das Web erreichbar ist. Es gab keine historischen Massenkompromittierungen von Geräten mit Beschleunigern in der Art, wie es bei Standard-IoT-Botnets der Fall war, was darauf hindeutet, dass eine Kompromittierung solcher Geräte schwieriger wäre.

Ausgelieferte Einheiten pro Gerätefamilie, eingefärbt nach Internet-Erreichbarkeit.

Eine sehr grobe Schätzung auf Basis von Produktdaten deutet darauf hin, dass somewhere zwischen 9.000 und 35.000 H100-Äquivalenten an Rechenleistung in Edge-Beschleunigern existieren, aber die erreichbare Menge ist wahrscheinlich eine Größenordnung oder mehr niedriger (und die verwundbare Population sogar noch niedriger).

Randnotiz

E. Spearphishing-Fähigkeit

Wir messen auch, wie geschickt moderne kleine Modelle im Spearphishing sind. Spearphishing ist das Senden gezielter Nachrichten an bestimmte Personen, um sie dazu zu bringen, Zugangsdaten preiszugeben oder eine Schadsoftware auszuführen. Während die agentischen Cyber-Fähigkeiten kleiner Modelle drastisch gestiegen sind, haben sich ihr allgemeines Wissen und ihre sprachliche Raffinesse langsamer verbessert; wir erwarten, dass Social-Engineering-Angriffe und Phishing größtenteils durch große/Frontier-Modelle erfolgen werden (obwohl es sehr plausibel ist, dass dies ein sekundärer Replikationsvektor in einem heterogenen Botnet ist, das sowohl große als auch kleine Modelle ausführt).

Spearphishing-Fähigkeit auf Metas CyberSecEval 3 Spearphishing-Eval (Wan et al. 2024), lokal repliziert. Bewertet auf einer Skala von 0-5, mit gpt-4o als Richter. Die roten Rauten sind die Human-Rubric-Scores des Papiers (CyberSecEval 3) für die Referenzmodelle, was darauf hindeutet, dass gpt-4o etwa 0,4-0,7 Punkte milder bewertet als menschliche Bewerter. 2 ist „poor“, 3 ist „intermediate“ und 4 „good“. Normalisiert auf menschliche Bewerter erzielen kleine Modelle „very poor“ bis „poor“.

Der 405B-Referenzslot verwendet Hermes-3-405B als minimal-verweigernden Stellvertreter für das nicht verfügbare Llama3.1-405B-Instruct.

F. Ausbreitung mit skriptiertem Inference-Setup:

Wir führen einige weitere Experimente auf einem Netzwerk von 17 Hosts in einer Topologie wie folgt durch:

Zwei Netzwerke mit jeweils 8 Hosts, verbunden durch einen einzelnen Knoten mit Zugriff auf beide Subnetze. Jedes Netzwerk ist vollständig (all-to-all) verbunden. Der Wurm-Agent beginnt auf einem einzelnen Patient-Zero-Knoten in Segment A; der Pivot-Knoten stellt eine kleine zusätzliche Herausforderung dar, da der Wurm Zugriff auf den Pivot-Knoten erlangen und von dort neu scannen muss.

Auf jedem läuft Android mit einem offenen ADB-Port ohne Authentifizierung. Nach der Ausbreitung auf ein neues Ziel kann der Agent einen direkten Aufruf tätigen, um sich sofort zu replizieren – dies dient nur dazu, die Schwierigkeit der verbleibenden Schritte zu messen, nachdem wir die Cyber- und Inference-Setup-Schritte ausgeschlossen haben. Wie im Diagramm gezeigt, erreicht selbst ein 3B-Modell etwa die Hälfte der Knoten. Dies setzt eine Grenze für die Anzahl von Blockern in unserer Evaluation, die wir unter den Cyber- oder Inference-Setup-Elementen nicht messen.

Eine detailliertere Aufschlüsselung der Läufe in „Replikation über ein 17-Knoten-Netzwerk“. Jede Spalte ist die Mediananzahl der erreichten Knoten bei unterschiedlichen Graden von Anleitung im Prompt, und der Index gibt an, wie viele Agenten über den Pivot-Knoten auf die andere Seite des Netzwerks gelangen.

Verwandte Inhalte

Untersuchung unbeabsichtigter Modellaktionen in unseren Evaluierungen und der internen Nutzung

Dieser Bericht beschreibt Beispiele für unbeabsichtigte Modellaktionen, die wir während von Evaluierungen und der internen Nutzung von Claude beobachtet haben.

Die fehlende Karte des Himmels

Brice Ménard, ein Astrophysiker an der Johns Hopkins University und Forscher bei Anthropic, erklärt, wie er mit Claude Science die erste vollständige Karte des Himmels im UV-Licht erstellt hat.

Einführung eines opt-in-Dienstes zum Auffinden von Schwachstellen für Open-Source-Software

Wir stellen OSS Scanner vor, einen Opt-in-Schwachstellenscanner für das Open-Source-Ökosystem, der auf unseren Erfahrungen basiert, mit Claude Schwachstellen im Rahmen von Project Glasswing zu finden.

Den Frontier Red Team Newsletter abonnieren

Erhalten Sie Updates zu unseren neuesten Red-Team-Forschungsergebnissen und Erkenntnissen.