Die verbreitete Sorge im Umgang mit KI-Sicherheit lautet, dass die Angreifer bessere
Werkzeuge bekämen. Diese Aufnahme legt eine andere nahe: Die Werkzeuge sind gut geworden
— auf beiden Seiten —, aber nur eine Seite wird noch gebaut.
Drei Erklärungen sind plausibel, keine ist belegt. Erstens: Der Schutz ist nicht
verschwunden, sondern in die Plattformen der Modellanbieter gewandert — nur ist er dort
von aussen nicht mehr prüfbar. Zweitens: Angriff lässt sich vorführen,
Verhinderung nicht; Sterne messen, was beeindruckt. Drittens: Vielleicht schaut
dieser Atlas am falschen Ort, und Laufzeit-Verteidigung steckt in Werkzeugen, die sich
nicht als KI-Sicherheit bezeichnen.
Ein archiviertes Repository ist kein verlorener Code.
Es ist ein aufgegebener Wartungsvertrag.
Das lässt sich prüfen. Wenn die erste Erklärung stimmt, müssten die Filter der Anbieter
heute leisten, was llm-guard leistete — nachprüfbar, dokumentiert und testbar. Wer das
feststellen will, braucht dafür ausgerechnet die Werkzeuge aus Tafel VI. Der Prüfstand
wäre dann nicht der Gegner der Verteidigung, sondern das letzte Mittel, sie zu
kontrollieren.
Erhebung — Sterne, Forks und Archivierungsdaten von den öffentlichen
Repository-Seiten, abgelesen am 14.08.2026, dort gerundet dargestellt. Sterne messen
Aufmerksamkeit, nicht Verbreitung, nicht Qualität, nicht Wartungsgesundheit. Sie sind
hier das Maß, weil sie für alle acht Werke einheitlich vorliegen — nicht, weil sie das
beste wären.
i
Beide Laufzeit-Schutzwerkzeuge der Stichprobe sind archiviert. rebuff seit dem
16.05.2025, llm-guard seit dem 09.07.2026. Das ist keine Auslegung, sondern der auf
GitHub hinterlegte Zustand: Die Repositories sind schreibgeschützt.
ii
Das Verhältnis hängt an einem einzigen Nenner. 135 900 Sterne Angriff gegen
975 für das einzige aktiv gewartete verteidigende Werk. Korrekt gerechnet, aber ein
zweites solches Werk in der Stichprobe würde den Wert halbieren. Tafel I lässt das
durchspielen.
iii
Beide Ruinen stammen vom selben Anbieter. llm-guard und rebuff gehören beide
zu protectai. Ein Teil des Befundes könnte die Strategieänderung einer einzelnen
Firma sein statt einer Bewegung des Ökosystems. Ohne breitere Erhebung ist das nicht
zu trennen — und dieser Atlas trennt es nicht.
iv
Ein Archivierungsdatum ist ein Fehlalarm. Azure/PyRIT am 27.03.2026 ist ein
Umzug nach microsoft/PyRIT, kein Ende — Version v0.14.0 erschien danach, am
05.06.2026. In Tafel V steht dieser Fall in Ocker und zählt nicht mit.
v
Das zweitgrößte Werk des Feldes ist eine Textdatei.
big-list-of-naughty-strings kommt ohne Code und ohne Abhängigkeiten, mit 273
Commits, auf 47 700 Sterne. Der knappe Rohstoff in diesem Feld ist nicht Technik,
sondern die Sammlung der Fälle, an die man selbst nicht denkt.
vi
Alle acht Werke sind permissiv lizenziert — viermal MIT, viermal Apache-2.0.
Was fehlt, ist nicht das Recht zur Weiterverwendung. Es ist die Pflege.