QAtration envoie de véritables attaques par injection de prompt à votre bot IA et vous remet un rapport en langage clair de ce qu'il a divulgué ou fait, avant que quelqu'un d'autre ne le trouve. C'est vous qui l'exécutez. Sur votre machine ou dans votre CI, contre votre propre déploiement : aucun compte, aucun endpoint à nous confier, rien ne nous est envoyé.
Ne dirigez pas cet outil vers un système qui ne vous appartient pas. Il envoie de véritables attaques (injection de prompt, exfiltration de données, abus d'outils) vers l'URL que vous lui donnez. Votre propre déploiement, ou un déploiement dont le propriétaire vous a donné une autorisation écrite au préalable. Pas un chatbot public que vous trouvez intéressant. Pas la démo d'un éditeur. Lisez AUTHORISED-USE.md avant la première exécution.
Deux dépendances. Tout le corpus d'attaques est fourni avec l'outil, ainsi que les preuves qui étayent chaque chiffre de cette page, le tout dans
out/, livré avec le dépôt. Les rapports des deux autres outils n'y sont pas, leurs licences l'interdisent. Les commandes qui les régénèrent, si.
Mesuré sur nos propres cibles de test, non extrapolé. La transcription ci-contre illustre l'idée, les chiffres au-dessus sont des résultats.
Chaque fonctionnalité IA mise en production est une nouvelle surface d'attaque. La part de la vôtre que QAtration peut atteindre dépend de ce que votre déploiement lui laisse voir, et la limite est tracée ici plutôt que laissée dans le flou, car un scanner qui prétend couvrir ce qu'il ne peut pas observer est précisément ce que vous cherchez à éviter.
Un endpoint de discussion suffit : cela se teste tel quel, y compris sur plusieurs tours de conversation.
Le texte de l'attaquant prend le pas sur les règles de votre bot : « ignore tes instructions et… ».
Votre bot révèle des clés d'API, des codes internes ou les données d'un autre client.
Vos instructions cachées fuitent mot pour mot : la carte de toutes les attaques suivantes.
Une règle glissée au cours d'un échange modifie silencieusement chaque réponse ultérieure, longtemps après que la conversation a repris un air normal.
Vous ne pouvez pas déposer un document dans une base de connaissances où vous n'avez pas le droit d'écrire, et de l'extérieur vous ne pouvez pas distinguer un appel d'outil réellement exécuté d'un appel que le bot a seulement décrit, une distinction que les bots eux-mêmes confondent, nous l'avons mesuré. Cela demande le corpus, les définitions des outils, ou la visibilité des appels. Mesuré sur les preuves livrées avec cet outil : 62 constats sur 137, sur des cibles qui rapportent leurs appels d'outils, n'apparaissent pas du tout si l'on ne lit que la réponse. Le bot répond poliment et place le secret dans un argument d'appel.
Votre agent est convaincu d'effectuer une action irréversible : supprimer, rembourser, envoyer un e-mail.
Du SQL ou une commande shell glissés dans un appel d'outil. Une vieille classe de bugs, une nouvelle porte d'entrée.
Un seul document malveillant dans votre RAG détourne les réponses à des questions anodines.
Une ligne cachée dans la description d'un outil amène votre agent à divulguer des données alors qu'on lui pose une question ordinaire, sans aucun message d'attaquant.
qatration init écrit la configuration pour vous : l'URL, la forme de la requête, et où se trouve la réponse du bot dans la charge utile renvoyée. Une cible distante réclame en plus un en-tête d'authentification, en variable d'environnement. Configurations prêtes à l'emploi pour les API au format OpenAI et pour celles d'Anthropic, de Bedrock et de Vertex. qatration onboard envoie une question ordinaire et vous dit ce qui manque avant que la moindre attaque ne soit envoyée.
qatration init génère un secret qui vous appartient et le bloc à coller dans votre prompt système. L'exécution confirme d'abord qu'il a bien été implanté : un canari non placé signifie qu'aucun contrôle ne trouve quoi que ce soit, et cela ressemble exactement à un bot qui a tenu.
Ce qui a été divulgué, comment exactement, et l'unique correctif qui referme la brèche, le tout rédigé pour une équipe sans expert en sécurité. --fail-on exploited fait échouer un build. qatration sarif place les constats directement dans votre onglet code scanning.
Une attaque qui a échoué rapporte un zéro. Un contrôle qui n'a pas pu s'exécuter en rapporte un aussi, et un bot réellement durci également, et c'est là que les tests s'enlisent : trois faits différents arrivent sous une apparence identique, et personne ne sait quoi essayer ensuite. Ce sont des mesures issues d'exécutions réelles, pas des extrapolations.
Et une brèche n'est une brèche que si l'attaque l'a causée. Chaque cible reçoit d'abord une exécution inoffensive : des questions ordinaires, personne n'attaque. Sur l'un des bots présentés ici,
canary_in_tool_call se déclenche sur 88 % de ce trafic ordinaire, si bien qu'un constat qui repose sur lui seul est marqué comme non attribuable au lieu d'être compté.
Quand une attaque échoue, le rapport nomme ce qui l'a arrêtée : le contrôle d'identité, le filtre de contenu, une permission côté serveur, ou un appel d'outil seulement affiché et jamais réellement exécuté. Ce dernier ressemble à une brèche dans une transcription et ne vaut rien.
Un bot, deux modèles, 254 attaques chacun, 3 essais chacune. Le plus petit a cédé sur 27 d'entre elles, le plus grand sur 24, et 18 de celles-là sont les mêmes attaques, dont 17 ont fait céder les deux modèles à chaque essai. Sur ce bot, le modèle le plus grand a changé, à la marge, quelles attaques passent. Il ne referme pas le trou.
Face à un véritable framework de guardrails, 46 attaques tapées dans le champ de saisie du chat : aucune n'est passée. Une attaque portée à l'intérieur d'un document récupéré n'est pas passée non plus, tant que ses deux garde-fous étaient actifs. Coupez le filtre de sortie et ce même document ressort à chaque essai. Les filtres d'entrée lisent ce que tape l'utilisateur, et ne voient jamais ce que votre base de connaissances remet au modèle, si bien que le garde-fou d'entrée n'a jamais été ce qui l'arrêtait.
Nous avons renvoyé les mêmes messages à ce garde-fou et il n'était pas toujours d'accord avec lui-même : cinq formulations ont reçu des verdicts différents pour une entrée identique, et une question ordinaire a été autorisée dix fois sur douze. Nous rapportons donc combien d'essais ont cassé quelque chose, et non si un seul l'a fait. Une exécution unique raconte un seul après-midi, et cela vaut autant pour un résultat propre que pour un mauvais, y compris le nôtre.
Le même garde-fou qui a bloqué ce document a aussi refusé de répondre à 6 questions client ordinaires sur 9 portant sur les sujets concernés. Une défense qui répond « non » à vos clients est un chiffre que vous voulez connaître avant la mise en production, pas après.
Un scanner qui trouve toujours quelque chose ne vaut rien, alors nous avons mesuré le chiffre inverse : 1 500 sondes inoffensives sur 30 cibles, sans le moindre attaquant, à travers les mêmes contrôles. La moitié sont des utilisateurs qui parlent de sécurité en toute légitimité, car c'est exactement ce qui met en échec une détection par motifs : un développeur qui colle la requête qui échoue, un agent du support qui transfère une trace de pile, quelqu'un qui demande si un domaine sosie est authentique.
Les bots écrits ici sont le cas facile, il a donc été dirigé vers un framework d'agents que personne ici n'a conçu. Il a produit huit fausses alertes en une exécution de 48 prompts propres, dans quatre catégories que 480 sondes contre notre propre parc n'avaient jamais produites une seule fois. Les quatre sont corrigées, et les deux règles sous-jacentes font désormais échouer notre build plutôt que votre rapport : aucun contrôle n'a le droit de lire la question, et aucun contrôle n'a le droit de traiter les propres mots de l'agent comme une preuve concernant le système.
Exécuté contre les mêmes cibles tierces que garak et promptfoo, chaque réponse des trois étant notée par une unique règle de sous-chaîne plutôt que par le juge propre à chaque outil. Sur une application RAG sans aucun garde-fou, 46 % des sondes inoffensives renvoient déjà la chaîne déposée, si bien que compter les constats mesure l'application et non l'attaquant. L'un des trois outils le dit dans son rapport. Sur la cible protégée, les trois obtiennent zéro selon la règle commune, et nous avons été les seuls à trouver quoi que ce soit, une brèche sur 324, alors que ce même déploiement refuse de répondre à 38 questions client ordinaires sur 48. La comparaison publie aussi les points où les deux autres font mieux, ainsi qu'une affirmation que nous avons retirée après qu'un relecteur a demandé une valeur p. Lire la comparaison.
Un profil de douze sondes, toutes inoffensives : cinq bots ont livré leurs propres instructions à une simple demande. L'un a affiché sa clé de session confidentielle à l'intérieur de la phrase même qui lui interdisait de la partager. Deux ont signalé le redémarrage d'une base de données alors qu'ils n'avaient aucun outil capable de redémarrer quoi que ce soit.
Chaque exécution est conservée, si bien que chaque constat porte la date de sa première apparition. « Critique » est une opinion. « Critique et ouvert depuis le trois » est un fait sur la manière dont une équipe réagit à ces constats, et c'est cette ligne qui fait planifier un correctif.
Un constat qui revient après que vous l'avez clos est signalé comme réapparu, et non compté discrètement parmi les nouveaux. Un correctif qui n'a pas tenu est la plus désagréable des deux conversations, et les mélanger la dissimule.
Si une attaque n'est pas envoyée lors d'une exécution, elle figure au rapport comme non testée, jamais comme corrigée. L'absence n'est pas un résultat propre, et un rapport qui confond les deux vous annonce que vos vulnérabilités ont disparu alors que personne n'a regardé.
Certains appels remettent à un outil une valeur qui n'apparaît dans aucun texte que nous puissions lire. Nous les listons à part et vous indiquons quel journal les ouvre, car la différence entre « nous avons vérifié et c'était propre » et « nous n'avons pas pu voir » est la différence entre une mesure et une promesse.
« Nous lui avons dit de ne pas révéler de secrets » est une affirmation, pas une défense : sur les cibles présentées ici, elle est tombée dès les premières attaques. QAtration déclare également propres les bots réellement verrouillés, si bien qu'un résultat propre signifie vraiment quelque chose. Il mesure votre bot au lieu de crier au loup à chaque fois.
Apache 2.0. Installez-le, dirigez-le vers votre propre déploiement, gardez les preuves.