Autorisations des agents d’IA : limiter outils, données et actions au strict nécessaire

L’autorité de l’agent n’est pas celle du système

Un agent peut interpréter une demande, choisir des outils et enchaîner des opérations. Cela ne signifie pas qu’il doit décider des ressources qu’il est autorisé à consulter ou à modifier. L’autorisation effective relève des systèmes qui hébergent les données ou exécutent les actions : le dépôt, le service de messagerie, l’API ou la plateforme d’entreprise. Le modèle peut proposer une opération ; le système cible doit vérifier si l’identité qui la demande peut l’effectuer sur la ressource concernée.

Cette distinction est importante, car l’agent peut se tromper, recevoir des instructions trompeuses ou choisir un outil inadapté. Les instructions du prompt et les règles qui filtrent les outils disponibles peuvent orienter son comportement, mais ne doivent pas constituer l’unique protection. Si un autre chemin permet d’exécuter la même opération avec un identifiant d’accès doté de larges privilèges, le filtrage des outils n’empêche pas l’accès. Il convient donc de combiner les limites imposées dans l’interface de l’agent avec des contrôles d’identité et d’autorisation appliqués par les outils et les services connectés.

L’objectif pratique n’est pas de rendre l’agent incapable de toute erreur. Il s’agit de réduire les conséquences possibles d’une mauvaise interprétation de la tâche : limiter les ressources accessibles, distinguer la lecture de la modification, réduire la durée de l’accès et éviter qu’un seul identifiant d’accès ne transforme une erreur en action de grande ampleur. Les recommandations de ce guide sont des principes de conception ; leur mise en œuvre dépend des capacités et du modèle d’autorisations de chaque plateforme.

Inventorier les tâches, les ressources et les effets avant d’accorder l’accès

Commencez par décrire les tâches que l’agent doit accomplir, et non par dresser la liste de tous les connecteurs qu’il serait possible d’activer. Pour chaque tâche, identifiez qui la demande, quelles données sont nécessaires, quel outil les fournit et quel résultat est attendu. Recensez ensuite les effets potentiels de chaque opération. Consulter un document, le modifier, envoyer un message et supprimer un enregistrement sont des capacités différentes, même si elles sont disponibles via le même service.

Distinguez les données propres à l’utilisateur des données partagées par une équipe ou une organisation. La délimitation doit également porter sur la ressource précise : un agent qui doit lire un dossier de projet n’a pas pour autant besoin d’un accès en lecture à l’ensemble du dépôt. Déterminez aussi si la tâche est effectuée au nom d’une personne ou par une application autonome. Sur les plateformes qui distinguent les autorisations déléguées des autorisations d’application, cette différence influe sur l’identité représentée et sur les limites applicables.

Ne classez pas une opération uniquement en fonction du nom de l’outil. Un appel de « mise à jour » peut modifier un champ sans conséquence particulière ou changer un état qui déclenche des processus ultérieurs. Décrivez l’effet observable et les personnes susceptibles d’être touchées. Si l’impact n’est pas clair, ne supposez pas que l’opération est peu risquée : délimitez sa portée et testez son comportement dans un environnement contrôlé avant de l’activer en production.

Concevoir des profils de moindre privilège selon la tâche et l’utilisateur

À partir de l’inventaire, définissez un profil pour chaque tâche. Précisez l’identité qui l’exécute, les outils qu’elle peut appeler, les ressources concernées, les actions autorisées et la durée de l’accès. Un profil tel que « accès à la messagerie » est trop vague. Un profil utile indique, par exemple, que l’agent peut consulter les messages d’une personne pour préparer un résumé, mais ne peut ni envoyer ni supprimer ou modifier des messages.

Lorsque l’utilisateur doit conserver ses propres limites, une autorisation déléguée peut être plus adaptée qu’un identifiant d’application doté d’un accès autonome et étendu. La documentation de Microsoft Graph distingue les autorisations déléguées, limitées par ce que l’utilisateur peut faire, des autorisations d’application, accordées à l’application. Cette distinction ne supprime pas la nécessité de configurer des autorisations selon le principe du moindre privilège et ne garantit pas, à elle seule, que chaque opération soit correctement délimitée : il faut vérifier les autorisations demandées par l’intégration et la manière dont le système les applique.

Dans certains environnements, l’échange de jetons permet d’obtenir des identifiants adaptés à une ressource cible ou de représenter une délégation. La norme OAuth sur l’échange de jetons décrit ce mécanisme, mais sa disponibilité et ses contraintes précises dépendent de l’implémentation. Ne présentez pas un jeton temporaire comme automatiquement sûr : vérifiez son audience, son sujet, les actions autorisées, sa durée de validité et les conditions de renouvellement. Si l’environnement ne prend pas en charge des identifiants d’accès à portée limitée, documentez cette limite et compensez-la par des contrôles sur le système cible, une séparation des fonctions et une supervision.

Autoriser chaque opération sur le système cible

Une politique qui limite les outils disponibles peut réduire les erreurs de sélection : par exemple, l’agent ne voit qu’un ensemble d’outils approuvés. Cela ne prouve toutefois pas que l’appel concerné est autorisé. La documentation d’Amazon Bedrock AgentCore décrit des listes d’autorisation d’outils et précise que ce filtrage ne remplace pas les autorisations IAM pour les autres voies d’exécution. En matière de conception, le filtre appliqué à l’agent et la politique de la ressource sont deux niveaux distincts qui doivent être examinés séparément.

Le système cible doit au minimum vérifier l’identité effective, l’action demandée et la ressource concernée. Si l’autorisation dépend de l’utilisateur, il ne suffit pas de la vérifier au démarrage de la session puis de faire entièrement confiance au contexte. Définissez comment l’identité est vérifiée à chaque opération et ce qui se passe si les autorisations changent pendant l’exécution de la tâche. La mise en œuvre dépend de la plateforme : il ne faut donc pas supposer que tous les connecteurs réévaluent les autorisations de la même façon.

Les politiques basées sur les ressources et celles basées sur les identités peuvent être combinées à des règles contextuelles. AWS documente pour AgentCore des politiques de ressources permettant d’exprimer des principaux, des actions et des conditions, et recommande de n’accorder que les autorisations nécessaires. Appuyez-vous sur ce type de documentation pour comprendre le modèle d’évaluation du service choisi ; ne copiez pas une politique d’exemple sans vérifier la ressource, le principal et l’action concernés dans votre déploiement.

Séparer la préparation, l’approbation et l’exécution des actions sensibles

Une approbation humaine est utile lorsqu’une opération peut transmettre des informations à des tiers, modifier des données partagées, supprimer du contenu ou changer des autorisations. Elle ne devrait pas se résumer à un bouton générique « Continuer ». Avant de prendre sa décision, la personne doit comprendre quelle opération sera effectuée, sur quelle ressource, avec quelles données et quel effet est attendu. Si l’aperçu ne montre pas le destinataire, le contenu à envoyer ou la portée de la modification, l’approbation ne permet pas d’évaluer correctement le risque.

L’approbation doit également être liée à l’opération examinée. Si la destination, les arguments, la ressource ou l’action changent après l’approbation, demandez une nouvelle décision. Évitez de transformer une approbation ponctuelle en autorisation générale que l’agent pourrait réutiliser pour d’autres tâches. L’interface doit préciser qui approuve et au nom de qui l’opération sera exécutée.

La documentation du SDK Agents d’OpenAI décrit un flux dans lequel un appel sensible à un outil peut être suspendu pour examen, l’outil et ses arguments étant inspectés avant la reprise ou le rejet de l’exécution. C’est un exemple de mécanisme de contrôle, et non une garantie que toute opération est sûre : l’équipe doit encore décider quels outils nécessitent une pause et si les informations présentées à la personne chargée de l’approbation suffisent pour évaluer l’effet.

Limiter la durée d’accès et vérifier que la révocation fonctionne

Accorder l’accès pour la durée d’une session ou d’une tâche réduit la période pendant laquelle un identifiant peut être réutilisé, à condition que l’environnement prenne en charge ce mode de fonctionnement. Définissez le début et la fin de l’autorisation, ses possibilités de renouvellement et les personnes habilitées à la renouveler. Ne confondez pas une session courte avec une portée réduite : un identifiant de courte durée qui permet de supprimer toutes les données peut tout de même avoir un impact potentiel considérable tant qu’il est actif.

Concevez la révocation comme une opération qui doit pouvoir être testée. Retirez l’autorisation ou invalidez l’identifiant, puis envoyez de nouvelles demandes avec la même identité. Vérifiez également les sessions déjà ouvertes, les jetons mis en cache, les tâches en arrière-plan et les nouvelles tentatives. Le comportement dépend du fournisseur : certaines modifications prennent effet immédiatement, tandis que d’autres peuvent être soumises à un délai de propagation ou à la durée de validité des identifiants déjà émis. Si la documentation ne précise pas ce comportement, consignez cette incertitude et testez le cas dans l’environnement concerné.

Pour réduire le risque d’accès persistant, attribuez si possible des identifiants différents aux agents, aux environnements et aux tâches, et évitez de copier des secrets d’utilisateur dans les prompts, les historiques ou les journaux. En cas de délégation ou d’échange de jetons, ne conservez que les données nécessaires à l’exécution et à l’audit. La révocation ne remplace pas une conception initiale rigoureuse des autorisations : c’est une protection supplémentaire en cas de changement de personnel, d’incident ou de fin de tâche.

Enregistrer les décisions et les résultats sans faire des journaux un nouveau risque

Un journal utile permet de reconstituer qui a demandé une tâche, quelle identité a été utilisée, quel outil a été appelé, quelle ressource a été visée, quelle décision le système a prise et quel a été le résultat. Conservez des identifiants de demande et des horodatages suffisants pour corréler les événements entre l’agent et le service cible. Distinguez un appel tenté, une autorisation accordée et une opération terminée : il s’agit de faits différents.

Ne consignez pas de jetons, de clés, de mots de passe ni d’autres secrets. Ne stockez pas non plus automatiquement tout le contenu consulté ou envoyé. Définissez quelles données sont nécessaires pour enquêter sur les erreurs, comment elles sont protégées, qui peut y accéder et pendant combien de temps elles sont conservées. Dans certains cas, enregistrer l’identifiant de la ressource et un résumé du type d’opération suffit ; dans d’autres, il peut être nécessaire de conserver un aperçu soumis à des contrôles de confidentialité.

Utilisez la télémétrie pour détecter les tendances qui méritent un examen : refus répétés, tentatives d’accès à des ressources sans rapport avec la tâche, appels d’écriture inattendus ou utilisation d’un identifiant après sa révocation. Une tendance observée ne prouve pas à elle seule qu’il y a eu abus ; elle constitue un signal à étudier en tenant compte du contexte de la demande et des politiques en vigueur.

Tester les limites, y compris les tentatives hors périmètre

Avant le déploiement, transformez chaque autorisation accordée en un test positif et plusieurs tests négatifs. Le test positif montre que la tâche légitime fonctionne dans les limites prévues. Les tests négatifs vérifient que le même agent ne peut pas changer d’utilisateur, accéder à une ressource partagée sans autorisation, utiliser une opération d’écriture alors qu’il n’a qu’un accès en lecture, supprimer des enregistrements ou appeler un outil à des fins qui ne sont pas prévues. Répétez ces tests lorsque les connecteurs, les rôles, les politiques ou les flux d’approbation changent.

Testez à la fois l’interface de l’agent et le système cible. Si l’agent ne propose pas un outil interdit, vérifiez également qu’un appel direct ou un autre chemin ne permet pas d’exécuter l’action avec les identifiants disponibles. Vérifiez qu’une approbation n’autorise pas des arguments différents de ceux qui ont été examinés et qu’une autorisation révoquée bloque les demandes ultérieures. Pour les opérations à fort impact, utilisez des données et des ressources de test permettant d’observer les effets sans toucher à des personnes ou à des services réels.

La réussite d’un test ne démontre pas que le système est sûr dans toutes les circonstances. Elle indique que certains cas se sont comportés comme prévu avec une configuration donnée. Conservez l’identité de test, la politique appliquée, les étapes et le résultat afin de pouvoir répéter la vérification après une mise à jour. Si une plateforme masque une partie de l’évaluation des autorisations ou ne fournit pas de journaux suffisants, consignez cette limite au lieu de supposer que le contrôle a fonctionné.

Limites des contrôles et erreurs à éviter

Les autorisations réduisent l’éventail des actions possibles, mais ne garantissent pas que l’agent interprète correctement une tâche ni que sa réponse soit exacte. Un accès en lecture peut divulguer des informations sensibles si l’ensemble des documents autorisés est trop large. Un accès en écriture limité peut provoquer une modification erronée dans le périmètre autorisé. La conception doit donc associer autorisation, validation des entrées, examen proportionné au risque et tests de comportement.

Évitez d’accorder un identifiant d’administration pour simplifier l’intégration, de compter sur le prompt pour empêcher les opérations indésirables ou de supposer qu’une liste d’outils autorisés constitue une politique complète. Ne transformez pas non plus le consentement de l’utilisateur pour une tâche en autorisation persistante pour d’autres tâches. Les instructions et les approbations orientent le processus ; les autorisations effectives doivent rester limitées au sein de l’identité et du système connecté.

Ce guide porte sur l’autorité technique et la manière de la limiter. Il se distingue d’un guide consacré à l’injection indirecte d’instructions, qui traite du contenu non fiable cherchant à orienter l’agent, et d’un guide sur la reprise après incident, qui porte sur la réponse aux erreurs et aux effets partiels. Ces sujets sont liés : une instruction hostile peut chercher à déclencher une action indésirable, tandis que les autorisations et les contrôles du système cible déterminent quelles actions peuvent effectivement être exécutées.

Liste de vérification avant le déploiement et après chaque changement

Examinez le modèle d’autorisations avant d’activer un agent, puis renouvelez cet examen lorsqu’un outil est ajouté, qu’un connecteur change, que l’ensemble de données s’élargit ou qu’une politique est modifiée. La personne responsable doit pouvoir expliquer quelle tâche justifie chaque autorisation et quelles seraient les conséquences d’un appel erroné. Si aucun usage légitime d’une capacité ne peut être identifié, désactivez-la en attendant d’y voir plus clair.

À titre de référence opérationnelle, vérifiez que la configuration distingue la lecture, l’écriture, l’envoi, la suppression et la modification des accès ; qu’elle délimite l’utilisateur et la ressource ; et qu’elle ne repose pas uniquement sur les instructions du modèle. Vérifiez le processus d’approbation des opérations sensibles, les informations présentées à la personne chargée d’approuver, l’enregistrement des décisions et des résultats ainsi que la procédure de révocation. Exécutez les tests négatifs décrits plus haut avec les identités et les systèmes qui seront utilisés en production.

Cette liste ne remplace ni l’examen de sécurité du produit ni la documentation propre au fournisseur. Elle sert à rendre visibles les hypothèses qui passent souvent inaperçues lors de la connexion d’outils. Si l’environnement ne permet pas d’imposer une limite nécessaire, consignez l’écart, évaluez le risque et modifiez la conception de la tâche ou le processus avant d’accorder un accès étendu.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.