Repository-Seiten auf github.com, abgelesen am Stichtag
Kernbefund
Beide Laufzeit-Schutzwerkzeuge der Stichprobe sind archiviert
Der Befund
Es gibt zwei Sorten von Sicherheitswerkzeugen. 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. Am 14. August 2026 sieht es so aus, als hätte sich das
quelloffene Ökosystem entschieden, nur noch eine davon zu bauen.
Auslöser dieser Aufnahme war ein einzelnes Projekt: strix, ein Werkzeug,
das autonome Agenten auf die eigene Anwendung loslassen soll, um Schwachstellen zu finden. Es
stand an diesem Tag ganz oben in der Trending-Übersicht von GitHub. Um es einordnen zu
können, wurden sieben weitere Projekte aus demselben Feld daneben gestellt —
Schwachstellen-Scanner, Red-Team-Frameworks, Laufzeit-Filter.
Was dabei herauskam, war nicht die erwartete Rangliste. Es war ein Muster, und zwar ein
unangenehmes: Die Werkzeuge, die prüfen, wachsen. Die Werkzeuge, die im Betrieb
schützen, sind abgeschaltet. Beide Laufzeit-Schutzwerkzeuge in dieser Stichprobe
sind auf GitHub archiviert — eines im Mai 2025, eines im Juli 2026. Sie sind nicht
langsamer geworden. Sie sind aus.
Prüfstand — greift an, um zu findenVerteidigung — aktiv gewartetArchiviert — eingestellt
Warum dieses Diagramm zwei Skalen braucht
Unten stehen dieselben acht Projekte, gemessen in Sternen. Voreingestellt ist die lineare
Skala — die ehrliche, die Grössenverhältnisse so zeigt, wie sie sind. Auf ihr
ist die Verteidigung nicht zu erkennen. Nicht klein: nicht zu erkennen.
Der Schalter wechselt auf eine logarithmische Skala. Dort werden die kleinen Werte wieder
sichtbar — um den Preis, dass der Abstand zwischen ihnen und der Spitze optisch
verschwindet. Beide Bilder sind wahr. Erst der Wechsel zwischen ihnen zeigt, wie gross der
Unterschied wirklich ist.
ABB. 1 — STERNE JE PROJEKT
Auf linearer Skala sind die letzten drei Balken schmaler als ein Pixel.
Rot: Werkzeuge, die angreifen. Blau: aktive Verteidigung. Grau: archiviert. Sternzahlen von
den Repository-Seiten am 14.08.2026, dort auf Hunderter gerundet dargestellt.
Ein Pixel Verteidigung auf 139 Pixel Angriff. Das Diagramm musste umgebaut werden, damit die
andere Seite überhaupt vorkommt.
ITeil I · Der Prüfstand
Fünf Werkzeuge, die angreifen
Diese fünf tun im Kern dasselbe: Sie erzeugen Eingaben, von denen sie hoffen, dass sie etwas
kaputtmachen, und schauen dann nach, was passiert ist. Der Unterschied liegt darin, worauf sie
zielen — auf die Anwendung, auf das Modell oder auf die Zeichenkette selbst.
strix setzt autonome Agenten auf eine Anwendung an, die arbeiten sollen wie ein
menschliches Pentest-Team: spezialisierte Agenten für Aufklärung, Ausnutzung und
Nachbereitung, die sich abstimmen, Funde teilen und Schwachstellen zu Ketten verbinden. Der
Werkzeugkasten ist der eines Angreifers — HTTP-Proxy, Browser-Exploitation,
Shell-Zugriff, eine Sandbox für Exploits.
Die interessanteste Entwurfsentscheidung ist die Beweislast: Ein Fund gilt erst, wenn der
Agent ihn mit einem funktionierenden Proof of Concept belegt hat. Das ist die Antwort auf
die Krankheit, an der automatisierte Sicherheitswerkzeuge seit jeher leiden — eine
Flut von Meldungen, die niemand mehr nachprüft, bis alle aufhören hinzusehen. Wer
Ausführbarkeit zur Bedingung macht, hat Falschmeldungen nicht reduziert, sondern
definitorisch ausgeschlossen.
Abgedeckt wird die Bandbreite der OWASP Top 10: Injection, kaputte Zugriffskontrolle,
serverseitige Lücken wie SSRF, XXE und RCE, clientseitige wie XSS und CSRF,
Authentifizierungsfehler, umgangene Geschäftslogik, falsch konfigurierte Infrastruktur.
Mit 713 Commits ist das Projekt jung — die 51 200 Sterne sind ein Vertrauensvorschuss,
keine Betriebsbilanz.
Das zweitgrösste Projekt dieser Aufnahme ist eine Textdatei. blns.txt
sammelt Zeichenketten mit hoher Wahrscheinlichkeit, Schaden anzurichten, wenn man sie als
Benutzereingabe verwendet: Steuerzeichen, Unicode-Fallstricke, SQL- und Skript-Fragmente,
Zahlen an den Grenzen der Darstellbarkeit, Zeichenfolgen, die Textrichtungen umkehren. Dazu
dieselbe Liste als JSON und in base64, damit sie auf dem Weg zum Testsystem nicht selbst
zum Problem wird.
Dass eine Datei ohne Code, ohne Abhängigkeiten und mit 273 Commits in zehn Jahren
beinahe so viele Sterne hat wie das aufwendigste Agentenwerkzeug im Feld, ist der
nüchternste Befund dieses Berichts. Der Wert liegt nicht in der Maschinerie, sondern
darin, dass jemand die Fälle gesammelt hat, an die man selbst nicht denkt. Das gilt
für Sprachmodelle nicht weniger als für Eingabefelder — nur heisst es dort
Prompt Injection.
promptfoo begann als Testwerkzeug für Prompts und ist zu einer Plattform geworden, die
Prompts, Agenten und RAG-Aufbauten prüft und daneben Red-Teaming und
Schwachstellen-Scans für KI-Anwendungen anbietet. Modelle verschiedener Anbieter lassen
sich gegeneinander laufen lassen, Ergebnisse landen wahlweise in der Kommandozeile oder in
einer Weboberfläche, die Sicherheitsberichte erzeugt.
Mit 9 364 Commits ist es das mit Abstand am dichtesten bearbeitete Projekt der Stichprobe
— mehr als das Dreizehnfache von strix. Das ist der Unterschied zwischen einem
Projekt, das gerade Aufmerksamkeit bekommt, und einem, das seit Jahren gepflegt wird. Wer
aus dieser Liste eine Werkzeugkette bauen will, findet hier die längste Betriebsspur.
garak nennt sich schlicht „the LLM vulnerability scanner“ und zielt, anders als
strix, nicht auf die Anwendung, sondern auf das Modell selbst. Geprüft wird auf
Halluzination, Datenabfluss, Prompt Injection und weitere Versagensmuster — mit
statischen, dynamischen und sich anpassenden Verfahren.
Die Sonden sind nach Angriffsart sortiert und tragen sprechende Namen:
dan für Jailbreaks,
encoding für Umgehungen über Kodierung,
promptinject,
malwaregen,
glitch für Tokens, bei denen Modelle aus der Spur laufen.
Angebunden werden Hugging Face, OpenAI, AWS Bedrock, Replicate, Cohere, Groq und weitere.
Bemerkenswert ist die Trägerschaft: Ein Hersteller, dessen Geschäft am Verkauf
von Rechenleistung für genau diese Modelle hängt, unterhält das Werkzeug, das
ihre Schwächen sichtbar macht. Das ist keine Selbstlosigkeit, sondern die Einsicht,
dass ein Markt für unprüfbare Modelle kleiner ist als einer für prüfbare.
Das Python Risk Identification Tool ist Microsofts Baukasten für das systematische
Angreifen generativer Systeme — gedacht für Sicherheitsfachleute, die Risiken
finden sollen, bevor ein System in Betrieb geht. 21 Releases und 228 bekannte abhängige
Projekte sprechen für Gebrauch, nicht nur für Beifall.
PyRIT taucht in diesem Bericht an zwei Stellen auf, und das ist eine wichtige Unterscheidung:
Das alte Repository unter Azure/PyRIT wurde am
27. März 2026 archiviert. Das ist
kein Todesfall, sondern ein Umzug nach
microsoft/PyRIT. Wer Archivierungsdaten zählt, ohne die
Weiterleitung zu lesen, produziert genau die Art von Fehlbefund, vor der dieser Bericht
weiter unten warnt.
IITeil II · Der Schutzschild
Zwei Werkzeuge, die schützen sollten. Beide sind aus.
Ein Laufzeit-Schutz ist etwas anderes als ein Testwerkzeug. Er läuft nicht vor der
Auslieferung, sondern währenddessen: Er sieht jede Eingabe und jede Antwort und entscheidet
in Millisekunden, ob sie durchgehen darf. Beide Projekte dieser Gattung in der Stichprobe sind
auf GitHub als archiviert markiert und damit schreibgeschützt.
llm-guard war das vollständigste Stück Laufzeit-Verteidigung im Feld:
35 Scanner, aufgeteilt in 15 für die Eingabe und 20 für die
Ausgabe. Eingangsseitig Anonymisierung, Erkennung von Prompt Injection, Geheimnissen,
unsichtbarem Text, Code, Kauderwelsch und Themenverboten. Ausgangsseitig Prüfung auf
sensible Daten, bösartige URLs, faktische Konsistenz, Relevanz, Voreingenommenheit
und darauf, ob das Modell die Antwort überhaupt verweigert hat.
Das ist eine bemerkenswert durchdachte Liste, und sie liest sich wie ein Katalog dessen,
was in der Praxis wirklich schiefgeht. Am 9. Juli 2026 wurde das Repository archiviert;
auch die zugehörigen Modelle auf Hugging Face werden nicht mehr gepflegt. Die 35
Scanner sind nicht verschwunden — MIT-lizenzierter Code lässt sich weiter
benutzen. Aber niemand pflegt mehr die Muster, gegen die sie prüfen, und eine
Erkennungsregel von gestern ist gegen einen Angriff von morgen ungefähr so
wirksam wie ein Virenscanner ohne Signaturupdate.
rebuff war ein Detektor gegen Prompt Injection mit vier hintereinandergeschalteten Ebenen:
Heuristiken, die verdächtige Eingaben aussortieren, bevor sie das Modell erreichen; ein
eigenes Modell, das den Rest beurteilt; eine Vektordatenbank, die Einbettungen früherer
Angriffe vorhält, um Ähnliches wiederzuerkennen; und Kanarienvogel-Tokens, die
anschlagen, wenn der Systemprompt nach aussen dringt.
Besonders die letzte Ebene ist elegant: Statt zu versuchen, 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. Archiviert seit Mai 2025, vom selben Anbieter wie llm-guard.
Zwei von zwei. Beide Laufzeit-Schutzwerkzeuge dieser Stichprobe stammten vom selben Anbieter
— das schwächt den Befund, löst ihn aber nicht auf.
agentic-radar sitzt zwischen den beiden Lagern. Es greift nicht die laufende Anwendung an
und steht auch nicht im Betrieb daneben, sondern liest den Quellcode eines Agenten-Aufbaus
und zeichnet, was es findet: den Ablauf als interaktiven Graphen, die eingebundenen
Werkzeuge, die angesprochenen MCP-Server. Unterstützt werden OpenAI Agents, CrewAI,
n8n, LangGraph und Autogen.
Die gefundenen Schwachstellen werden auf etablierte Rahmenwerke abgebildet — OWASP Top
10 für LLMs und die Bedrohungsmodelle für agentische Systeme. Dazu kommt
Prompt-Härtung, die knappe Anweisungen in strukturierte, abgesicherte Systemprompts
umschreibt, und ein Laufzeittest, der Angriffe tatsächlich abfeuert: Prompt Injection,
Abfluss personenbezogener Daten, schädliche Inhalte. Ein Workflow für GitHub
Actions liegt bei.
Die Analyse läuft lokal, ohne den Quellcode nach aussen zu geben — dasselbe
Zugeständnis an die Rechtsabteilung, das auch andere Werkzeuge dieser Generation
machen. Mit 975 Sternen ist agentic-radar das kleinste Projekt hier und zugleich das
einzige verteidigende, das noch gewartet wird. Auf diese eine Zahl stützt sich die
gesamte rechte Seite der Rechnung 139:1 — was sie nicht besser macht, aber ehrlicher
beschreibt, als der Nenner es vermuten lässt.
Chronik der Abschaltungen
16.05.2025
rebuff archiviert. Der Prompt-Injection-Detektor mit den vier Schutzebenen
wird schreibgeschützt gestellt. 1 500 Sterne, 140 Forks.
27.03.2026
Azure/PyRIT archiviert — aber nur umgezogen. Das Repository verweist
auf microsoft/PyRIT, wo die Arbeit weiterläuft. Kein
Verlust, sondern eine Umbenennung: der eine Fall in dieser Chronik, der bei flüchtigem
Lesen falsch gezählt wird.
05.06.2026
PyRIT v0.14.0. Beleg dafür, dass der Umzug kein Abschied war —
zweieinhalb Monate nach der Archivierung des alten Ortes erscheint die nächste Version.
09.07.2026
llm-guard archiviert. 35 Scanner gehen offline, die zugehörigen
Modelle auf Hugging Face werden nicht weiter gepflegt. Damit ist die Laufzeit-Verteidigung
in dieser Stichprobe vollständig eingestellt.
14.08.2026
Stichtag. strix führt die Trending-Übersicht an. Fünf Wochen
nach dem Ende von llm-guard steht dem grössten Angriffswerkzeug des Feldes ein einziges
gewartetes Verteidigungsprojekt gegenüber.
Drei Erklärungen — keine bewiesen
Der Befund steht; seine Ursache steht nicht fest. Die folgenden drei Erklärungen sind
plausibel und teilweise miteinander vereinbar. Keine davon lässt sich mit den hier
erhobenen Daten belegen — sie sind als Hypothesen gekennzeichnet, weil sie welche sind.
Der Schutz ist nicht verschwunden, er ist umgezogen
Die wahrscheinlichste Erklärung: Laufzeit-Filter sind vom offenen Ökosystem in
die Plattformen der Modellanbieter gewandert. Wer Inhaltsprüfung, Erkennung von
Prompt Injection und Ausgabefilter direkt beim Anbieter eingeschaltet bekommt, hat wenig
Anlass, eine eigene Bibliothek davorzuschalten — und noch weniger, sie zu pflegen.
Das wäre keine schlechte Nachricht, sondern Arbeitsteilung. Sie hat allerdings einen
Preis, der selten mitgenannt wird: Verteidigung, die nur beim Anbieter stattfindet, ist
von aussen nicht prüfbar. Man kann nicht nachlesen, wogegen gefiltert wird, nicht
testen, wann der Filter irrt, und nicht widersprechen, wenn er sich ändert. Bei
llm-guard konnte man alle 35 Scanner im Quellcode nachlesen.
Angriff ist demonstrierbar, Verteidigung nicht
Ein Angriffswerkzeug liefert ein Ergebnis, das man vorzeigen kann: hier ist die
Lücke, hier der funktionierende Exploit. Ein Verteidigungswerkzeug liefert im
Idealfall gar nichts — nichts ist passiert, und niemand weiss, ob deshalb, weil der
Schutz gewirkt hat, oder weil ohnehin niemand angegriffen hat.
Diese Asymmetrie schlägt auf jede Kennzahl durch, die auf Aufmerksamkeit beruht.
strix kann in einem Demovideo eine Anwendung aufbrechen. llm-guard kann zeigen, dass eine
Anfrage geblockt wurde — was nur überzeugt, wenn man vorher glaubt, dass sie
gefährlich war. Sterne messen, was beeindruckt, und Verhinderung beeindruckt nicht.
Vielleicht schaut dieser Bericht am falschen Ort
Die unbequemste Erklärung ist, dass die Stichprobe schief ist. Laufzeit-Verteidigung
könnte in Projekten stecken, die sich nicht als KI-Sicherheit bezeichnen: in
API-Gateways, in Werkzeugen zur Richtliniendurchsetzung, in
Beobachtbarkeits-Plattformen, die Anomalien melden. Solche Projekte tauchen in keiner
Suche nach „LLM security“ auf und wären hier nie aufgefallen.
Beide Schutzwerkzeuge dieser Aufnahme stammen zudem vom selben Anbieter. Was hier wie ein
Strukturwandel aussieht, könnte in Teilen die Geschäftsentscheidung einer
einzelnen Firma sein. Das ist der ernsteste Einwand gegen die Rechnung 139:1, und er wird
in diesem Bericht nicht ausgeräumt, sondern nur benannt.
Befunde
B1belastbar
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.
B2gerechnet
135 900 Sterne stehen für Werkzeuge, die prüfen und angreifen; 975 für das
einzige gewartete verteidigende Projekt. Das Verhältnis 139:1 ist korrekt gerechnet,
hängt aber vollständig an einem einzigen Nenner. Ein zweites aktives
Verteidigungsprojekt in der Stichprobe würde es halbieren.
B3Entwarnung
Die Archivierung von Azure/PyRIT am 27.03.2026 ist ein Umzug
nach microsoft/PyRIT, kein Ende. Version v0.14.0 erschien am
05.06.2026, danach. Wer Archivierungsdaten automatisiert zählt, zählt diesen Fall
falsch.
B4Beobachtung
Das zweitgrösste Projekt des Feldes ist eine Textdatei ohne Code und ohne
Abhängigkeiten. big-list-of-naughty-strings kommt mit 273 Commits auf 47 700 Sterne
— ein Hinweis darauf, dass der knappe Rohstoff in diesem Feld nicht Technik ist,
sondern die Sammlung der Fälle, an die man selbst nicht denkt.
B5Beobachtung
Alle acht Projekte sind permissiv lizenziert — viermal MIT, viermal Apache-2.0. Der
archivierte Code bleibt damit nutzbar. Was fehlt, ist nicht das Recht zur Weiterverwendung,
sondern die Pflege der Muster, gegen die geprüft wird.
B6Einschränkung
Beide archivierten Schutzwerkzeuge stammen von protectai. Ein Teil des Befundes könnte
die Strategieänderung eines einzelnen Anbieters sein statt einer Bewegung des
Ökosystems. Ohne eine breitere Erhebung ist das nicht zu trennen.
Übersicht
Spaltenüberschrift anklicken zum Sortieren, Suchfeld zum Filtern. Ohne JavaScript bleibt
die Tabelle vollständig lesbar.
Projekt
Rolle
Zustand
Sterne
Forks
Sprache
Lizenz
usestrix/strix
Pruefstand
aktiv
51200
5500
Python
Apache-2.0
minimaxir/big-list-of-naughty-strings
Pruefstand
aktiv
47700
2200
Text
MIT
promptfoo/promptfoo
Pruefstand
aktiv
24200
2200
TypeScript
MIT
NVIDIA/garak
Pruefstand
aktiv
8800
1200
Python
Apache-2.0
microsoft/PyRIT
Pruefstand
aktiv
4000
796
Python
MIT
protectai/llm-guard
Schutzschild
archiviert
3200
433
Python
MIT
protectai/rebuff
Schutzschild
archiviert
1500
140
TypeScript
Apache-2.0
splx-ai/agentic-radar
Zwischenstellung
aktiv
975
130
Python
Apache-2.0
Methodik und ihre Lücken
Wie gezählt wurde — und wo die Rechnung angreifbar ist
Auswahl. Ausgangspunkt war strix aus der Trending-Übersicht vom
14.08.2026. Die übrigen sieben Projekte wurden ergänzt, weil sie in
Übersichten zu KI-Red-Teaming regelmässig gemeinsam genannt werden. Das ist eine
Gelegenheitsstichprobe, keine Vollerhebung — sie kann zeigen, dass ein Muster
existiert, aber nicht, wie verbreitet es ist.
Einteilung. Die Zuordnung zu Prüfstand, Schutzschild und
Zwischenstellung stammt von diesem Bericht, nicht von den Projekten. Sie folgt einer
Frage: Läuft das Werkzeug vor der Auslieferung oder während des Betriebs?
promptfoo liesse sich mit guten Gründen auch anders einordnen, weil es neben
Red-Teaming vor allem Evaluation macht. Wer es herausnimmt, ändert den Zähler um
24 200 — das Verhältnis fällt dann auf rund 114:1 und der Befund bleibt.
Zahlen. Alle Werte stammen von den öffentlichen Repository-Seiten,
nicht aus der API, und sind dort gerundet dargestellt. Sternzahlen messen Aufmerksamkeit,
nicht Verbreitung, nicht Qualität und nicht Wartungsgesundheit. Sie sind hier die
Masszahl, weil sie für alle acht Projekte einheitlich vorliegen — nicht, weil
sie die beste wären. Eine Erhebung über Paketregister-Downloads oder
abhängige Projekte würde ein anderes und wahrscheinlich nüchterneres Bild
ergeben.
Der Nenner. Die Zahl 139:1 hängt an einem einzigen aktiven
Verteidigungsprojekt. Das ist rechnerisch korrekt und rhetorisch aufgeladen. Wer die
archivierten Werkzeuge mitzählt, kommt auf rund 24:1; wer ein weiteres aktives
Verteidigungsprojekt findet, halbiert den Wert. Die Zahl ist als Grössenordnung
gemeint, nicht als Messwert — und sie steht so gross auf der Titelseite, weil die
Grössenordnung das Ergebnis ist.
Was fehlt. Keine Aussage zur Wirksamkeit eines der Werkzeuge. Keine
Prüfung, ob die Scanner von llm-guard je zuverlässig funktioniert haben. Keine
Erhebung kommerzieller, geschlossener Verteidigungsprodukte — die es gibt und die in
dieser Betrachtung vollständig fehlen. Dieser Bericht beschreibt den Zustand eines
öffentlichen Ökosystems an einem Tag, mehr nicht.
Was 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. Ein archiviertes Repository
ist kein verlorener Code. Es ist ein aufgegebener Wartungsvertrag.
Das lässt sich prüfen. Wenn die Plattform-These stimmt, müssten die Filter der
Modellanbieter heute leisten, was llm-guard leistete — nachprüfbar, dokumentiert
und testbar. Wer das feststellen will, braucht dafür ausgerechnet die Werkzeuge aus Teil
I dieses Berichts. Der Prüfstand wäre dann nicht der Gegner der Verteidigung,
sondern das letzte Mittel, sie zu kontrollieren.
Lagebericht KI-Sicherheit · Stand 14. August 2026 · 8 Projekte
Alle Kennzahlen von den öffentlichen Repository-Seiten, abgelesen am Stichtag
Gesetzt mit mzone-ui 1.5.0 · Diagramme mit chart.js 4.4.6