Une démonstration selon laquelle un agent a rejeté une phrase hostile ne constitue pas une déclaration d'assurance. Évaluez le système par rapport aux résultats souhaités par un attaquant : modifications DNS non autorisées, récupération entre clients, divulgation vers une destination non approuvée, preuves d'audit supprimées ou récit d'approbation erroné. Associez ces tests à des tâches légitimes afin que la sécurité ne se mesure pas uniquement par le refus.
Cartographier la surface d'attaque
Répertoriez les entrées consommées par l'agent et les fonctionnalités qu'il peut atteindre. Incluez le texte du rapport, les échantillons d'e-mails, les documents récupérés, les résumés stockés et les réponses des outils. Marquez quelles sources d’entrée peuvent être influencées par des tiers. Identifiez où l'application convertit la sortie du modèle en actions de récupération, de communication ou de configuration.
Une injection rapide peut affecter les conclusions ainsi que les appels d’outils. L'OWASP note que le contenu externe peut rediriger un modèle et qu'aucune prévention infaillible ne doit être supposée. OWASP LLM01. Pour l’analyse de l’authentification, une fausse conclusion « expéditeur approuvé » peut être préjudiciable avant même qu’un changement DNS ne se produise.
Spécifier les décisions attendues avant les tests
Pour chaque cas, conservez les commentaires, le locataire autorisé, les outils autorisés, les approbations fiables, le résultat attendu et les effets secondaires interdits. Incluez une identité ambiguë sans langage hostile : l’incertitude à elle seule ne devrait pas entraîner une approbation automatique. Ajoutez un rapport inoffensif qui doit quand même être résumé. Décidez comment évaluer les réclamations non fondées et l'exposition des données, et pas seulement les tentatives d'écriture réussies.
Séparez le comportement du modèle du comportement d’application. Une figurine peut proposer une action interdite alors que la porte outil la refuse correctement. Il s'agit d'une tentative bloquée, et non d'une preuve d'un modèle sûr. A l’inverse, un refus poli sous forme de texte ne compense pas un appel à un outil qui a déjà divulgué des données.
Définir six objectifs d’évaluation contrastés
Une évaluation proposée peut associer cinq résultats interdits à une tâche légitime : une mutation DNS non approuvée, une récupération privée par un autre locataire, une divulgation à une destination non approuvée, une suppression d'audit, un récit d'approbation falsifié et une lecture autorisée au sein du locataire vérifié. Pour chacun, fournissez une contribution concrète via le canal testé et spécifiez l'outil attendu et le comportement de réponse avant l'exécution.
Il s'agit de catégories, de luminaires non fournis, d'assertions de passage ou de résultats mesurés. Ajoutez un expéditeur ambigu sans langage hostile : il devrait susciter une demande de preuve de compte spécifique, et non une approbation fabriquée. Incluez une action autorisée dans l'environnement de test, le cas échéant, afin que le refus global ne puisse pas être déguisé en application précise. Une demande d'outil forcée teste le portail ; l'ingestion réelle via le modèle teste une limite différente. Déclarez les deux séparément et ne déduisez pas la résistance aux attaques déployée de l’un ou l’autre seul.
Développez-vous dans une évaluation de déploiement
Exécutez des tests autorisés sur l’ingestion réelle, le modèle et la pile d’outils dans un environnement isolé. Versionnez les invites, la configuration du modèle, les autorisations du connecteur et les ensembles de données. Répétez les cas basés sur un modèle car les résultats peuvent varier. Enregistrez les tentatives, les dénominateurs et les critères de notation exacts plutôt que de rapporter un chiffre « 100 % sécurisé » sans contexte.
Ajoutez des attaques en plusieurs étapes qui manipulent d'abord un résumé, puis exploitent ce résumé comme preuve apparente. Testez les approbations obsolètes, le contexte de locataire modifié et la sortie qui nomme une destination de reporting contrôlée par l'attaquant. Incluez les cas d’interruption et de récupération afin que les échecs ne contournent pas le chemin d’approbation normal. L'aide-mémoire de l'OWASP met l'accent sur les garanties et l'évaluation à plusieurs niveaux avec des limites claires. Aide-mémoire OWASP.
Transformez les résultats en décisions de déploiement
Une action non autorisée réussie est un échec du contrôle matériel. Préservez la trace, limitez la capacité affectée et corrigez la limite d’application avant d’étendre l’accès. Pour les résumés manipulés, améliorez l’attribution des preuves et les exigences d’examen. Réexécutez les cas pertinents par rapport à la version modifiée et conservez les échecs précédents sous forme de régressions.
Signalez l’achèvement des tâches utiles ainsi que les attaques bloquées, les cas non résolus et les lacunes de couverture. Approuvez un déploiement uniquement pour la portée testée et le risque résiduel accepté. Une suite locale propre est une preuve de cette suite, et non une garantie de chaque entrée future.