Faire du red teaming sur un flux de travail d'agent avant de lui accorder des permissions réelles

Objectif

Découvrir ce qu'une partie attaquante peut faire faire à l'agent par le biais des entrées qu'il traite, avant que l'agent ne détienne des permissions qui rendraient la réponse coûteuse, et transformer chaque constat en test de non-régression.

Prérequis

Une copie de pré-production de l'agent avec ses outils réels pointés vers des cibles jetables ; des journaux d'exécution rejouables ; une liste des entrées de l'agent : messages de l'utilisateur, documents récupérés, pages web, résultats d'outils, fichiers de mémoire, noms de fichiers. L'antisèche OWASP sur la prévention de l'injection de prompt LLM catalogue des classes d'attaque (injection directe et distante/indirecte, encodage et obfuscation, empoisonnement de RAG, attaques spécifiques aux agents) et des défenses (prompts structurés avec séparation claire, validation des sorties, contrôles avec intervention humaine, moindre privilège). Des scanners comme garak exécutent des bibliothèques de sondes pour l'injection de prompt, la fuite de données, les jailbreaks et d'autres faiblesses contre un modèle de langage.

Étapes

1. Établir la liste des menaces par entrée : pour chaque endroit où du contenu non fiable pénètre, quel est le pire appel d'outil qu'il pourrait déclencher (envoyer, supprimer, payer, exfiltrer via un paramètre d'URL, écrire un fichier de mémoire) ?
2. Implanter des charges utiles dans chaque entrée : une instruction dans un document récupéré, dans le texte caché d'une page web, dans un nom de fichier, dans un résultat d'outil, dans un message de commit. Varier la forme : en clair, encodée, répartie sur plusieurs blocs, dans une autre langue.
3. Exécuter des sondes scriptées avec un scanner contre l'interface exposée au modèle, puis des tentatives manuelles contre l'ensemble du flux de travail, car les échecs intéressants impliquent des chaînes d'outils.
4. Tenter l'exfiltration spécifiquement : peut-on amener l'agent à inclure une donnée secrète ou privée dans une URL qu'il récupère, un message qu'il envoie ou un fichier qu'il écrit dans un emplacement partagé ?
5. Tenter l'épuisement : des entrées qui font boucler l'agent, qui lui font appeler des outils des milliers de fois, ou qui remplissent son contexte.
6. Consigner chaque tentative avec le journal d'exécution : charge utile, emplacement, ce que l'agent a fait, si une barrière ou le bac à sable l'a arrêté.
7. Corriger d'abord au niveau de la frontière (retirer la capacité, la soumettre à une barrière, restreindre le réseau, valider les arguments), puis améliorer le prompt, puis ajouter la charge utile au jeu d'évaluation comme test permanent.
8. Répéter après chaque nouvel outil ou nouvelle source d'entrée.

Résultat attendu

Un tableau mettant en regard les entrées et la pire action obtenue, chaque constat accompagné d'une correction au niveau de la frontière et d'un test de non-régression, et un risque résiduel documenté pour ce que seul le prompt défend.

Limites et base de vérification

Les défenses au niveau du prompt sont probabilistes ; une charge utile qui échoue aujourd'hui peut réussir après une mise à jour du modèle, ce pourquoi les constats deviennent des tests. L'exercice trouve ce que l'équipe a pensé à essayer ; un scanner élargit la couverture mais ne connaît pas les outils de l'application. Aucun résultat n'est revendiqué ici pour un agent particulier.