Sécuriser les agents d’IA : injection de requêtes, autorisations des outils et moindre privilège

Un robot conversationnel qui donne une mauvaise réponse, c’est embarrassant. Un agent qui suit une instruction malveillante cachée dans un courriel, puis transfère vos fichiers, c’est une atteinte à la sécurité. À mesure que les systèmes d’IA acquièrent la capacité d’agir, leur modèle de sécurité doit changer.

Le Top 10 de l’OWASP pour les applications de grands modèles de langage (édition 2025) classe l’injection de requêtes au premier rang et place l’autonomie excessive — c’est-à-dire le fait d’accorder à un modèle plus d’autorisations ou d’autonomie que la tâche ne l’exige — parmi les principaux risques. Les deux sont liés : l’injection est le moyen par lequel un attaquant oriente le modèle, et l’autonomie détermine l’ampleur des dommages que cette manipulation peut causer.

Pourquoi l’injection de requêtes est difficile à « corriger »

Les modèles de langage ne séparent pas de façon fiable les instructions des données. Si un agent lit une page Web, un PDF ou un courriel entrant, le texte contenu dans ce contenu peut ressembler à une instruction. Les filtres aident, mais aucun n’est parfait. L’approche pratique consiste à supposer qu’une partie des injections passera et à concevoir le système de sorte qu’elles ne puissent pas causer de tort grave.

Six contrôles qui limitent le rayon d’impact

1. Moindre privilège pour les outils. Ne donnez à chaque agent que les outils et les portées dont sa tâche a besoin. Un agent de synthèse a besoin d’un accès en lecture, et non d’un droit d’envoi ou de suppression.

2. Identités distinctes. Exécutez les agents sous leurs propres identités de service, avec leurs propres autorisations, et non avec la session complète d’un utilisateur. Leurs actions restent ainsi vérifiables et révocables.

3. Approbation humaine pour les actions lourdes de conséquences. Les paiements, les courriels externes, la suppression de données et les modifications d’autorisations devraient exiger la confirmation d’une personne, l’action proposée étant présentée en langage clair.

4. Traiter les résultats du modèle comme des entrées non fiables. Validez tout ce que produit le modèle avant que cela n’atteigne un autre système : paramètres, URL, code et SQL. Les règles que vous appliquez aux entrées des utilisateurs s’appliquent ici aussi.

5. Restreindre ce qu’il peut atteindre. Limitez les destinations réseau sortantes et les sources de données que l’agent peut interroger. De nombreuses voies d’exfiltration reposent sur la capacité de l’agent à récupérer du contenu depuis l’URL d’un attaquant ou à y publier des données.

6. Journaliser et surveiller. Consignez les requêtes, le contenu récupéré, les appels d’outils et les approbations. Déclenchez des alertes en cas de comportement inhabituel, comme une hausse soudaine des appels d’outils ou un accès à des données hors de la portée normale de l’agent.

Tester comme un attaquant

Avant le lancement, et après chaque changement important, effectuez des tests contradictoires : documents contenant des instructions cachées, courriels demandant à l’agent de révéler sa requête système, demandes d’appel d’outils hors de son rôle. Conservez ces cas dans votre suite d’évaluation afin que les régressions soient détectées automatiquement.

Le principe

Partez du principe que le modèle peut être persuadé. La sécurité découle de ce que l’agent est autorisé à faire, et non de ce qu’on lui dit de faire.

Notre pratique Logiciel et IA conçoit des agents qui intègrent ces contrôles dès le départ, et évalue les fonctionnalités d’IA existantes au regard de ceux-ci.