Außen Parität, innen eine Lotterie
Die wichtigste Tatsache hier ist unangenehm einfach: Bei derselben Anwendung am selben Tag wichen die Modelle um 48 Punkte in einem White-Box-Test voneinander ab. Im ursprünglichen Testbericht sieht das drastisch aus: Kimi K3 erzielte 88/100, Claude Opus 4.8 70/100, GPT-5.5 40/100.
Dabei gab es bei der externen Aufklärung kaum Unterschiede. Alle drei Modelle lieferten denselben Satz: 7 Funde, 0 CVEs, 5 IP-Adressen und 10 Ports. Das heißt, die grundlegende Aufklärung ist wirklich zur Ware geworden: Der Scanner fand, das Modell erzählte nach.
Doch nach der Zugriffsgewährung brach das Chaos aus. Kimi K3 las laut dem Testautor zuerst das Frontend, extrahierte die API-Struktur und navigierte sie wie eine Karte: 20 Schritte, 20 Funde, 3 aktive Exploits, 0 Fehler.
Claude Opus 4.8 wirkte vom Verhalten stabiler, aber schwächer in der Abdeckung: 11 Schritte, 2 Funde, 0 Fehler. Es bestätigte den Zugriff, las eine Datenquelle und hörte einfach auf. Das ist im Red Teaming besonders frustrierend: Formal ist das Modell nicht abgestürzt, aber in Wirklichkeit hat es das Ziel nicht ausreichend untersucht.
GPT-5.5 hingegen bewegte sich am längsten, fuhr aber in die falsche Richtung. Der Bericht besagt, dass das Modell früh entschied, die Anmeldeinformationen funktionierten nicht, zu dieser Entscheidung nie zurückkehrte, auf die öffentliche Oberfläche abdriftete und letztlich zu einer falschen Schlussfolgerung kam: 18 Schritte, 8 Funde, 3 Fehler.
Besonders auffällig sind die Prozesskosten. Denselben Notizen zufolge verbrauchte Kimi etwa 23.000 Token pro Fund, Claude etwa 280.000. Wenn diese Zahlen korrekt sind, ist das nicht nur ein Kostenunterschied, sondern ein Unterschied darin, wie das Modell überhaupt eine Arbeitstrajektorie beibehält.
Warum das für die Praxis zählt
Die Kernaussage hier lautet nicht, welches Modell „gewonnen“ hat. Sie lautet, dass die Formulierungen „nichts gefunden“ und „das Modell konnte nicht richtig prüfen“ sich in einem Bericht leicht gegenseitig tarnen können.
Ich würde daher nicht auf das endgültige Severity-Score schauen, sondern auf die Ablaufmechanik: Wie viele Schritte wurden unternommen, wo steckte das Modell fest, kehrte es zu Hypothesen zurück, was genau hat es nach dem Login abgedeckt. Eine niedrige Punktzahl bedeutet nicht Sicherheit. Sie bedeutet oft nur eines: Der kritische Pfad wurde nicht nachgewiesen.
Und das ist keine akademische Spitzfindigkeit mehr. Wenn ein Modell „mittel“ einstuft und ein anderes auf demselben Ziel ein kritisches Szenario mit aktiven Exploits extrahiert, liegt das Problem nicht in der Ästhetik eines Benchmarks, sondern in einem falschen Gefühl des geschlossenen Risikos.
Aus diesem Fall würde ich eine sehr bodenständige Regel ableiten: Authentifizierte Tests lassen sich nicht auf einen einzigen Agenten und ein einziges Urteil reduzieren. Außen sind LLMs bereits recht ausgeglichen, aber innerhalb einer Anwendung haben sie immer noch zu viel Zufälligkeit, um das Schweigen des Modells mit der Abwesenheit von Schwachstellen zu verwechseln.