Un garde-fou qu’une application doit penser à appeler finit tôt ou tard par être oublié : un nouveau point d’accès, une livraison pressée, un script écrit en un après-midi. L’endroit fiable pour un contrôle, c’est le chemin de la requête lui-même : rien n’atteint le modèle, et rien n’atteint l’utilisateur, sans le traverser.
C’est ainsi que Guardrino est proposé. L’API d’inspection reste, pour les applications qui veulent poser une question. Les intégrations ci-dessous placent Guardrino là où le trafic passe déjà ; la liste finale indique ce qui est disponible aujourd’hui.
Chaque chemin applique les mêmes contrôles que l’API d’inspection : une seule politique et un seul journal d’audit les couvrent tous. La documentation développeur de HisnLabs consacre une page au proxy, à LiteLLM et à MCP, avec des exemples et les limites qui subsistent.
Un proxy compatible OpenAI : une seule URL à changer
Guardrino expose POST /v1/chat/completions. Une application qui parle l’API de chat OpenAI ne change que son URL de base. Guardrino vérifie les tours de l’utilisateur, le contexte que le modèle lit comme donnée (résultats d’outils, documents, et images ou fichiers, qui passent d’abord par le service d’extraction) et la réponse. Un refus revient au format d’erreur OpenAI : la gestion d’erreurs existante de l’application continue de fonctionner.
Les réponses en streaming sont vérifiées au fil de l’eau
Une réponse qui arrive par morceaux ne peut pas être jugée seulement à la fin. Guardrino lit une réponse en streaming à mesure qu’elle grandit. Si elle enfreint la politique, le flux se termine par un événement d’erreur. Les morceaux déjà envoyés ne peuvent pas être rappelés ; quand rien ne doit être affiché avant vérification, buffer_output = true retient la réponse jusqu’à ce qu’elle ait été validée en entier.
Chaque modèle derrière LiteLLM
Les équipes qui font passer de nombreux modèles par LiteLLM ne veulent pas un garde-fou par modèle. Guardrino peut s’exécuter comme garde-fou personnalisé LiteLLM, avant et après l’appel, ou se placer devant LiteLLM avec LiteLLM pour amont. Dans les deux cas, un seul jeu de contrôles couvre chaque modèle derrière.
Outils MCP : descriptions et résultats sont aussi des entrées
Un agent lit la description d’un outil comme une instruction, et le résultat d’un outil comme une information fiable. Les deux sont des textes écrits par quelqu’un d’autre. Le proxy de sécurité MCP se place entre l’agent et ses serveurs MCP. Il vérifie les descriptions d’outils lorsque les outils sont listés, les arguments sortants (jeton canari, données personnelles, URL), et lit les résultats qui reviennent comme contexte, par fenêtres.
- Les descriptions sont vérifiées quand les outils sont listés.
- Les arguments sont vérifiés à la sortie.
- Les résultats sont vérifiés au retour, comme tout document lu par le modèle.
Où en est chaque intégration
- API d’inspection : Disponible
- Proxy compatible OpenAI : Disponible
- Contrôle du streaming (server-sent events) : Disponible
- Plug-in garde-fou LiteLLM : Disponible
- Proxy de sécurité MCP : Disponible
Le plugin LiteLLM, ses tests et des exemples prêts à l’emploi pour le proxy, le streaming et MCP sont en open source sur GitHub, sous licence Apache-2.0.
Le rôle de Guardrino et de HisnLabs
Guardrino est conçu pour se placer sur le chemin de la requête : un proxy compatible OpenAI, un garde-fou LiteLLM et un proxy de sécurité MCP sont disponibles, de sorte que le contrôle a lieu là où le trafic passe déjà.