Article · IA & agents
Sécuriser les outils d’un agent : commencer par les permissions
Une méthode de cadrage pour relier chaque outil d’agent à une permission, une donnée et une procédure de révocation.
Un outil est une capacité, pas une simple fonction
Un agent qui peut lire un fichier, appeler une API et écrire dans un dépôt possède trois capacités différentes. Les réunir derrière un bouton « exécuter » rend la revue difficile : on ne sait plus quelle donnée sort, quelle action est irréversible ni quel compte porte le risque.
Commencez par une phrase : « l’agent doit produire X à partir de Y ». Tout ce qui n’est pas nécessaire à cette phrase reste hors périmètre. Cette discipline rejoint les recommandations de l’OWASP LLM Top 10 sur l’excès d’autorité et la manipulation des appels d’outils.
Faire la carte des accès
Pour chaque outil, consignez le verbe (lire, créer, modifier, supprimer), la ressource, le compte, le domaine réseau, la durée du jeton et le journal produit. Séparez lecture et écriture. Une clé qui ne sert qu’à lire un catalogue ne doit pas pouvoir supprimer un projet.
Testez aussi les réponses inattendues. Le texte renvoyé par un outil peut contenir une instruction malveillante ; il doit rester une donnée à analyser. Aucun résultat externe ne doit pouvoir étendre les permissions ou demander un secret absent du contrat initial.
Commencer en lecture seule
Le premier prototype devrait lire un jeu de données sans caractère sensible et produire un rapport local. Ensuite seulement, ajoutez une écriture réversible, avec confirmation humaine et journal de l’avant/après. Les opérations destructrices doivent exiger un identifiant explicite de ressource et un second contrôle.
Prévoyez la révocation avant la mise en service : où désactiver la clé, qui reçoit l’alerte, comment vérifier qu’aucun jeton n’est encore accepté ? Un accès impossible à retirer est une dette opérationnelle, même si l’agent fonctionne parfaitement.
Vérifier avant de déléguer
Faites un test d’autorisation par outil : accès autorisé, accès refusé, ressource hors périmètre, erreur réseau et réponse contenant une consigne parasite. Conservez les journaux sans recopier les secrets. Le test est réussi si l’agent échoue de façon compréhensible et ne tente pas une action de secours plus puissante.
Le parcours peut ensuite s’appuyer sur MCP sans exécuter de code non vérifié et sur le protocole d’évaluation d’un outil IA. Ces articles décrivent le raisonnement ; ils ne remplacent pas une revue de votre configuration réelle.
Sources et limites
Références vérifiées le 21 septembre 2026 : OWASP LLM Top 10 et NIST AI RMF. Aucun connecteur ni serveur tiers n’est recommandé ici.