LLM Guard ist archiviert: Alternativen und Migration

Die Standard-Guardrails-Bibliothek bewegt sich nicht mehr

Am 9. Juli 2026 wurde das llm-guard-Repository auf GitHub archiviert. Der Code ist noch da, die MIT-Lizenz gilt weiter, und pip install llm-guard funktioniert nach wie vor. Aber das Repo ist jetzt read-only: keine Commits mehr, keine gemergten PRs, keine Issue-Triage. Wer LLM Guard in Produktion betreibt, laesst ab sofort unmaintainte Sicherheitssoftware ueber seinen KI-Traffic laufen und sollte sich jetzt nach einer LLM-Guard-Alternative umsehen.

Dieser Beitrag erklaert, was "archiviert" fuer eine Sicherheits-Dependency wirklich bedeutet, wie du inventarisierst, wofuer du LLM Guard tatsaechlich nutzt (meist weniger, als du denkst), und wie die Migration aussieht, inklusive der Option, Guardrails komplett aus dem Anwendungscode zu nehmen und auf den Netzwerkpfad zu verlagern.

Was passiert ist

LLM Guard entstand bei Protect AI als Open-Source-Python-Toolkit: ueber 35 Scanner fuer PII-Anonymisierung, Secret-Erkennung, Prompt Injection, Toxizitaet, Bias, Code-Erkennung und Output-Validierung. Umfassend, MIT-lizenziert und kostenlos, wurde es schnell zur Standardantwort auf die Frage "Wie baue ich Guardrails in meine LLM-App?".

Der weitere Verlauf ist das bekannte Muster von venture-finanziertem Open Source. Protect AI wurde von Palo Alto Networks uebernommen, die Entwicklung verlangsamte sich durch 2025 und Anfang 2026, und im Juli wurde das Repo formal archiviert. Nach einer Uebernahme verschieben sich Prioritaeten, und Archivieren ist ehrlicher, als ein Repo still verrotten zu lassen. Fuer die Nutzer ist das praktische Ergebnis trotzdem dasselbe.

Es ist auch Teil einer groesseren Konsolidierungswelle: Helicone ging nach der Uebernahme in den Maintenance-Modus, Humanloop wurde nach dem Wechsel zu Anthropic eingestellt, Private AI hat sich umbenannt und neu ausgerichtet. Die Tooling-Landschaft, auf die sich Teams 2024–2025 standardisiert haben, wird gerade unter ihnen umgebaut.

Was "archiviert" fuer eine Sicherheits-Dependency bedeutet

Eine archivierte Utility-Bibliothek ist laestig. Eine archivierte Sicherheits-Bibliothek ist ein Risiko, denn genau das, wofuer du sie brauchst (mit einer sich bewegenden Bedrohungslage Schritt zu halten), findet nicht mehr statt. Konkret:

• +Keine Sicherheitspatches. Landet eine CVE in LLM Guard selbst oder im schweren Dependency-Baum (transformers, torch, spaCy), kommt kein Fix von upstream. Entweder du patchst in einem Fork, oder gar nicht.
• +Keine neuen Erkennungsmuster. Staendig erscheinen neue Credential-Formate, und jeder Anbieter mit neuem API-Key-Format ist fuer einen eingefrorenen Secrets-Scanner unsichtbar. Prompt-Injection-Techniken entwickeln sich noch schneller; der OWASP-Report 2026 misst 340 % mehr Prompt-Injection-Versuche im Jahresvergleich. Ein eingefrorenes Erkennungsmodell verfaellt gegen einen Gegner, der sich weiterentwickelt.
• +Dependency-Verfall. LLM Guard pinnt bestimmte Versionen des Hugging-Face-Stacks. Je weiter sich das Oekosystem bewegt, desto oefter musst du waehlen: die gesamte Python-Umgebung zurueckhalten oder Kompatibilitaets-Patches selbst pflegen.
• +Keine Modell-Updates. Die Transformer-Modelle hinter den Scannern Anonymize, PromptInjection und Toxicity werden nie wieder trainiert. Ihr Recall war schon immer der tuning-intensive Teil von LLM Guard; jetzt ist die Obergrenze fix.

Nichts davon tut am ersten Tag weh. Alles davon tut irgendwann weh, und Sicherheits-Dependencies sind der schlechteste Ort, um den Zeitpunkt herauszufinden.

Erst inventarisieren, was du wirklich nutzt

LLM Guard liefert ueber 35 Scanner, aber kaum jemand betreibt 35 Scanner. Jeder kostet Latenz (100 ms bis mehrere Sekunden bei den modellbasierten), also landen die meisten Teams bei einem kleinen Kern. Bevor du Alternativen bewertest: grep deine Scanner-Konfiguration und schreib auf, was tatsaechlich in der Kette steckt. In der Praxis ist es meist eine Teilmenge von:

from llm_guard import scan_prompt
from llm_guard.input_scanners import Anonymize, Secrets, PromptInjection, Toxicity

scanners = [Anonymize(), Secrets(), PromptInjection(), Toxicity()]
sanitized_prompt, results, valid = scan_prompt(scanners, prompt)

Also: PII-Anonymisierung, Secret-Erkennung, Prompt-Injection-Erkennung und manchmal Toxizitaet. Der Long Tail (Bias, Gibberish, Code-Erkennung, Lesezeit, JSON-Validierung) ist meist entweder ungenutzt oder mit ein paar Zeilen eigenem Code trivial ersetzbar.

Diese Inventur ist wichtig, weil "LLM Guard ersetzen" ein viel groesseres Projekt ist als "die vier Scanner ersetzen, die wir wirklich nutzen". Scope die Migration auf Letzteres.

Eine LLM-Guard-Alternative waehlen: drei Wege

Weg 1: Eine andere Python-Bibliothek

Du kannst pro Scanner andere Open-Source-Komponenten einsetzen: Microsoft Presidio fuer PII-Erkennung, einen eigenstaendigen Secrets-Scanner fuer Credentials, NeMo Guardrails oder ein Klassifikationsmodell fuer Content-Policy.

Das behaelt die Architektur bei, eine Scanner-Kette in der Anwendung, und genau das ist Staerke und Problem zugleich. Du behaeltst volle Kontrolle und null Vendor-Abhaengigkeit, erbst aber dasselbe Betriebsmodell, das LLM Guard teuer gemacht hat: Modell-Hosting, Schwellenwert-Tuning, Sprachabdeckung, und jetzt die Upgrade-Treadmills mehrerer Bibliotheken statt einer. Und Presidio ist ein Erkennungs-Toolkit und kein Redaktionssystem, ohne Secrets-Unterstuetzung, mit einweg-Anonymisierung und ohne Audit-Trail. Wir haben aufgeschrieben, wo Presidio aufhoert und was produktive Redaktion darueber hinaus braucht; die Kurzfassung: Es ersetzt LLM Guards Anonymize-Scanner, nicht LLM Guard.

Waehle diesen Weg, wenn dein Team Guardrails wirklich als internes System besitzen will, oder wenn du auf die Long-Tail-Scanner (Bias, Code-Erkennung, Output-Validierung) angewiesen bist, die Gateway-Produkte nicht abdecken.

Weg 2: Forken und einfrieren

Du kannst das archivierte Repo forken und privat weiterpflegen. Das ist fuer genau eine Situation richtig: eine harte Compliance-Anforderung, dass alle Sicherheits-Tools aus selbst kontrolliertem Quellcode laufen, plus die Personalstaerke, eine transformerbasierte Python-Codebasis dauerhaft zu reviewen und zu patchen.

Sei ehrlich beim zweiten Teil. Ein Fork, den niemand aktiv pflegt, ist das archivierte Repo mit Umwegen. Du hast die Haftung uebernommen, ohne sie zu verringern.

Weg 3: Guardrails auf die Netzwerkebene verlagern

Die dritte Option: nicht mehr in der Anwendung scannen, sondern die Pruefungen auf den Netzwerkpfad legen. Ein AI Gateway sitzt zwischen App und Anbieter und scannt jeden Request im Transit.

Das ist ein echter Architekturwechsel, kein Drop-in-Ersatz. Deshalb lohnt der klare Blick auf die Unterschiede:

Die Abdeckungszeile ist die, die meine Meinung ueber Scanner-Ketten insgesamt geaendert hat. Eine Bibliothek laeuft nur dort, wo du sie aufrufst. Jeder neue Endpoint, jeder Background-Job und zunehmend jeder autonome Agent mit Tool-Calls, die du nie von Hand geschrieben hast, ist eine Gelegenheit, den Scan zu ueberspringen. Mitte 2026, wo Agent-Frameworks Egress-Pfade schneller vervielfachen, als irgendwer sie reviewen kann, ist "haben wir wirklich jede Aufrufstelle gewrappt?" eine Frage, die App-Level-Scanning nicht mehr sicher beantworten kann. Ein Proxy beantwortet sie strukturell: Wenn Traffic rausgeht, wurde er gescannt.

Die Latenzzeile zaehlt auf einer anderen Ebene. LLM Guards modellbasierte Scanner waren der Preis fuer die Breite: eine halbe bis mehrere Sekunden pro Request, auf selbst gehosteter GPU-Infrastruktur. Scanning auf Netzwerkebene mit deterministischen Validatoren und optimierten Modellen laeuft in Millisekunden. Bei Chatbots und Agent-Loops mit Dutzenden Calls pro Aufgabe ist dieser Unterschied fuer Nutzer spuerbar.

Migration: So sehen Vorher und Nachher aus

So sieht die Migration fuer den haeufigsten Fall aus: die Vier-Scanner-Kette von oben, in einer Python-App mit OpenAI.

Vorher laeuft jede Aufrufstelle durch die Scanner-Kette:

scanners = [Anonymize(vault), Secrets(), PromptInjection(), Toxicity()]

def safe_completion(prompt: str):
    sanitized, results, valid = scan_prompt(scanners, prompt)
    if not valid:
        raise GuardrailViolation(results)
    return client.chat.completions.create(
        model="gpt-5.5", messages=[{"role": "user", "content": sanitized}]
    )

Nachher weiss der Anwendungscode nicht mehr, dass es Guardrails gibt. Du richtest das SDK auf das Gateway, und die Pruefungen passieren im Transit:

client = OpenAI(
    base_url="https://gateway.example.com/v1",  # dein Gateway-Endpoint
    api_key=os.environ["GATEWAY_KEY"],
)

def safe_completion(prompt: str):
    return client.chat.completions.create(
        model="gpt-5.5", messages=[{"role": "user", "content": prompt}]
    )

Das Vault-Objekt im ersten Snippet verdient eine Anmerkung, denn es ist eine Migrationsfalle. LLM Guards Anonymize-Scanner konnte Platzhalter-Zuordnungen in einem Vault speichern, damit ein Deanonymize-Output-Scanner sie wiederherstellt. Aber die Zuordnung lebte in deinem Prozess, pro Instanz, mit Lifecycle-Management auf deiner Seite. Wenn du das genutzt hast, achte darauf, dass dein Ersatz reversible Redaktion nativ unterstuetzt. Wenn nicht, gewinnst du mit gateway-seitigem Mask-and-Restore eine neue Faehigkeit: Das Modell sieht Platzhalter, deine Nutzer sehen echte Werte, und die Zuordnung haengt nicht davon ab, welche App-Instanz den Request bearbeitet hat.

Zwei Dinge solltest du bewusst migrieren statt nebenbei:

• +Blocking-Verhalten. scan_prompt lieferte ein Validitaets-Flag, und dein Code entschied, was passiert. Gateways druecken das als Policy aus: blockieren, redigieren oder markieren-und-loggen pro Kategorie. Portiere deine tatsaechlichen Entscheidungen, nicht die Scanner-Liste.
• +Der Long Tail. Wenn du Bias-Erkennung oder Output-Validierung wirklich genutzt hast: Die haben kein Gateway-Aequivalent. Behalte dafuer einen minimalen In-App-Check und lass die Netzwerkebene PII, Secrets und Injection besitzen.

Wie Grepture die Migration abdeckt

Grepture ist ein AI Gateway mit eingebauter Sicherheitsschicht, und der Vier-Scanner-Kern passt direkt darauf:

• +Anonymize → PII-Redaktion: ueber 50 deterministische Muster plus mehrsprachige NER-Modelle, die in-process im Proxy laufen, sodass rohe Prompts nie an eine externe Erkennungs-API gehen. Reversibles Mask-and-Restore ist nativ und ersetzt das Vault/Deanonymize-Muster mit konsistenten Tokens ueber die gesamte Konversation.
• +Secrets → Secret-Scanning: spezialisierte Muster fuer ueber 30 Credential-Typen (API-Keys, Bearer-Tokens, AWS-Credentials, Connection-Strings), also eine der schwerwiegendsten Leak-Kategorien im LLM-Traffic und genau die Stelle, wo eingefrorene Muster am schnellsten verfallen.
• +PromptInjection → Injection-Erkennung: Scanning am Gateway, ausfuehrlich in unserem Leitfaden zur Prompt-Injection-Praevention.
• +Toxicity → Content-Scanning im Business-Plan, mit lokal gehosteten Modellen.

Weil Grepture ein Proxy ist, gilt derselbe Schutz fuer jede Sprache und jedes Framework im Stack, nicht nur Python. Die Integration ist eine Base-URL-Aenderung, egal ob der Aufrufer ein Node-Service, ein CrewAI-Agent oder ein Coding-Assistent ist. Jeder Scan landet in einem Audit-Trail fuer das Compliance-Team, was unter DSGVO und den Transparenzpflichten des EU AI Act kein optionaler Papierkram mehr ist.

Wir pflegen einen vollstaendigen Vergleich Grepture vs. LLM Guard. Er entstand, als LLM Guard noch maintained war, und die dort beschriebenen Scanner-Abdeckungs-Tradeoffs gelten fuer die eingefrorene Version weiter. Und wenn deine Policy Quellcode-Betrieb verlangt: Der Proxy-Kern ist Open Source und self-hostbar.

LLM Guard hat sich seinen Platz als Standard verdient, und der archivierte Code wird noch eine Weile funktionieren. Aber eine Guardrails-Schicht ist nur so gut wie ihr letztes Update, und dieses Datum steht jetzt fest. Welchen Weg du auch waehlst: Geh ihn, bevor die Luecke in deinem Traffic sichtbar wird.