Permissions d'un agent IA : comment décider ce qu'il peut faire ?

Un agent IA peut disposer d'un accès à vos fichiers, d'un outil capable d'envoyer un message ou d'une commande permettant de modifier une base de données. Cela ne signifie pas qu'il doit pouvoir utiliser ces capacités comme il l'entend.

Cette différence devient facile à oublier quand tout passe par la même interface. Le traitement d'une demande peut mobiliser plusieurs sources, produire un brouillon puis déclencher un outil. L'enchaînement paraît continu. Pourtant, chaque étape engage un niveau de permission différent.

Le réglage utile précise ce que l'agent peut lire, ce qu'il peut préparer, ce qu'il peut exécuter et l'endroit où il doit s'arrêter.

Le sujet commence après le choix de la tâche et de l'architecture. Il s'agit de transformer les droits accordés à l'agent en contrat vérifiable : ce qu'il peut faire, où, dans quelles conditions, avec quelle trace et à quel moment il doit s'arrêter.

Permissions d'un agent IA : une capacité n'est pas une autorisation

Donner un outil à un agent revient à lui donner une capacité technique. Une connexion à une messagerie peut permettre de lire, rechercher, rédiger et envoyer. Un accès à un dossier peut permettre de consulter, créer, modifier ou supprimer. Ces verbes n'ont ni le même effet ni le même niveau de risque.

L'OWASP regroupe le risque d'« excessive agency » autour de trois excès : trop de fonctionnalités, trop de permissions et trop d'autonomie. Son exemple d'un assistant de messagerie est parlant : résumer des courriels nécessite un accès en lecture, mais pas la capacité d'envoyer un message. Si l'outil réunit les deux, une injection indirecte dissimulée dans un courriel malveillant peut exploiter une capacité dont l'usage initial n'avait pas besoin.

La première question n'est donc pas « quels outils connecter ? », mais « quelles actions utiles doivent être possibles dans chaque outil ? ».

Cloudflare donne un exemple simple dans son guide sur la gestion des agents IA : un agent peut recevoir un droit de lecture sans droit d'écriture. La même logique peut limiter ses ressources, les données sensibles auxquelles il accède et la durée pendant laquelle l'accès reste actif.

Cette granularité évite de confondre quatre niveaux :

1. La capacité : l'outil sait techniquement effectuer l'action.
2. L'accès : l'agent peut atteindre la donnée ou le service concerné.
3. L'autorisation : la règle permet l'action dans ce contexte précis.
4. L'autonomie : l'agent peut agir immédiatement ou doit attendre une validation.

Un agent peut donc avoir accès à un service sans être autorisé à utiliser toutes ses fonctions. Il peut aussi être autorisé à préparer une action sans pouvoir l'exécuter seul.

Décrire une permission comme un contrat

Une règle telle que « l'agent peut écrire dans Obsidian » reste trop vague. Écrire où ? Pour créer quel type de contenu ? Peut-il modifier une note existante ? Renommer un dossier ? Déplacer une source ? Supprimer un doublon ?

Une permission exploitable devrait répondre à six questions :

• Action : quel verbe précis est autorisé ?
• Cible : sur quelle donnée, quel compte ou quel espace ?
• Périmètre : quelles limites s'appliquent à cette cible ?
• Condition : dans quelles circonstances l'action peut-elle partir ?
• Preuve : quelle trace permettra de comprendre ce qui a été fait ?
• Repli : que doit faire l'agent si une information manque ou si le cas sort du cadre ?

Exemple de règle fictive :

L'agent peut créer un brouillon en Markdown dans le dossier prévu, à partir d'une demande explicite. Il conserve les sources utilisées. Il ne remplace aucune note existante. En cas de titre déjà présent ou de destination ambiguë, il s'arrête et demande une décision.

Cette formulation ne révèle aucune configuration technique. Elle décrit le comportement attendu. Elle peut donc servir à la fois de règle, de documentation et de base de test.

Trois régimes suffisent pour commencer

Le contrat de permission aboutit à l'un des trois régimes : exécution automatique, validation explicite ou interdiction. Cette classification intervient après le choix entre règle, automatisation, modèle ou agent. Elle borne concrètement les droits de l'agent retenu.

1. Automatique

Le contrat peut autoriser une exécution automatique quand le périmètre est précis et l'erreur facile à corriger. Par exemple, l'agent crée un brouillon dans un dossier défini, sans remplacer de fichier existant. La règle fixe déjà la cible, la trace attendue et le comportement en cas de conflit.

Microsoft recommande de limiter chaque agent aux sources nécessaires à sa fonction et de faire appliquer, par les outils, les permissions de l'utilisateur ou d'un compte de service délimité.

2. Soumis à validation

Le contrat impose un arrêt avant exécution lorsque l'action engage une autre personne, modifie une source de vérité, crée un coût ou produit un effet difficile à annuler.

La validation ne doit pas être une formalité. Pour décider, la personne doit voir ce qui va être exécuté, sur quelle cible et avec quelles données. Un bouton « confirmer » placé après un résumé flou ne suffit pas.

Les modèles human-in-the-loop de Cloudflare prévoient qu'un workflow puisse s'arrêter, conserver son état et attendre une approbation avant de reprendre. Leur documentation cite les paiements, les suppressions et les communications externes parmi les opérations qui demandent une supervision.

Une règle de validation doit préciser ce que la personne voit et ce qu'elle valide. Par exemple :

Avant tout envoi externe, présenter le destinataire, l'objet, le contenu final et les éventuelles pièces jointes. Attendre une validation explicite portant sur cette version. Toute modification ultérieure annule la validation.

3. Interdit

Le contrat peut aussi rendre une action impossible. C'est le cas d'un accès à des données hors périmètre, de l'exposition d'un secret, du contournement d'une protection ou d'une action destructive sans reprise adaptée.

Une demande formulée dans une conversation ne doit pas suffire, à elle seule, à autoriser une action. Elle peut être imprécise, envoyée dans le mauvais contexte ou provenir d'une personne qui ne dispose pas du droit nécessaire.

OWASP recommande d'appliquer l'autorisation dans les systèmes en aval plutôt que de laisser le modèle décider seul si l'action est permise. Autrement dit, une règle écrite dans le prompt ne remplace pas une limite réellement imposée par l'outil ou le compte utilisé.

Les catégories varient selon le système. Dans mon architecture d'agent reliée à Obsidian, je montre leur application dans un système personnel. Ici, l'objectif est d'écrire chaque règle de façon à pouvoir la contrôler et la tester.

Cinq critères pour écrire le contrat de permission

Le même verbe peut conduire à des règles différentes selon sa cible et ses conséquences. Cinq critères aident à remplir le contrat.

L'effet sort-il du système ?

Une recherche interne et un courriel envoyé n'ont pas la même portée. Dès qu'une action touche un client, un prospect, un fournisseur, une plateforme publique ou un système de paiement, prévoyez par défaut un examen humain. Cloudflare cite notamment les paiements et les communications externes parmi les opérations nécessitant une supervision.

Peut-on revenir en arrière ?

Un brouillon peut être supprimé. Une modification versionnée peut être restaurée. En revanche, considérez un message envoyé comme difficile à annuler une fois lu par son destinataire. La possibilité de reprendre un état antérieur change le niveau d'autonomie acceptable.

Pour approfondir les mécanismes de reprise et leur vérification, voir mon article sur la sauvegarde et la restauration d'un système IA. Une action présentée comme réversible ne l'est vraiment que si le mécanisme de reprise existe et a été vérifié.

Quelles données l'action mobilise-t-elle ?

La validation finale ne corrige pas un accès initial trop large. Si l'agent ne doit jamais lire certaines données, il faut les isoler avant l'étape de raisonnement. Microsoft recommande de séparer les données confidentielles des sources publiques et de limiter chaque agent aux sources nécessaires.

Quel engagement l'action crée-t-elle ?

Un achat, une prise de rendez-vous, une promesse faite à un client ou une modification contractuelle engage davantage qu'un brouillon. Même si le montant est faible, l'action peut avoir une portée commerciale ou juridique qui mérite une décision humaine explicite.

L'intention est-elle suffisamment précise ?

« Prépare une réponse » et « envoie cette réponse à Julie » ne donnent pas la même autorisation. Si plusieurs destinataires, fichiers ou interprétations sont possibles, l'agent doit demander une précision avant d'agir. Une bonne permission décrit aussi ce comportement d'arrêt.

Une matrice simple pour le premier usage

Il n'est pas nécessaire de cartographier toutes les actions imaginables avant de commencer. La matrice peut se limiter au premier usage retenu.

Cette matrice rend les règles compréhensibles sans montrer la configuration interne. Elle fournit aussi des scénarios concrets pour vérifier que les permissions appliquées correspondent à la décision.

Tester les permissions, pas seulement le résultat

Ne limitez pas le test d'un agent au scénario nominal : la demande est claire, les données existent et le résultat attendu apparaît. Ce test montre que l'agent sait agir. Il ne montre pas qu'il sait s'arrêter.

Pour chaque permission, préparez au moins quatre scénarios :

1. Action autorisée : l'agent exécute l'action dans le bon périmètre et produit la trace attendue.
2. Validation obligatoire : il prépare l'action, expose les éléments utiles à la décision et attend.
3. Action interdite : il refuse sans chercher un autre chemin pour atteindre le même résultat.
4. Contexte incomplet : il demande l'information manquante ou s'arrête, sans choisir une cible par défaut.

Ajoutez un cinquième test lorsque plusieurs espaces ou comptes se ressemblent : une tentative de dépassement de périmètre. L'agent reçoit une demande apparemment légitime, mais visant une donnée ou une destination non autorisée. Il doit la refuser de manière prévisible.

Une permission écrite dans une consigne reste une intention. Elle devient exploitable lorsque les tests montrent que le système exécute l'action autorisée, interrompt l'exécution au point prévu et refuse l'action hors périmètre. J'ai détaillé un protocole en sept scénarios pour tester un agent IA avant de l'utiliser au quotidien.

Cette distinction entre actions internes réversibles, modifications à valider et actions externes est illustrée dans l'article consacré à mon système relié à Obsidian. Chaque nouvel outil ou nouvel usage oblige à reprendre la matrice, pas seulement à ajouter une connexion.

Élargir l'autonomie après observation

Commencer avec peu de permissions permet d'observer les premières utilisations avant d'élargir l'autonomie. Cette phase sert à identifier les validations qui apportent une décision réelle et celles dont le régime peut être réexaminé.

Une action peut passer de « validation » à « automatique » si plusieurs conditions sont réunies :

• son périmètre est stable ;
• les erreurs observées sont détectables ;
• la reprise fonctionne ;
• les traces permettent de comprendre l'exécution ;
• les cas ambigus provoquent bien un arrêt.

L'inverse doit rester possible. Le niveau d'autonomie doit pouvoir être revu quand l'outil, les données ou le contexte changent. Pour situer chaque étape entre l'automatisation complète et la décision directe, j'ai décrit quatre niveaux d'autonomie pour un agent IA.

Pour un premier usage, choisissez un périmètre fréquent et borné, puis n'élargissez l'autonomie qu'après avoir observé et testé son fonctionnement. L'article sur le choix d'un premier processus à confier à l'IA traite l'étape qui précède cette matrice.

Les permissions font partie du système

Dès qu'un assistant peut agir sur des comptes, des données ou des outils, ses permissions deviennent une partie du système. Elles définissent ce qu'il est autorisé à faire et participent à la conception d'un système IA personnel utilisable au quotidien.

Le système devrait permettre de répondre simplement à ces questions :

• Quelles données l'agent peut-il lire ?
• Quelles actions peut-il exécuter seul ?
• Où doit-il attendre une validation ?
• Que lui est-il impossible de faire ?
• Quelle trace reste après l'action ?
• Comment vérifie-t-on qu'un refus fonctionne encore ?

Si ces réponses n'existent pas, l'autonomie affichée repose surtout sur la confiance accordée au modèle. Le modèle peut produire une sortie inattendue, mal interpréter une demande ou traiter une instruction manipulée comme légitime. Les limites importantes doivent donc aussi être appliquées par les comptes, les outils et les tests.

Une permission est adaptée lorsqu'elle permet l'usage prévu sans étendre l'autorisation au-delà de ce périmètre.