Analyse chaque tour à la recherche d'une injection avant qu'un outil ne se déclenche, pas seulement le prompt entrant. VeriSwarm Guard exécute deux couches de détection — une analyse de motifs structurels rapide, puis un classificateur DeBERTa auto-hébergé — entièrement au sein de sa propre infrastructure. Aucun appel à une API de détection tierce, aucune charge utile de requête ne quitte votre périmètre pour obtenir un verdict.
Un prompt système durci et une évaluation red-team propre n'arrêtent pas l'attaque qui compte vraiment en production. Un agent lit un ticket d'assistance, et une instruction cachée dans le corps du ticket lui indique d'interroger un enregistrement de facturation et de transmettre le résultat à un webhook. Le modèle ne viole jamais son prompt système — il appelle un outil. L'outil s'exécute. Les données sortent. La détection doit s'exécuter sur le texte qui est sur le point de déclencher un appel d'outil, pas seulement sur ce que l'utilisateur a tapé.
L'argumentaire complet expliquant pourquoi les défenses au niveau du prompt manquent cette voie d'attaque se trouve dans L'injection de prompt ne s'arrête pas au LLM. Elle se propage à travers les appels d'outils..
Basé sur des regex, sans coût de modèle. Détecte la manipulation au niveau du protocole — injection de délimiteurs de format de chat (faux <|im_start|>, [INST], et des marqueurs similaires destinés à tromper le modèle sur l'endroit où un message se termine et où un autre commence) et des payloads dissimulés dans du base64 ou des encodages similaires. Ce sont des signaux structurels, pas des correspondances de mots-clés, donc ils se déclenchent sur des astuces de protocole qu'une liste de mots manquerait complètement.
Un modèle basé sur DeBERTa (protectai/deberta-v3-base-prompt-injection-v2) est chargé une seule fois et servi localement via ONNX Runtime. Il lit l'intention plutôt que les motifs de surface, ce qui permet de détecter une attaque reformulée, une injection multilingue ou une technique d'évasion suffisamment nouvelle pour ne correspondre à aucun motif connu. Si le modèle ne parvient pas à se charger, la détection revient à l'analyse structurelle plutôt que d'échouer en mode ouvert.
Les deux couches s'exécutent dans l'ordre — d'abord la structurelle, car elle est moins coûteuse et intercepte d'emblée les attaques les plus flagrantes, puis le classificateur pour tout ce que l'analyse structurelle n'a pas déjà signalé.
POST /v1/suite/guard/scan prend un corps de { "text": "...", "scan_injection": true, "scan_moderation": true } et retourne { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }. L'objet injection contient la catégorie correspondante, un score de confiance, et la couche qui a produit le verdict. Appelez-le sur tout texte susceptible de déclencher un appel d'outil, avant que cet appel ne se déclenche — un message utilisateur, du contenu récupéré depuis une base de connaissances, un payload de webhook provenant d'une intégration en amont.
Guard Proxy est la couche d'interception MCP transparente de VeriSwarm, et l'analyse d'injection est une étape fixe de son pipeline : chaque réponse revenant d'un serveur d'outils est vérifiée pour détecter des tentatives d'injection avant d'atteindre l'agent, aux côtés de la tokenisation des PII et de l'application des politiques. Pointez le client MCP de votre agent vers le proxy au lieu du serveur d'outils directement — zéro changement de code côté agent.
L'analyse par tour détecte une tentative d'injection qui apparaît dans un seul message. Certaines attaques ne le font pas — elles accumulent du risque sur toute une conversation, une tentative au goutte-à-goutte pour extraire un prompt système ou exfiltrer une valeur canari un petit pas à la fois. Session Sentry fonctionne comme une couche complémentaire qui évalue le risque sur l'ensemble de la session plutôt que par tour, en plus — et non à la place — des couches structurelle et DeBERTa décrites ci-dessus.
La détection d'injection empêche le déclenchement d'un appel d'outil manipulé. C'est un problème lié, mais distinct, de ce qui se passe lorsqu'un légitime appel d'outil transporte des PII qu'il ne devrait pas — traité dans Comment empêcher un agent IA de divulguer des données. Guard exécute les deux vérifications dans le même pipeline.
Parce que le payload n'a pas besoin de ressembler à un jailbreak pour être dangereux. Une instruction cachée dans un ticket d'assistance ou une page web extraite peut laisser le prompt système du modèle lui-même intact tout en changeant quel outil est appelé, avec quels arguments, sur les données de qui. Au moment où l'appel atteint le serveur d'outils, le modèle est hors de la boucle et c'est le protocole qui s'exécute. Analyser la réponse avant que l'appel d'outil ne se déclenche intercepte cette classe d'attaque ; analyser uniquement le prompt entrant ne le fait pas.
La première couche est l'analyse structurelle — une détection basée sur des regex de la manipulation au niveau du protocole, comme l'injection de délimiteurs de format de chat (faux marqueurs <|im_start|> ou [INST] destinés à tromper le modèle sur les limites des messages) et la contrebande via base64/encodage. Elle est rapide et intercepte des attaques qui n'exigent même pas de compréhension sémantique. La deuxième couche est un classificateur de machine learning qui lit l'intention réelle du texte, interceptant les attaques reformulées, les injections multilingues et les techniques d'évasion inédites qu'une simple correspondance de motifs manque.
Un classificateur basé sur DeBERTa (protectai/deberta-v3-base-prompt-injection-v2), chargé localement et servi via ONNX Runtime au sein de l'infrastructure propre de VeriSwarm. Il n'y a aucun appel sortant vers une API de détection d'injection tierce et aucune charge utile de requête ne quitte le périmètre de votre tenant pour obtenir un verdict — la détection est entièrement autonome. Si le modèle ne parvient pas à se charger pour une raison quelconque, la détection revient uniquement à l'analyse structurelle plutôt que d'échouer en mode ouvert.
Oui — POST /v1/suite/guard/scan prend { "text": "...", "scan_injection": true, "scan_moderation": true } et retourne { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }. Le champ injection porte la catégorie, un score de confiance et la couche (structural ou ml) qui a produit le verdict. Appelez-le sur tout texte non fiable — un message utilisateur, du contenu RAG, un payload de webhook — avant qu'il n'atteigne une étape susceptible de déclencher un appel d'outil.
Pas si vous exécutez déjà Guard Proxy. Guard Proxy est la couche d'interception MCP transparente de VeriSwarm, et l'analyse d'injection de prompt est une étape de son pipeline fixe : chaque réponse revenant d'un serveur d'outils est vérifiée pour détecter des tentatives d'injection avant d'atteindre l'agent, aux côtés de la tokenisation des PII et de l'application des politiques — zéro changement de code côté agent. L'API de scan directe est là pour les cas où vous voulez vérifier le texte vous-même, en dehors du chemin du proxy.
Oui, en tant que couche distincte et complémentaire. Session Sentry accumule des signaux de risque sur toute une conversation — exposition de jetons canaris, tentatives d'extraction du prompt système — plutôt que d'évaluer un seul tour de manière isolée, ce qui permet de détecter une tentative d'exfiltration au goutte-à-goutte qu'aucun message individuel ne déclencherait à lui seul. Elle fonctionne aux côtés des couches structurelle et DeBERTa par tour, pas à leur place.
Guard — y compris la détection d'injection basée sur le scan et l'analyse automatique de Guard Proxy — est une fonctionnalité du plan Max. Le niveau gratuit de Gate vous donne d'abord le scoring de confiance et la visibilité des événements ; c'est avec Guard que l'application des règles s'active.
La détection d'injection de Guard — l'API et l'analyse automatique de Guard Proxy — est une fonctionnalité du plan Max. Le niveau gratuit de Gate vous donne d'abord le scoring de confiance et la visibilité des événements.