if ( !emtpy($headline_subheadline ) ) : ?>
Les failles LLM les plus dommageables s’arrêtent rarement à une réponse dangereuse. Ils se retrouvent dans les systèmes de récupération, les contrôles d’identité, les outils, les pipelines de données et les transactions commerciales. Une évaluation utile suit ce chemin complet.
endif; ?>
L’IA générative est allée bien au-delà du chatbot autonome. Désormais, il rédige du code, recherche dans les connaissances internes, examine les contrats, ouvre des dossiers de support et, dans certains déploiements, prend des mesures via des outils connectés. Ce rôle plus large change la question de la sécurité. Un testeur ne recherche plus seulement un modèle qui dira quelque chose qu’il ne devrait pas dire. La véritable préoccupation est de savoir si un langage manipulé peut atteindre des données protégées ou déclencher une action commerciale non autorisée.
Cela rend une application LLM plus proche d’un graphique d’attaque que d’un seul point de terminaison. Les invites, les services de récupération, les bases de données vectorielles, les identités, les plug-ins, les passerelles de modèles et les API en aval influencent tous le résultat final. Un test Web conventionnel reste important, mais il manquera les itinéraires propres aux systèmes dans lesquels les instructions et les données arrivent par le même canal.
Commencez par l’application, pas par le modèle
Un engagement utile commence par une visite guidée de l’architecture. Documentez les invites du système et du développeur, les points de terminaison du modèle, les modèles de secours, la couche de récupération, le service d’intégration, le magasin de vecteurs, la mémoire, les définitions d’outils, la passerelle API, les contrôles de modération, les secrets, les étapes d’approbation et la journalisation. Marquez chaque endroit où le contenu change de niveau de confiance ou où un composant transmet l’autorité à un autre.
Cette carte expose les chemins qui méritent d’être testés. Un document téléchargé par un utilisateur ordinaire peut ultérieurement devenir un contexte de récupération fiable pour un cadre. Une réponse de modèle peut être traitée comme un paramètre pour une requête SQL ou une API de remboursement. Un résultat d’outil peut être renvoyé au modèle sans filtrage. Aucune de ces transitions ne semble dangereuse lorsqu’elle est considérée isolément ; la chaîne est ce qui crée l’exploit.
Les directives actuelles de l’OWASP sur l’injection rapide distinguent la manipulation directe par un utilisateur des instructions indirectes cachées dans le contenu externe. Il note également que la génération augmentée par récupération (RAG) et le réglage fin ne suppriment pas le risque sous-jacent. En pratique, cela signifie que la surface de test comprend les e-mails, les tickets, les pages Web, les PDF, les référentiels de code, les feuilles de calcul et tout autre contenu que l’application peut lire.
Établissez des règles qui empêchent le test de devenir un incident
Les systèmes agents peuvent produire des effets secondaires lors des tests. Ils peuvent envoyer un message, modifier un enregistrement, appeler un service externe, exposer des données réglementées ou consommer une quantité surprenante d’inférences payantes. Les règles d’engagement doivent donc nommer les locataires approuvés, les identités de test, les modèles, les limites de taux, le plafond de coût, les outils autorisés et les conditions d’arrêt d’urgence. Les fonctions destructives appartiennent à un simulateur ou à un environnement jetable.
Utilisez des canaris au lieu de vrais secrets. Créez des enregistrements clients synthétiques, des clés API leurres et des expressions spécifiques aux locataires faciles à reconnaître dans les journaux. Définissez le succès avant le début de la campagne : récupérer un canari d’un autre locataire, appeler un outil sans approbation, modifier une valeur de transaction protégée, conserver une instruction en mémoire ou provoquer une condition d’épuisement de ressources mesurable. Le refus d’un jailbreak évident n’est pas un critère de réussite significatif.
Considérez l’injection rapide comme une campagne
Les invites à un tour telles que « ignorer les instructions précédentes » sont des tests de fumée utiles, mais les attaquants expérimentés ne dépendent pas d’une seule phrase. Les testeurs doivent varier la langue, le formatage, l’encodage, le jeu de rôle, l’Unicode, les pièces jointes et l’historique des conversations. Ils doivent également répartir l’intention sur plusieurs tours, car les contrôles qui bloquent une demande explicite peuvent échouer lorsque l’objectif est assemblé progressivement.
Les tests d’évasion de modèle doivent poser une question pratique : l’attaquant peut-il conserver l’objectif nuisible tout en modifiant sa forme de surface ? Essayez les paraphrases, les traductions, le placement dans un contexte long, les documents cités, les instructions imbriquées et le contenu qui prétend provenir d’un flux de travail fiable. Répétez le même objectif après un résumé de session, une compression de contexte, un repli de modèle ou une erreur d’outil. Ces changements d’état modifient souvent l’instruction prioritaire.
La découverte la plus forte relie l’injection à un effet observable. Un document empoisonné peut-il obliger l’assistant à récupérer un deuxième document restreint ? Un robot d’assistance peut-il transmettre un montant de remboursement modifié à un outil ? Le SQL généré par le modèle, le texte shell, le HTML ou un paramètre API peuvent-ils atteindre un interpréteur sans validation déterministe ? Le rapport doit montrer la chaîne complète, y compris l’identité utilisée, les enregistrements récupérés, les arguments de l’outil et le changement d’état qui en résulte.
La taxonomie d’apprentissage automatique contradictoire 2025 du NIST fournit un cadre solide pour ce travail car elle organise les attaques par type de modèle, étape du cycle de vie, objectif de l’attaquant, capacité et connaissances. Cette perspective plus large empêche l’évaluation de regrouper chaque problème GenAI sous l’étiquette « jailbreak ».
Testez les bases de données RAG et vectorielles comme contrôles de sécurité
Un système RAG introduit une autre couche de décision : quel contenu le modèle voit. Même un modèle bien élevé peut produire une réponse compromise lorsque le pipeline de récupération fournit un contexte empoisonné ou non autorisé. L’évaluation doit couvrir l’ingestion, l’analyse, le découpage, l’intégration, l’indexation, les métadonnées, la construction de requêtes et les filtres d’autorisation.
Commencez par un empoisonnement contrôlé. Insérez un document synthétique contenant une instruction cachée et observez si le pipeline l’indexe, la récupère et la suit. Déplacez l’instruction dans le texte visible, les métadonnées, les commentaires, le texte blanc sur blanc, les couches OCR, les cellules de la feuille de calcul et les commentaires du code source. Mesurez la cohérence avec laquelle l’objet empoisonné apparaît pour les requêtes ciblées et s’il reste récupérable après la modification ou la suppression de la source.
Les tests d’isolement sont tout aussi importants. Créez deux locataires ou groupes de sécurité avec des faits Canary distincts, puis émettez des requêtes sémantiquement similaires des deux côtés. Inspectez les identifiants des documents récupérés, pas seulement la prose finale. L’autorisation doit limiter l’ensemble de récupération avant que le contenu sensible n’entre dans le contexte du modèle. Testez les métadonnées vides, les filtres mal formés, les différences de casse, les valeurs génériques, les caches de contrôle d’accès obsolètes et les modifications d’autorisation effectuées après l’indexation.
Les directives de vecteur et d’intégration de l’OWASP dénoncent les accès non autorisés, les fuites entre contextes, l’inversion d’intégration et l’empoisonnement des données. Il recommande des magasins prenant en compte les autorisations, un partitionnement logique, une validation des sources et des journaux de récupération immuables détaillés. Ces recommandations se traduisent parfaitement par des assertions de tests d’intrusion : prouver que le filtre ne peut pas être contourné, que le contenu non fiable est traçable et que chaque récupération sensible peut être reconstruite.
Suivez le pipeline ML en amont
Certains compromis se produisent avant l’inférence. Examinez les données de formation et de réglage fin, les blocs-notes, le code d’intégration, les registres de modèles, le stockage d’objets, les flux de travail CI/CD, les adaptateurs, les dépendances de packages et les manifestes de déploiement. Testez si un utilisateur non autorisé peut remplacer un ensemble de données, modifier un ensemble d’évaluation, publier une nouvelle version de modèle ou modifier l’invite et l’ensemble de stratégies déployés.
Pour les composants de ML prédictif, des exemples contradictoires limités peuvent révéler une évasion proche des seuils de décision. Pour les systèmes génératifs, utilisez l’empoisonnement contrôlé dans un corpus de non-production et mesurez si un comportement ciblé survit au recyclage, à la réindexation ou à la restauration. Les hachages d’artefacts, les signatures et la séparation des tâches doivent être testés et non acceptés à partir d’un diagramme. Une restauration fiable doit également restaurer les invites, l’index de récupération, la politique de l’outil et la version du modèle en une seule version cohérente.
Les secrets méritent leur propre piste d’essai. Recherchez dans les blocs-notes, les modèles d’invites, les variables d’environnement, les traces et les journaux de modèles les informations d’identification ou le contexte sensible. Utilisez des leurres lorsque vous tentez une extraction. Les preuves doivent démontrer le parcours sans copier un véritable secret de production dans le rapport.
Utilisez Python pour rendre l’attaque reproductible
Le sondage manuel est utile pour la découverte, mais il s’agit d’une mauvaise méthode de régression. Un petit harnais Python peut définir un objectif, générer des mutations approuvées, les envoyer via la même interface utilisée par les clients, capturer des traces de récupération et d’outils, évaluer le résultat et conserver les preuves. Le code doit s’exécuter uniquement sur des cibles autorisées et doit s’arrêter en cas d’effets secondaires inattendus.
for case in approved_cases:
for prompt in mutate(case.seed):
result = sandbox.send(
prompt, identity=case.test_identity,
trace=True, max_cost=case.cost_limit,
)
finding = score_outcome(result, case.objective, case.canaries)
evidence.write(case.id, prompt, result, finding)
if finding.critical or result.unexpected_side_effect:
emergency_stop()
Une implémentation de référence publique de cette boucle exécute ces quatre mêmes fonctions sur un RAG local délibérément vulnérable et une cible d’appel d’outils, de sorte que chaque résultat qu’elle rapporte est reproductible en exécutant une suite de tests plutôt qu’en étant affirmé.
Le cadre autour de la boucle compte plus que la boucle elle-même. Gardez les graines et les mutations sous contrôle de version. Enregistrez les versions du modèle et de l’invite, les ID source récupérés, l’identité, les appels d’outils, la latence, l’utilisation du jeton et l’état de la politique. Évaluez des résultats concrets – un enregistrement interdit récupéré, un fichier écrit, un outil appelé ou une approbation contournée – plutôt que de vous fier uniquement à un autre modèle pour juger si une réponse semble dangereuse.
La documentation PyRIT actuelle de Microsoft utilise une conception modulaire comparable construite autour d’ensembles de données, de scénarios, de techniques d’attaque, d’exécuteurs, de convertisseurs, de cibles et de marqueurs. Il est utile pour faire évoluer les campagnes des équipes rouges, mais il ne peut pas déterminer le modèle de menace de l’organisation ni la gravité commerciale d’une découverte. Ce jugement appartient toujours au testeur et au propriétaire du système.
Signalez l’exploitabilité, pas le théâtre
Un rapport solide distingue le mauvais comportement du modèle de la compromission du système. La gravité doit tenir compte de l’accès requis, de la répétabilité, de la persistance, des utilisateurs concernés, de la sensibilité des données, des privilèges de l’outil et de la présence d’une étape d’approbation humaine significative. Une réponse dramatique interdite peut être moins grave qu’une réponse simple qui récupère discrètement le contrat d’un autre locataire.
Le comportement du modèle étant probabiliste, répétez chaque chaîne de matériaux. Signalez le taux de réussite de l’attaque, les tours requis, le coût estimé, le temps d’impact et si le résultat survit à une nouvelle session ou à une révision du modèle. Pour RAG, suivez les récupérations non autorisées et l’influence des documents empoisonnés. Pour les agents, suivez les appels d’outils non autorisés et les échecs de la porte d’approbation. Pour le pipeline ML, enregistrez si les contrôles d’intégrité ont détecté un artefact modifié et empêché la promotion.
Chaque découverte à haut risque devrait devenir un test de régression. Une formulation rapide à elle seule constitue rarement une solution durable. Une remédiation efficace combine généralement des outils de moindre privilège, une récupération basée sur les autorisations, la provenance des sources, la validation des sorties, le sandboxing, des vérifications déterministes des politiques, l’approbation des actions irréversibles, des limites de débit, une surveillance et une restauration testée.
Testez la chaîne chaque fois que la chaîne change
Les tests d’intrusion GenAI doivent commencer avant le lancement et revenir chaque fois que le modèle, l’invite du système, les outils, le corpus de récupération, les règles d’identité ou les autorisations changent. Le livrable final n’est pas une collection d’invites intelligentes. Il s’agit d’un ensemble de chemins reproductibles montrant où le contenu manipulé a franchi une limite de confiance et quelles conséquences commerciales en ont suivi.
L’objectif pratique n’est pas de rendre un modèle de langage impossible à confondre. Ce n’est pas une frontière de sécurité réaliste. L’objectif est de concevoir et de vérifier l’application environnante afin qu’un modèle confus ne puisse pas récupérer ce qu’il ne devrait pas voir, exécuter ce qu’il ne devrait pas contrôler ou changer discrètement l’état de l’entreprise.
