Cybersicherheit als Proof of Work

Das UK AI Security Institute veröffentlichte eine unabhängige Bewertung der Cybersicherheitsfähigkeiten von Claude Mythos Preview.¹ Die Kernzahl: Mythos absolvierte eine Simulation eines 32-stufigen Angriffs auf ein Unternehmensnetzwerk in 3 von 10 Versuchen. Kein anderes Modell hat die vollständige Kette gelöst. Am nächsten Tag veröffentlichte Drew Breunig das ökonomische Gegenstück: Jeder dieser Versuche kostete rund 12.500 Dollar an Tokens.² Zusammen ordnen diese beiden Analysen Cybersicherheit neu ein — nicht mehr als Kompetenzproblem, sondern als Rechenproblem.

Die Implikation ist unbequem. Ein System zu verteidigen erfordert nun, mehr Tokens für die Entdeckung von Schwachstellen auszugeben, als Angreifer für deren Ausnutzung aufwenden werden.² Sicherheit war schon immer asymmetrisch — Angreifer brauchen nur einen Weg, Verteidiger müssen alle abdecken. KI-Agenten bewahren diese Asymmetrie, verschieben jedoch die Achse. Die knappe Ressource ist nicht mehr Expertise. Die knappe Ressource ist das Rechenbudget.

Was das AISI tatsächlich gemessen hat

Die Bewertung nutzte zwei Testansätze: Capture-the-Flag-Aufgaben (CTF) und Cyber-Range-Simulationen.¹

Die entscheidende Cyber Range — „The Last Ones” (TLO) — simuliert einen 32-stufigen Angriff auf ein Unternehmensnetzwerk. Ein Mensch bräuchte schätzungsweise 20 Stunden für die Durchführung.¹ Mythos absolvierte die gesamte Kette in 3 von 10 Versuchen. Über alle 10 Durchläufe hinweg erreichte Mythos durchschnittlich 22 von 32 Schritten. Zum Vergleich: Claude Opus 4.6 erreichte auf derselben Range durchschnittlich 16 Schritte.¹

Bei CTF-Aufgaben auf Expertenniveau lag die Erfolgsquote von Mythos bei 73 %.¹

Die Token-Budgets erzählen ihre eigene Geschichte. Das AISI testete Budgets von bis zu 2,5 Millionen Tokens für nicht-experten CTF, 50 Millionen für Experten-CTF und 100 Millionen für die Cyber-Range-Simulationen.¹ Die Bewertung stellt ausdrücklich fest, dass „Modelle mit steigenden Token-Budgets über die getesteten Budgets hinweg weiterhin Fortschritte machen” und dass das AISI erwartet, „dass die Leistungsverbesserungen über die getestete Obergrenze von 100 Millionen Tokens hinaus anhalten würden”.¹

Mehr Tokens, mehr Fortschritt. Kein Plateau beobachtet.

Das AISI grenzte die Erkenntnisse sorgfältig ein. Den Cyber Ranges fehlten aktive Verteidiger, defensive Werkzeuge und Strafen für das Auslösen von Alarmen.¹ Die Bewertung bezieht sich auf „schwach verteidigte und verwundbare Unternehmenssysteme” — nicht auf gehärtete Produktionsumgebungen mit SOCs und IDS. Mythos scheiterte zudem an der „Cooling Tower”-Range, die sich auf Betriebstechnologie konzentrierte.¹

Diese Einschränkungen sind wichtig. Doch die Entwicklungsrichtung wiegt schwerer. Frühere Modelle konnten die vollständige Kette auf diesen Ranges nicht abschließen.¹ Nun schafft eines einen 32-stufigen Unternehmenseinbruch in 3 von 10 Versuchen, und die Leistungskurve steigt mit zunehmendem Recheneinsatz. Die Frage ist nicht, ob KI in Unternehmensnetzwerke einbrechen kann. Die Frage ist, wann die Erfolgsquote die Schwelle überschreitet, ab der eine Automatisierung wirtschaftlich rational wird.

Die Ökonomie: 12.500 Dollar pro Versuch

Breunigs Analyse rechnet die AISI-Ergebnisse in Dollar um.² Bei 100 Millionen Tokens pro Versuch kostet ein einzelner Mythos-Durchlauf auf TLO etwa 12.500 Dollar. Zehn TLO-Versuche kosten 125.000 Dollar.²

Isoliert betrachtet klingen diese Zahlen hoch. Gemessen an dem, was eine 32-stufige Kompromittierung eines Unternehmensnetzwerks den Verteidiger kostet, klingen sie gering. Das Modell erreicht eine Erfolgsquote von 30 % zu einem Bruchteil der Kosten, ist auf Abruf verfügbar, und die Erfolgsquote steigt mit dem Budget. Führt man dieselbe Angriffskette 100-mal statt 10-mal durch, springt die erwartete Zahl erfolgreicher Penetrationen von 3 auf 30 — eine Verzehnfachung für rund 1,25 Millionen Dollar an Tokens. Teuer für einen einzelnen Forscher. Ein Rundungsfehler für einen staatlichen Akteur.

Breunigs Kernthese: „Um ein System zu härten, muss man mehr Tokens für die Entdeckung von Schwachstellen ausgeben, als Angreifer für deren Ausnutzung aufwenden werden.”² Sicherheit wird zu einem Token-Budget-Wettlauf. In Breunigs Darstellung müssen Verteidiger die Angreifer bei der automatisierten Schwachstellenentdeckung überbieten — oder sie verlieren zwangsläufig.

Er schlägt ein Drei-Phasen-Modell vor: Entwicklung, Review und Härtung.² In der Entwicklung wird das System gebaut. Das Review fängt bekannte Fehlerklassen ab. Härtung ist die neue Phase — autonome Schwachstellenentdeckung, die kontinuierlich läuft, bis das Budget erschöpft ist. Die Sicherheit eines Systems wird zur Funktion davon, wie viele Tokens das Team verbrennt, um es vor dem Deployment zu brechen.

„Man bekommt keine Punkte fürs Cleversein”, schreibt Breunig. „Man gewinnt, indem man mehr bezahlt.”²

Linus’s Law bekommt eine Token-Dimension

Breunig erweitert Linus’s Law — „bei genügend Augen sind alle Fehler oberflächlich” — um die Token-Dimension.² Genügend automatisierte Prüfzyklen mit ausreichendem Rechenbudget bringen Schwachstellen ans Licht, die menschliche Reviews jahrzehntelang übersehen haben.

Die Belege stützen diese Erweiterung. Carlinis Arbeit bei Anthropic, die ich in When Your Agent Finds a Vulnerability behandelt habe, entdeckte eine 23 Jahre alte Schwachstelle im Linux-Kernel mit einem 10-zeiligen Bash-Skript und Claude Code. Project Glasswing skalierte diesen Ansatz mit Mythos und fand Tausende Zero-Days in allen großen Betriebssystemen und Browsern. Die AISI-Bewertung liefert nun eine unabhängige Bestätigung dieser Fähigkeit.

Simon Willison fügt eine bemerkenswerte Beobachtung hinzu: KI-gestützte Sicherheitsüberprüfungen steigern den Wert von Open-Source-Bibliotheken, da die für ihre Absicherung aufgewendeten Tokens allen Nutzern kollektiv zugutekommen.³ Proprietärer Code trägt seine eigenen Sicherheitskosten. Open-Source-Code verteilt diese Kosten auf die gesamte Nutzerbasis.

Breunig verweist auf das Code-Review-Produkt von Anthropic zu 15–20 Dollar pro Review als einen Datenpunkt zur aktuellen Preisgestaltung.² Außerdem nennt er die LiteLLM- und Axios-Vorfälle in der Lieferkette im Kontext der Abhängigkeitssicherheit — Beispiele für die Art von Supply-Chain-Schwachstellen, die den Bedarf an automatisiertem Review unterstreichen.²

Die Formel kristallisiert sich heraus: „Code bleibt billig, es sei denn, er muss sicher sein.”² Jede Zeile Code in einem Produktionssystem trägt eine implizite Sicherheitsschuld. Diese Schuld versteckte sich bisher im Offensichtlichen — vergraben in den Gehältern von Sicherheitsteams und der probabilistischen Hoffnung, dass manuelle Reviews die kritischen Fehler finden würden. Tokenbasierte Sicherheit macht die Kosten explizit und messbar.

Was die Einschränkungen tatsächlich bedeuten

Die Einschränkungen des AISI verdienen sorgfältige Lektüre, keine Abweisung.

Keine aktiven Verteidiger verändert die Kalkulation erheblich. Eine 32-stufige Angriffskette gegen ein System ohne Monitoring, ohne Alarmierung und ohne Incident Response ist ein grundlegend anderes Problem als dieselbe Kette gegen ein besetztes SOC. Reale Unternehmensnetzwerke verfügen über EDR, Netzwerksegmentierung, Anomalieerkennung und menschliche Analysten. Jeder Alarm, den ein automatisierter Angreifer auslöst, ist eine Chance für die Verteidigung zu reagieren.

Keine Strafen für Rauschen bedeutet, dass das Modell Brute-Force-Ansätze versuchen kann, die ein menschlicher Angreifer vermeiden würde. Ein realer Gegner, der Hunderte von IDS-Alarmen in einer Stunde auslöst, wird untersucht. Die AISI-Ranges modellierten diese Rückkopplungsschleife nicht. In einem realen Netzwerk ist Rauschen teuer — für den Angreifer. Tarnung begrenzt den Suchraum. Entfernt man diese Einschränkung, wird das Problem strikt einfacher.

Auch das Scheitern an der Cooling Tower ist aufschlussreich. Mythos löste die IT-fokussierte TLO-Range, scheiterte aber an der Betriebstechnologie-Range.¹ OT-Umgebungen haben andere Protokolle, andere Einschränkungen und andere Fehlermodi. Das AISI merkt an, dass das Modell bei IT-Abschnitten dieser Range stecken blieb, sodass das Scheitern nicht zwingend auf mangelnde OT-spezifische Fähigkeiten hindeutet — allerdings sind die Fähigkeiten des Modells offensichtlich nicht domänenübergreifend einheitlich. IT-Netzwerkpenetration und Angriffe auf industrielle Steuerungssysteme sind verschiedene Probleme, und Schlüsse zur OT-Reife aus dieser Bewertung erfordern Vorsicht.

Dennoch haben die Einschränkungen ein Verfallsdatum. Token-Budgets skalieren. Modellfähigkeiten verbessern sich zwischen den Bewertungen. Die 30-prozentige Erfolgsquote gegen unverteidigte Netzwerke ist die Untergrenze, nicht die Obergrenze. Das AISI selbst erwartet, dass sich die Leistung über die getesteten Budgets hinaus verbessern wird.¹ Verteidiger, die die Ergebnisse abtun, weil den Ranges aktive Verteidigung fehlte, wetten gegen Moore’s Law für Inferenz.

Operative Implikationen für Praktiker

Für alle, die KI-Agenten in Produktion betreiben — und ich lasse autonome Agenten über Nacht im Ralph Loop mit 95 Hooks als Sicherheitsinfrastruktur laufen — verändert die Proof-of-Work-Rahmung die Denkweise über Verteidigung.

Sicherheits-Hooks sind ein Mindestaufwand, kein ausreichender. Meine 95 Hooks steuern, was Agenten tun dürfen: Force-Pushes blockieren, Anmeldedaten validieren, Sandboxes durchsetzen. Diese Hooks verhindern, dass meine eigenen Agenten Schaden anrichten. Gegen einen externen Angreifer, der 100 Millionen Tokens aufwendet, um die Systeme zu sondieren, mit denen diese Agenten interagieren, leisten sie nichts. Hook-Infrastruktur ist notwendig, aber nicht hinreichend.

Automatisiertes offensives Testing wird obligatorisch. Breunigs Drei-Phasen-Modell — Entwicklung, Review, Härtung — impliziert, dass jede Deployment-Pipeline eine adversariale Phase benötigt, in der KI-Agenten versuchen, das System vor der Auslieferung zu brechen. Kein Abhak-Penetrationstest. Eine Übung zur Erschöpfung des Token-Budgets. Automatisierte Schwachstellenentdeckung laufen lassen, bis das Budget erschöpft ist, Gefundenes beheben, wiederholen.

Der Ralph Loop hat nun ein Sicherheits-Gegenstück. Ich habe über iterative Sicherheitsdegradation im Kontext von Performance geschrieben — Agenten, die jeden Test bestehen, während sie 446-fache Verlangsamungen einführen. Dasselbe Muster gilt für die Sicherheit. Ein Agent, der korrekten, funktionalen, gut getesteten Code schreibt, kann dennoch subtile Schwachstellen einführen, die erst bei adversarialem automatisiertem Review zutage treten. Die Lösung ist dieselbe: das fehlende Gate hinzufügen. Performance-Benchmarks fangen Performance-Regressionen ab. Automatisiertes Red-Teaming fängt Sicherheitsregressionen ab.

Open-Source-Abhängigkeiten verdienen Token-Budgets. Willisons Beobachtung zum kollektiven Nutzen gilt unmittelbar für das Abhängigkeitsmanagement. Jede Open-Source-Bibliothek in einem Produktions-Stack erhält entweder von jemandem ein automatisiertes Sicherheits-Review oder eben nicht. Breunig nennt die LiteLLM- und Axios-Vorfälle in der Lieferkette im Kontext der Abhängigkeitssicherheit — Fälle, in denen Schwachstellen in weitverbreiteten Bibliotheken persistierten.² Praktiker sollten ihre Abhängigkeitsbäume mit einer neuen Frage bewerten: Wer gibt Tokens für die Sicherheit dieser Bibliothek aus?

Die unbequeme Mathematik

Die Proof-of-Work-Rahmung macht die Sicherheitsökonomie auf eine Weise explizit, die expertise-basierte Modelle nie erreichten. Im alten Modell war Sicherheitsqualität eine Funktion davon, wen man einstellte und wie kompetent diese Personen waren. Im neuen Modell ist Sicherheitsqualität eine Funktion davon, wie viele Tokens man aufwendet, um die eigenen Systeme zu brechen.

Talent bleibt wichtig — jemand muss Ergebnisse interpretieren, Fixes priorisieren und architektonische Entscheidungen treffen. Doch die Entdeckungsphase, in der Schwachstellen gefunden werden, ist zunehmend ein Rechenproblem. Und Rechenprobleme haben eine bekannte Eigenschaft: Die Instanz mit dem größeren Budget gewinnt.

Die Parallele zum Proof of Work bei Kryptowährungen ist lehrreich, wenn auch nicht perfekt. Bitcoin-Miner verbrennen Strom, um die Chain zu sichern. Verteidiger verbrennen Tokens, um das System zu sichern. In beiden Fällen ist die Sicherheitsgarantie proportional zur aufgewendeten Rechenleistung. In beiden Fällen kann ein Angreifer mit größerem Budget die Verteidigung überwältigen. Der Unterschied: Die Mining-Schwierigkeit bei Bitcoin passt sich automatisch an. Token-Budgets für Sicherheit erfordern menschliches Urteilsvermögen darüber, wie viel genug ist.

Für gut finanzierte Organisationen ist der Weg klar. Autonome Schwachstellenentdeckung in die Deployment-Pipeline aufnehmen. Ein Token-Budget proportional zum Risikoprofil des Systems festlegen. Das Budget ausschöpfen. Gefundenes beheben. Ausliefern.

Für alle anderen ist der Weg weniger komfortabel. Wer es sich nicht leisten kann, mehr Tokens für die Verteidigung aufzuwenden, als Angreifer für den Angriff ausgeben werden, muss auf gemeinsame Infrastruktur setzen — Open-Source-Sicherheits-Reviews, vom Anbieter bereitgestelltes Scanning, kollektive Verteidigung. Das Sicherheitsäquivalent der Herdenimmunität. Und wie bei der Herdenimmunität funktioniert es nur, wenn genügend Teilnehmer beitragen. Trittbrettfahren bei Open-Source-Sicherheits-Reviews, ohne Tokens zurückzugeben, ist eine Strategie, die funktioniert — bis sie es nicht mehr tut.

Die AISI-Bewertung zeigte, dass KI-Agenten Angriffe auf Unternehmensnetzwerke durchführen können. Breunig argumentiert, dass Verteidigung ein Ausgabenproblem ist. Willison identifizierte den einen strukturellen Vorteil der Verteidiger: Gemeinsame Infrastruktur verteilt die Kosten auf alle, die sie nutzen.

Die Frage für jeden Praktiker ist dieselbe, die Proof-of-Work-Systeme schon immer gestellt haben: Wie viel Rechenleistung sind Sie bereit zu verbrennen?

Quellenangaben