Agent IA : définir ses droits et suivre ses actions

Vous demandez à un agent de préparer une facture. Il doit consulter le dossier du client et créer un document ; il n'a pas forcément besoin de modifier les coordonnées bancaires ni d'envoyer le résultat. Définir ces possibilités dans les services et les autorisations permet de limiter ses actions, même s'il comprend mal une consigne ou rencontre un contenu piégé.

Partir des actions réellement nécessaires

Un agent utilise le système par des outils : rechercher un client, lire un document, créer une facture, envoyer un message. Chaque outil donne accès à une capacité concrète. Le choix de ces capacités et les contrôles appliqués à chaque appel déterminent ce que l'agent peut réellement faire.

Pour préparer notre facture, l'application peut autoriser la lecture du dossier et la création d'un brouillon. La validation et l'envoi peuvent rester deux actions distinctes, soumises à des conditions supplémentaires.

Je recommande de commencer par cette liste d'actions et de données nécessaires, plutôt que par un compte doté de tous les accès disponibles. Une mission de préparation ne devrait pas recevoir automatiquement les pouvoirs d'une mission d'exécution.

Le prompt guide le modèle, les services contrôlent ses demandes

Une consigne comme « ne modifie jamais les coordonnées bancaires » aide à orienter le comportement du modèle. Elle ne remplace pas une vérification d'autorisation sur l'opération de modification.

Le modèle peut mal interpréter une demande. Il peut aussi rencontrer une instruction cachée dans un document ou une page qu'il consulte. Cette injection indirecte cherche à lui faire traiter du contenu externe comme une nouvelle consigne.

Le service appelé doit donc contrôler l'identité, les droits et les règles métier, quelle que soit la justification donnée par l'agent. Si sa mission n'autorise pas le changement de compte bancaire, l'appel doit être refusé.

Réduire les outils exposés aide également à limiter les erreurs possibles. Cela complète les autorisations : un outil masqué dans une interface ne constitue pas une protection suffisante si le même accès reste disponible ailleurs.

Relier l'action à la personne et à la mission qui l'autorisent

Lorsqu'un agent agit à la demande d'une personne, ses droits ne devraient pas dépasser ceux qu'elle peut lui déléguer. Ils peuvent être plus étroits : le fait qu'un utilisateur puisse supprimer des factures ne signifie pas que son agent en a besoin pour préparer un brouillon.

Cette délégation doit être identifiable. Pour chaque action, le système doit pouvoir retrouver la personne qui a demandé la mission, le périmètre accordé et l'outil utilisé. Il doit aussi pouvoir retirer l'autorisation sans devoir reconstruire tout le parcours.

Le problème du député confus, décrit par Norm Hardy en 1988, aide à comprendre le risque d'un composant qui utilise ses propres pouvoirs au bénéfice d'un appelant qui ne les possède pas. Un agent disposant d'une clé partagée très puissante peut créer ce type de confusion.

Un compte de service n'est pas intrinsèquement incontrôlable : il peut avoir des droits étroits, une durée limitée et des journaux détaillés. Mais un compte partagé entre de nombreuses missions rend plus difficile l'attribution de chaque action et peut accumuler des permissions inutiles.

Les identifiants doivent rester dans la couche qui exécute les outils

L'utilisateur peut autoriser l'application à agir auprès d'un service tiers, par une délégation OAuth 2 ou une clé d'API selon le fournisseur. L'application conserve ces accès et les utilise pour les appels autorisés. Le modèle n'a pas besoin de lire les secrets pour choisir un outil.

La RFC 8707 permet notamment au client OAuth de préciser la ressource visée. Le serveur d'autorisation peut ainsi restreindre le jeton au service concerné. Cette restriction doit être effectivement appliquée et contrôlée ; le seul usage d'OAuth ne suffit pas.

Il faut aussi limiter les opérations permises et la durée de validité lorsque le service le permet. Une délégation destinée à lire des documents ne devrait pas devenir un accès général à tous les services du même utilisateur.

L'expression bring your own key, ou BYOK, est parfois utilisée pour une clé de fournisseur apportée par l'utilisateur. Elle désigne habituellement des clés de chiffrement dans d'autres contextes. Ici, il est plus clair de parler directement d'identifiants ou de délégation d'accès.

La facturation et les droits sont deux réglages à suivre

Utiliser la clé personnelle d'un fournisseur peut permettre à chacun de choisir son offre et de payer directement ses appels. Une plateforme peut aussi facturer des usages mutualisés en les attribuant correctement. Dans les deux cas, il faut suivre les consommations et prévoir des plafonds.

Le paiement sous une clé donnée ne prouve pas que l'action était autorisée. Inversement, une action autorisée peut coûter trop cher si un agent répète inutilement le même traitement. Budget et permissions se complètent.

Des droits limités ne suppriment pas le risque de fuite

Un agent peut avoir le droit de lire un document confidentiel et le droit d'envoyer un courriel. S'il est manipulé, il peut combiner ces deux actions pour transmettre le document à un mauvais destinataire, sans avoir obtenu de permission supplémentaire.

Simon Willison décrit ce risque lorsque l'agent cumule accès à des données privées, lecture de contenus non fiables et possibilité de communiquer vers l'extérieur. Hériter des droits de l'utilisateur ne suffit donc pas à protéger son intention.

Selon la mission, il faut séparer certaines capacités, limiter les destinations de sortie ou demander une validation avant la transmission. Le journal doit permettre de relier la demande initiale, les données consultées et l'action effectuée. Ces contrôles réduisent les conséquences d'une erreur ; ils ne rendent pas toute combinaison d'outils sûre par défaut.

Sources

• N. Hardy, The Confused Deputy, ACM SIGOPS Operating Systems Review 22(4), octobre 1988.
• S. Willison, The lethal trifecta for AI agents, juin 2025.
• OWASP, Top 10 for LLM Applications, édition 2026.
• OWASP, Top 10 for Agentic Applications, 2026.
• RFC 8707, Resource Indicators for OAuth 2.0.