Test d'intrusion de l'équipe rouge d'Agent et OWASP LLM01

Pourquoi les agents modifient les mathématiques d'injection

De la sortie à l'action

Dans un chatbot pur, l'objectif d'une injection est de faire dire au modèle quelque chose qu'il ne devrait pas dire. L'impact s'arrête au texte qui quitte le modèle. Lorsque le même modèle peut invoquer un outil, le texte injecté peut devenir une commande que l'outil exécute. Un attaquant qui peut diriger un outil de lecture de fichiers pour extraire un document confidentiel ou un outil d'envoi de courriels pour transmettre ce document a transformé un astuce de formulation en violation de données. La gravité dépend donc de ce que l'outil peut faire, et non de la malice de la réponse.

La portée de l'outil définit le rayon de blast

Le rayon de blast est l'union de toutes les ressources que les outils de l'agent peuvent toucher. Si l'agent n'a qu'une API en lecture seule pour un blog public, le pire des cas est la fuite d'informations publiques. Si l'agent peut appeler un outil d'écriture de base de données, un outil de suppression de fichiers ou un portail de paiement externe, la même injection pourrait effacer des enregistrements, modifier des soldes ou déplacer de l'argent. Les travaux de l'équipe rouge doivent cartographier chaque outil avec les magasins de données, les services ou le matériel qu'il peut affecter, puis tester si une injection peut atteindre ces actifs.

Conceptions erronées courantes

- En supposant que la limite de longueur de sortie du modèle limite les dégâts - faux, car une courte chaîne peut déclencher un appel d'outil destructeur. - En croyant que le filtrage du message de l'utilisateur est suffisant - faux, car les injections peuvent arriver à l'intérieur des résultats de l'outil ou des invites du système. - En pensant qu'un modèle à faible paramètre est sécurisé - faux, lorsque ce modèle est associé à un ensemble d'outils puissants.

Pour une référence rapide sur la programmation défensive, voir la feuille de triche OWASP sur la prévention des injections de requêtes LLM.

Surfaces à sonder au-delà de la boîte de chat

Invite de système et configuration

L'invite de système contient souvent des clés API, des URL de service ou un langage de politique interne. Un attaquant qui peut injecter dans cette zone peut obtenir des informations d'identification directes ou apprendre où pointer d'autres sondes. Examinez l'invite pour toute secret statique et testez si elles peuvent être échoées ou exfiltrées via un appel d'outil.

Schémas d'outils et validation des arguments

Chaque outil exposé définit un schéma JSON pour ses entrées. Si le schéma accepte des chaînes libres sans validation stricte, un attaquant peut intégrer des commandes à l'intérieur de ces chaînes. Par exemple, un outil « exécuter_sql » qui prend une chaîne de requête brute est vulnérable à l'injection SQL à moins que la couche d'agent ne nettoie ou ne paramètre l'entrée. Vérifiez si l'agent impose des limites de type, des plafonds de longueur ou des listes autorisées pour chaque argument.

Pipelines de génération augmentée de récupération (RAG)

Lorsque l'agent récupère des données à partir de sources externes - pages Web, courriels, systèmes de tickets -, ces données deviennent partie du contexte du modèle. Un attaquant qui contrôle l'une de ces sources peut placer des instructions que le modèle traitera plus tard comme fiables. Sondez en empoisonnant une source de alimentation externe connue et en regardant si l'agent agit sur la commande cachée.

Propagation d'instructions à l'intérieur des résultats de l'outil

Certaines conceptions renvoient les résultats de l'outil directement dans l'appel de modèle suivant sans ré-sanitiser. Si un outil renvoie un morceau de texte qui inclut une nouvelle instruction, le modèle peut obéir à cette instruction à l'étape suivante. Cela crée une injection à deux étapes où la première étape est des données inoffensives et la deuxième étape est la commande malveillante. Testez chaque chemin de sortie d'outil pour voir si l'agent ré-alimente les résultats bruts dans le générateur d'invite.

Check-list pratique

- Extraire l'invite de système et rechercher des secrets codés en dur. - Répertorier chaque outil, notez son schéma et tentez de passer des types de données inattendus. - Identifiez toutes les sources de données externes utilisées pour RAG et injectez des marqueurs inoffensifs pour vérifier la portée. - Capturez les résultats de l'outil et ré-alimentez-les en tant que nouvelles entrées pour voir si l'agent les traite comme des commandes. - Documentez toute chaîne où un seul message de l'utilisateur conduit à plusieurs invocations d'outils.

Pour une comparaison avec les défenses classiques d'injection, la feuille de triche SQL d'injection offre des modèles utiles : OWASP A03:2021 - Injection.

Le risque d'une agence excessive est le risque associé

Ce que signifie une agence excessive

OWASP place l'Agence excessive à LLM03 pour 2026. Elle décrit les agents qui peuvent effectuer des actions irréversibles - envoyer un e-mail, supprimer des fichiers, exécuter du code - sans une étape d'approbation séparée. Le risque augmente lorsque l'autonomie du modèle dépasse les garanties entourant ses outils.

Domaines de concentration de l'équipe rouge

- Vérifiez si les outils destructeurs nécessitent une confirmation explicite d'un humain ou d'un service séparé. - Essayez de chaîner deux outils ou plus ensemble en utilisant uniquement les sorties intermédiaires générées par le modèle. - Voir si l'agent peut augmenter ses propres privilèges, par exemple en appelant un outil qui met à jour sa propre clé API. - Testez les déclencheurs basés sur le temps : peut-on utiliser un appel d'outil retardé pour contourner une limite de taux ou une expiration de session ?

Matrice de risque illustrative

Catégorie d'outil | Privilège typique | Confirmation nécessaire | Abus potentiel si manquant Lecture de fichier | Accès en lecture seule aux dossiers désignés | Aucun (la lecture est généralement sûre) | Exfiltration de journaux, de code source, de configuration Écriture de fichier | Créer ou écraser des fichiers | Oui - approbation de l'utilisateur ou demande signée | Insertion de portes dérobées, corruption de données Écriture de base de données | INSERT/UPDATE/DELETE sur des tables | Oui - approbation de transaction ou authentification multifacteur | Perte de données, fraude financière, élévation de privilèges HTTP externe | Réseau sortant vers des domaines arbitraires | Oui - vérification de liste d'autorisation | Exfiltration de données, balise C2, SSRF Exécution de code | Interpréteur ou shell arbitraire | Oui - bac à sable isolé + approbation | Compromission complète de l'hôte, déploiement de rançongiciel

Le tableau montre pourquoi une équipe rouge doit vérifier chaque ligne : si la colonne de confirmation est manquante, l'agent peut passer de bénin à nocif avec une seule entrée empoisonnée.

Ce que devrait contenir un rapport de sonde

Champs essentiels

Une découverte utile nécessite plus qu'un simple « pass/fail » booléen. Enregistrez l'énoncé exact de l'utilisateur qui a déclenché la chaîne, la liste ordonnée des outils que l'agent a appelés et l'effet observable final (par exemple, un fichier écrit, une requête réseau envoyée, une ligne de base de données modifiée). Incluez les arguments de l'outil bruts tels qu'ils ont été envoyés et la trace de raisonnement interne du modèle si votre framework l'expose.

Orientations de gravité

- Faible - fuite d'informations publiques ou modification d'état réversible. - Moyen - accès à des données internes non réglementées ou action réversible qui nécessite un réinitialisation manuelle. - Élevé - modification de données réglementées, transaction financière ou exécution de code arbitraire. - Critique - porte dérobée persistante, destruction de données ou capacité à maintenir une prise après la fin de la session.

Priorisez les correctifs pour les éléments de gravité élevée et critique en premier ; les éléments de faible gravité peuvent être traités dans un sprint de durcissement ultérieur.

Conseils de remédiation actionnables

- Ajoutez une validation au niveau du schéma qui rejette les chaînes contenant des mots-clés SQL ou des métacaractères de shell. - Enveloppez les outils destructeurs dans un microservice qui exige un jeton d'approbation signé. - Mettez en œuvre une liste d'autorisation de sortie pour les appels HTTP sortants et enregistrez chaque tentative de connexion. - Sanitisez les sorties d'outil avant de les réinsérer dans l'invite du modèle - supprimez ou échappez tout contenu qui ressemble à une instruction. - Utilisez une réplique en lecture seule pour tout outil de requête de base de données, sauf si une écriture est explicitement requise.

Le red teaming ne remplace pas les contrôles de conception

Pourquoi les tests complètent, mais ne remplacent pas, les garanties

Le travail de red team découvre les lacunes qui existent déjà dans la mise en œuvre. Il ne crée pas les garanties qui découlent de la conception d'outils avec les privilèges minimum, des portes de confirmation, ou de la segmentation du réseau. Traitez chaque test comme une étape de validation : si les contrôles arrêtent la chaîne injectée, vous avez la preuve qu'ils fonctionnent ; si ce n'est pas le cas, vous avez un défaut concret à corriger.

Contrôles à prioriser

- Exécutez chaque outil sous un utilisateur OS dédié avec un ensemble minimal de capacités de système de fichiers. - Exigez un service d'approbation distinct pour chaque appel qui peut modifier l'état, enregistrez la décision et imposez un délai d'attente. - Appliquez des stratégies de réseau qui limitent les connexions sortantes aux services internes connus et à une courte liste d'API externes. - Chiffrez les secrets au repos et ne les placez jamais dans la invite de système ; utilisez un service de coffre-fort à la place. - Enregistrez chaque invocation d'outil avec l'ID utilisateur, l'horodatage, le hachage de l'entrée et le hachage de la sortie pour l'examen forensique.

Lorsque ces contrôles sont en place, les résultats du red team passent de « nous avons trouvé un moyen de le casser » à « nous avons tenté X et les contrôles les ont bloqués », ce qui est un signal plus fort de maturité de la sécurité.

Ce que ce n'est pas

Aucune garantie d'exhaustivité

Ce guide ne promet pas que suivre les étapes permettra de détecter toutes les injections possibles. Les techniques nouvelles, les vulnérabilités des outils zero-day ou les fonctionnalités des agents non divulguées peuvent échapper aux vérifications décrites ici.

Pas de solution à 100 %

L'application des atténuations réduit les risques mais ne les élimine pas. La défense en profondeur nécessite une surveillance continue, des examens réguliers de la chaîne d'outils et des mises à jour lorsque de nouvelles versions d'OWASP sont publiées.

La revendication de ne jamais manquer une faille est fausse

Aucune méthode de red team ne peut prétendre ne jamais manquer une faille. L'objectif est d'augmenter le coût pour un attaquant et de rendre l'exploitation réussie visible et traçable.

Pas de remplacement de la programmation sécurisée

Les recommandations supposent que vous suivez déjà les pratiques de programmation sécurisée de base - validation des entrées, encodage des sorties et principe du privilège minimum. Elles ajoutent des couches spécifiques à l'agent sur cette base.

Références

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection

Articles liés

- Tests d'abus d'outils pour les agents LLM - Explorez la matrice complète du sujet micro-SaaS IA →