Ein Guardrail, den eine Anwendung eigens aufrufen muss, wird früher oder später übersprungen: ein neuer Endpunkt, ein eiliger Release, ein an einem Nachmittag geschriebenes Skript. Der verlässliche Ort für eine Prüfung ist der Anfragepfad selbst, sodass nichts das Modell und nichts die Nutzer erreicht, ohne ihn zu durchlaufen.
So wird Guardrino angeboten. Die Inspect-API bleibt für Apps, die eine Frage stellen wollen. Die folgenden Integrationen setzen Guardrino dorthin, wo der Datenverkehr ohnehin fließt; die Liste am Ende zeigt, was heute verfügbar ist.
Jeder Pfad führt dieselben Prüfungen aus wie die Inspect-API, sodass eine Richtlinie und ein Audit-Protokoll alle abdecken. Die Entwicklerdokumentation von HisnLabs hat je eine Seite zu Proxy, LiteLLM und MCP, mit Beispielen und den verbleibenden Grenzen.
Ein OpenAI-kompatibler Proxy: nur eine URL ändern
Guardrino stellt POST /v1/chat/completions bereit. Eine App, die die OpenAI-Chat-API spricht, ändert nur ihre Basis-URL. Guardrino prüft die Beiträge der Nutzer, den Kontext, den das Modell als Daten liest (Tool-Ergebnisse, Dokumente sowie Bild- und Dateiteile, die zuerst durch den Extraktionsdienst laufen), und die Antwort. Eine Ablehnung kommt im OpenAI-Fehlerformat zurück, sodass die vorhandene Fehlerbehandlung der App weiter funktioniert.
Gestreamte Antworten werden beim Wachsen geprüft
Eine Antwort, die in Stücken eintrifft, lässt sich nicht erst am Ende beurteilen. Guardrino liest eine gestreamte Antwort, während sie wächst. Verstößt sie gegen die Richtlinie, endet der Stream mit einem Fehler-Ereignis. Bereits gesendete Stücke lassen sich nicht zurückrufen; wo nichts vor der Prüfung angezeigt werden darf, hält buffer_output = true die Antwort zurück, bis sie vollständig bestanden hat.
Jedes Modell hinter LiteLLM
Teams, die viele Modelle über LiteLLM routen, wollen keinen Guardrail pro Modell. Guardrino kann als benutzerdefinierter LiteLLM-Guardrail laufen, vor und nach dem Aufruf, oder vor LiteLLM sitzen, mit LiteLLM als Upstream. In beiden Fällen deckt ein Satz Prüfungen jedes Modell dahinter ab.
MCP-Tools: Beschreibungen und Ergebnisse sind ebenfalls Eingaben
Ein Agent liest die Beschreibung eines Tools wie eine Anweisung und das Ergebnis eines Tools wie verlässliche Information. Beides sind Texte, die jemand anderes geschrieben hat. Der MCP-Sicherheitsproxy sitzt zwischen dem Agenten und seinen MCP-Servern. Er prüft Tool-Beschreibungen, wenn Tools aufgelistet werden, die ausgehenden Argumente (Canary-Token, personenbezogene Daten, URLs) und liest zurückkommende Ergebnisse als Kontext in Fenstern.
- Beschreibungen werden beim Auflisten der Tools geprüft.
- Argumente werden auf dem Weg nach draußen geprüft.
- Ergebnisse werden auf dem Rückweg geprüft, wie jedes Dokument, das das Modell liest.
Wo jede Integration steht
- Inspect-API: Verfügbar
- OpenAI-kompatibler Proxy: Verfügbar
- Streaming-Prüfung (Server-Sent Events): Verfügbar
- LiteLLM-Guardrail-Plugin: Verfügbar
- MCP-Sicherheitsproxy: Verfügbar
Das LiteLLM-Plugin, seine Tests und sofort nutzbare Beispiele für den Proxy, das Streaming und MCP sind Open Source auf GitHub, unter der Apache-2.0-Lizenz.
Wo Guardrino und HisnLabs ins Spiel kommen
Guardrino ist dafür gebaut, im Anfragepfad zu sitzen: Ein OpenAI-kompatibler Proxy und ein LiteLLM-Guardrail sind verfügbar, ein MCP-Sicherheitsproxy folgt als Nächstes, damit die Prüfung dort stattfindet, wo der Datenverkehr ohnehin fließt.