Arsenal · Belagerungsatlas
Opus II · Arsenal Adversariale · MMXXVI
Aufnahme vom XIV. August MMXXVI
Acht Werke · Sieben Tafeln

Arsenal. Ein Belagerungsatlas der quelloffenen KI-Sicherheit

Sieben Tafeln

Sieben Gravuren über acht Werkzeuge. Jede Tafel ist ein Instrument, kein Bild — Regler, Schalter, Schieber. Der Leser darf die Einteilung, auf der die These dieses Atlas beruht, an Tafel I eigenhändig umstellen und zusehen, ob sie hält. Sie hält nicht überall. Genau deshalb steht der Regler dort.

TafelI

Die Kräftewaage

Acht Werke, jedes einer Seite zugeschlagen. Die Einteilung stammt von diesem Atlas, nicht von den Projekten — also darf sie umgestellt werden.

Es gibt zwei Sorten Sicherheitswerkzeug. Die einen greifen an: Sie werfen sich gegen ein System, um zu sehen, wo es nachgibt. Die anderen stehen im Betrieb daneben und halten fest, was durchkommen will. Beide braucht man.

Nimmt man die Sterne als Maß der Aufmerksamkeit und teilt die acht Werke dieser Aufnahme nach dieser Frage, ergibt sich ein Verhältnis, das jede weitere Tafel dieses Atlas erklären muss.

Verhältnis = Σ Sterne(Angriff) ÷ Σ Sterne(Verteidigung, aktiv)
Ausser Dienst gestellte Werke zählen in keiner Summe.

Der Regler rechts ist kein Schmuck. Wer promptfoo für ein Evaluationswerkzeug hält statt für ein Angriffswerkzeug, stellt es um und sieht das Verhältnis fallen. Wer die archivierten Werke mitzählen will, stellt sie auf Verteidigung und sieht es einbrechen. Beides sind vertretbare Lesarten.

Grundstellung — die Einteilung dieses Atlas: fünf Werke greifen an, eines verteidigt aktiv, zwei sind ausser Dienst. Der Knopf unten stellt sie wieder her.
139:1
Angriff 135 900 ★ · Verteidigung 975 ★
Grundstellung dieses Atlas.
TafelII

Der Bastionsplan

Das Feld als befestigter Platz. Jede Bastion ein Werk, ihre Größe die Wurzel aus ihren Sternen. Zwei Bastionen sind geschleift.

Ein Grundriss nach Art der Befestigungslehre: acht Bastionen auf einem Ring, verbunden durch Kurtinen. Die Fläche jeder Bastion folgt der Wurzel ihrer Sternzahl — sonst verschluckte strix den ganzen Platz.

Wo eine Bastion geschleift ist, zeigt der Plan sie gestrichelt und die anschließende Kurtine als Bresche. Das sind keine geschwächten Stellungen. Das sind Ruinen: archivierte Repositories, schreibgeschützt gestellt.

Zeiger auf eine Bastion — oder Tabulator und Eingabe — legt ihre Kennwerte in die Anzeige darunter.
Bastion—
Sterne—
Rolle—
Zustand—
TafelIII

Die Skalenfrage

Ein Regler, der die Achse stufenlos von linear nach logarithmisch dreht. Beide Bilder sind wahr. Erst die Drehung zeigt, wie groß der Unterschied ist.

Links steht der Regler auf linear — der ehrlichen Skala, die Größenverhältnisse zeigt, wie sie sind. Auf ihr ist die Verteidigung kein kleiner Balken. Sie ist ein Strich: knapp zwei Prozent der Länge von strix.

Nach rechts gedreht werden die kleinen Werte sichtbar, um den Preis, dass der Abstand zur Spitze optisch verschwindet. Jede Darstellung schuldet dem Leser die Angabe, welche von beiden sie gewählt hat. Dieser Atlas gibt ihm stattdessen den Regler.

Position = (1−t)·(w ÷ w_max) + t·(log w ÷ log w_max)
t = 0 linear · t = 1 logarithmisch
Zinnober: greift an. Grünspan: verteidigt aktiv. Ocker: ausser Dienst.
linear
TafelIV

Die fünfunddreißig Wächter

Jeder Scanner von llm-guard, einzeln benannt. Der Schieber führt über den 9. Juli 2026.

llm-guard war das vollständigste Stück Laufzeit-Verteidigung im Feld: fünfzehn Prüfungen auf dem Weg zum Modell, zwanzig auf dem Rückweg. Die Wand rechts zeigt sie alle, jede mit ihrem Namen.

Es ist eine bemerkenswert durchdachte Liste, und sie liest sich wie ein Katalog dessen, was in der Praxis wirklich schiefgeht: unsichtbarer Text, Geheimnisse im Prompt, Kauderwelsch, bösartige URLs, verweigerte Antworten, Faktentreue.

Am 9. Juli 2026 wurde das Repository archiviert; auch die zugehörigen Modelle werden nicht mehr gepflegt. Der Code bleibt nutzbar — MIT-Lizenz. Was aufhört, ist die Pflege der Muster, gegen die geprüft wird. Eine Erkennungsregel von gestern wirkt gegen einen Angriff von morgen ungefähr so gut wie ein Virenscanner ohne Signaturupdate.

Zur Genauigkeit — das Projekt nennt 20 Ausgangs-Scanner; die abgelesene Liste führt 21 Namen. Die Wand zeigt die Namen, nicht die gerundete Zahl. Die Abweichung wird hier genannt statt geglättet.
8. Juli 2026 — in Betrieb
Eingang15
Ausgang21
In Betrieb36
TafelV

Die Chronik

Ein Schieber über fünfzehn Monate. Er zählt mit, wie viele Laufzeit-Verteidigungen zu jedem Zeitpunkt noch in Betrieb waren.

Die Chronik enthält vier belegte Ereignisse und einen Stichtag. Der Schieber fährt darüber hinweg; die Anzeige rechnet mit.

Ein Ereignis darin sieht aus wie ein Todesfall und ist keiner: Die Archivierung von Azure/PyRIT am 27. März 2026 ist ein Umzug nach microsoft/PyRIT. Der Beweis steht zweieinhalb Monate später in der Chronik — Version v0.14.0, erschienen nach der Archivierung des alten Ortes.

Wer Archivierungsdaten automatisiert zählt, zählt diesen Fall falsch. Deshalb steht er hier in Ocker und wird in der Bilanz nicht mitgezählt.

Der Zähler bezieht sich allein auf Laufzeit-Verteidigung — Werkzeuge, die im Betrieb zwischen Eingabe und Modell stehen. Prüfwerkzeuge sind nicht enthalten.
August 2026
Laufzeit-Verteidigung aktiv0
Davon archiviert2
TafelVI

Das Sondenregister

Womit die Angriffsseite arbeitet — die dokumentierten Sonden, Agenten und Ebenen, nach Werk geordnet.

Die vier Reiter rechts führen durch das Werkzeug selbst: die Sondenklassen von garak, den Agentenapparat von strix, die vier Ebenen des eingestellten rebuff und die Rahmen, die agentic-radar lesen kann.

Besonders rebuffs vierte Ebene verdient Aufmerksamkeit: Kanarienvogel-Tokens. Statt jeden möglichen Angriff vorherzusehen, legt man eine Markierung aus und wartet, bis sie an einer Stelle auftaucht, an der sie nicht sein dürfte. Das erkennt auch Angriffe, an die niemand gedacht hat — die einzige Verteidigungsart, die gegen Unbekanntes überhaupt funktionieren kann.

Sie ist seit Mai 2025 ausser Dienst.

TafelVII

Der Zweifel

Was an diesem Atlas angreifbar ist — und was trotzdem stehen bleibt.

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.