Réponse en bref
Commencez avec un agent IA en lecture seule, avec son propre compte, puis ajoutez une permission à la fois. Classez ses actions en trois catégories : lecture et brouillons sans validation, modifications internes réversibles avec relecture, actions irréversibles ou externes validées une à une par une personne désignée. Faites appliquer les règles par les systèmes eux-mêmes, plafonnez le volume et la dépense, tenez un journal que l’agent ne peut pas modifier et testez la procédure d’arrêt avant le lancement.
Une erreur coûte ce que les permissions autorisent
Un agent IA est un logiciel autorisé à agir : lire une boîte aux lettres, mettre à jour une fiche, envoyer un message, émettre un remboursement. Le modèle qu’il contient se trompera parfois, et parfois il sera induit en erreur par un texte lu en chemin. Ni l’un ni l’autre ne peut être exclu par une meilleure formulation. Ce que l’on peut décider à l’avance, c’est jusqu’où un faux pas peut aller.
Le projet OWASP Gen AI Security Project nomme ce risque Excessive Agency, une capacité d’agir excessive : des actions dommageables exécutées en réponse à des sorties inattendues, ambiguës ou manipulées d’un modèle de langage. Il en situe la cause profonde dans un ou plusieurs de ces trois éléments : des fonctionnalités excessives, des permissions excessives et une autonomie excessive. Tous trois sont des choix faits par celui qui configure l’agent.
C’est pourquoi il est utile de considérer les permissions d’un agent IA comme quelque chose qui se mérite. L’agent commence presque sans aucune, montre pendant une période de travail journalisé qu’une catégorie d’actions est sûre entre ses mains, et ne reçoit la suivante qu’ensuite.
Lister les actions avant de brancher les outils
Écrivez la tâche comme une suite d’étapes et, pour chacune, notez ce que l’agent doit lire et ce qu’il doit modifier. La liste est en général plus courte que l’éventail de fonctions de l’outil. L’exemple d’OWASP est un assistant de messagerie qui résume les courriels entrants : il a besoin de lire les messages, si bien que l’extension qu’il utilise ne devrait pas pouvoir en plus les supprimer ou les envoyer.
Retirez ensuite ce que la liste ne justifie pas. Les premières recommandations d’OWASP consistent à réduire au minimum les extensions qu’un agent peut appeler, à réduire au minimum les fonctions de chacune et à éviter les outils ouverts, comme l’exécution d’une commande shell ou le chargement de n’importe quelle URL, au profit d’outils étroits. Un outil essayé pendant le développement puis abandonné doit être débranché, et pas seulement ignoré.
Appliquez la même retenue aux données. Dans l’illustration d’OWASP, un agent qui recommande des produits n’a besoin que d’un accès en lecture à la table des produits, sans pouvoir insérer, modifier ou supprimer des enregistrements ni consulter d’autres tables. Pour une petite entreprise, l’équivalent est un dossier partagé ou un pipeline du CRM, pas le compte entier.
La lecture seule vient d’abord, et elle dure des semaines
Pendant la première période, l’agent lit, cherche et rédige des brouillons, et une personne exécute chaque action. Le guide d’OpenAI sur la construction d’agents distingue les outils de données, qui récupèrent de l’information, des outils d’action, qui modifient quelque chose dans un autre système. Commencez uniquement par les premiers. Ce que produit l’agent est une proposition : une réponse rédigée, une mise à jour suggérée, une liste de factures qui semblent erronées.
Cette étape n’est pas du temps perdu. Elle montre à quelle fréquence les brouillons sont acceptés tels quels, dans quels types de cas l’agent se trompe et si ses erreurs sont minimes ou étranges. Le même guide juge l’intervention humaine particulièrement importante au début du déploiement, parce qu’elle aide à repérer les défaillances et à faire apparaître les cas limites.
Fixez la règle de promotion avant de commencer, pour que l’impatience ne puisse pas l’infléchir plus tard. Par exemple : une catégorie d’actions ne devient automatique qu’après un nombre convenu de brouillons consécutifs approuvés sans retouche, et elle repasse en manuel après toute erreur grave. Les chiffres vous appartiennent ; l’important est qu’ils aient été écrits d’abord.
Qui valide quoi : trois catégories d’actions
Rangez chaque action de la liste dans l’une de trois catégories. La première regroupe la lecture, la recherche et la rédaction de brouillons : pas de validation, mais une trace au journal. La deuxième est une modification dans vos propres systèmes qui peut être annulée, comme étiqueter un ticket, remplir un champ qui conserve son historique ou enregistrer un brouillon. Le responsable du processus peut valider ces actions par lots ou les contrôler par sondage.
La troisième catégorie comprend tout ce qui est irréversible, externe ou financier : envoyer un message à un client, publier, supprimer, payer, rembourser, modifier des droits d’accès. OWASP recommande un contrôle avec intervention humaine (human-in-the-loop), afin qu’une personne approuve les actions à fort impact avant leur exécution. Le guide d’OpenAI indique que les actions sensibles, irréversibles ou à fort enjeu doivent déclencher une supervision humaine jusqu’à ce que la confiance dans la fiabilité de l’agent grandisse, et cite comme exemples l’annulation de commandes, l’autorisation de remboursements importants et la réalisation de paiements.
Désignez le valideur par sa fonction, et désignez un suppléant, car une file de validation sans personne au bout devient une raison de désactiver le contrôle. Montrez au valideur l’action exacte, les données sur lesquelles elle repose et ce qui se passera ensuite, et non un résumé que l’agent a rédigé sur lui-même.
La règle vit dans le système, pas dans le prompt
Une consigne telle que « ne supprime jamais d’enregistrements » est une demande adressée au modèle. Ce n’est pas un contrôle, puisque le modèle est justement l’élément qui peut faillir. Le conseil d’OWASP est la médiation complète : mettez en œuvre l’autorisation dans les systèmes en aval et ne comptez pas sur un modèle de langage pour décider si une action est permise.
En pratique, l’agent reçoit son propre compte, ni l’identifiant d’un salarié ni, surtout, une clé d’administrateur, avec le rôle le plus étroit que propose le système. Lorsque l’agent agit pour un utilisateur précis, OWASP recommande d’exécuter dans le contexte de cet utilisateur avec les privilèges minimaux nécessaires, par exemple au moyen d’une autorisation OAuth dotée de la portée minimale requise.
L’étape de validation a sa place au même endroit. Si les remboursements supérieurs à un seuil exigent une seconde signature dans le système de paiement, l’agent rencontre cette règle exactement comme un salarié. Le guide d’OpenAI ajoute que les garde-fous doivent être associés à une authentification et à une autorisation robustes, à des contrôles d’accès stricts et aux mesures habituelles de sécurité logicielle.
Des limites de volume, de dépense et de portée
Une limite transforme une défaillance sans plafond en défaillance bornée. OWASP relève que la limitation de débit réduit le nombre d’actions indésirables possibles sur une période donnée et augmente les chances de les découvrir grâce à la surveillance avant que les dégâts soient importants. Un courriel erroné vaut une excuse ; mille font un incident.
Fixez les limites là où l’agent ne peut pas les modifier : un nombre maximal d’actions par exécution et par jour, un nombre maximal de destinataires, une liste de dossiers, de domaines ou de types d’enregistrements autorisés. Le guide d’Anthropic sur la construction d’agents mentionne les conditions d’arrêt, comme un nombre maximal d’itérations, parmi les moyens courants de garder le contrôle.
Le coût a lui aussi besoin d’un plafond. Anthropic observe que la nature autonome des agents entraîne des coûts plus élevés et un risque d’erreurs qui se cumulent. Si le compte du fournisseur du modèle propose une limite de dépense ou une alerte, réglez-la en dessous du montant qui ferait mal. Le guide d’OpenAI ajoute une limite de comportement : plafonnez les nouvelles tentatives de l’agent et confiez le cas à une personne quand le plafond est atteint.
Un journal que quelqu’un lit vraiment
Consignez chaque appel d’outil : l’heure, la tâche, l’outil, son entrée, le résultat et la personne qui l’a validé. Conservez ces traces là où l’agent n’a pas le droit de les modifier. OWASP est franc sur ce que l’on en obtient : la journalisation et la surveillance n’empêchent pas l’excès de capacité d’agir, mais elles limitent les dégâts en montrant où des actions indésirables se produisent.
Un journal ne protège personne tant que nul ne le regarde. Confiez à un responsable désigné une revue hebdomadaire en trois questions : qu’a fait l’agent qui nous a surpris, qu’ont refusé les valideurs et pourquoi, quelles limites ont été atteintes. Les réponses décident si une permission est étendue, maintenue ou retirée.
Le cadre de gestion des risques liés à l’IA du NIST (« AI Risk Management Framework »), document d’application volontaire, formule les mêmes attentes sous forme de résultats. L’une de ses sous-catégories demande que le comportement d’un système d’IA soit surveillé en production. Une autre demande que les incidents et les erreurs soient communiqués aux personnes concernées, y compris les communautés touchées, et que les processus de suivi, de réponse et de rétablissement soient appliqués et documentés.
Le chemin du retour s’écrit avant le lancement
Le même cadre demande des mécanismes, assortis de responsabilités attribuées et comprises, pour remplacer, débrancher ou désactiver un système d’IA dont les performances ou les résultats ne correspondent pas à l’usage prévu. Pour une petite équipe, cela tient en une phrase : qui peut éteindre l’agent, et comment. Il doit s’agir d’un geste que cette personne peut accomplir seule, comme désactiver l’intégration ou révoquer les identifiants de l’agent, sans attendre un développeur.
Écrivez ensuite le chemin d’annulation de chaque action réversible. Une fiche modifiée se restaure depuis son historique, un fichier déplacé revient de l’ancien dossier, un brouillon est simplement supprimé. Faites une sauvegarde ou un export avant toute opération de masse. Si une action n’a pas de chemin d’annulation, elle était mal classée : elle appartient à la troisième catégorie et attend une validation.
Faites-en une répétition sur des données copiées. Arrêtez l’agent au milieu d’une exécution, restaurez une modification et chronométrez les deux. Décidez aussi qui prévient les clients si quelque chose leur est parvenu à tort. Le moment de trouver les failles d’un plan se situe avant la première mise en service.
Une page à régler avant la première mise en service
Avant le lancement, rassemblez les décisions sur une seule page. Indiquez la finalité de l’agent et les tâches qu’il ne doit pas tenter. Listez ses actions par catégorie, avec le valideur et le suppléant de chacune. Notez le compte qu’il utilise, avec quel rôle, et la date d’expiration de ses identifiants. Ajoutez les limites, l’endroit où le journal est conservé, la personne qui le relit, la procédure d’arrêt et la date de la répétition.
Testez d’abord d’après cette page dans un bac à sable, sur des copies de données réelles. Anthropic recommande des tests approfondis en environnement isolé, accompagnés des garde-fous appropriés. Incluez des cas hostiles : un document contenant des instructions adressées à l’agent, une demande étrangère à sa finalité, un outil qui renvoie une erreur. Notez ce qu’il a fait, non ce qu’il a dit qu’il ferait.
Le cadre du NIST demande que les rôles, les responsabilités et les circuits de communication soient documentés et clairs, et que les processus de supervision humaine soient définis, évalués et documentés. Le NIST qualifie ce cadre de document vivant ; vérifiez donc sur son site quelle est la version en vigueur. Donnez aussi une date de révision à votre propre page. Les permissions d’un agent IA s’ajoutent une à une, et chacune devrait encore avoir un responsable dans un an.
Checklist pratique
- Listez toutes les actions que l’agent pourrait accomplir et débranchez les outils et les fonctions dont la tâche n’a pas besoin.
- Donnez à l’agent son propre compte, d’abord en lecture seule, et ajoutez une permission à la fois.
- Désignez la personne qui valide chaque action irréversible, externe ou financière, ainsi qu’un suppléant pour ses absences.
- Fixez dans les systèmes eux-mêmes, et non dans le prompt, les limites d’actions par exécution, de destinataires et de dépense quotidienne.
- Faites une répétition de la procédure d’arrêt et d’un retour arrière sur des données copiées avant que l’agent ne touche au travail réel.
Questions et réponses
Que signifie le moindre privilège pour un agent IA ?
Cela signifie que l’agent ne dispose que des outils, des fonctions et des accès aux données qu’exige sa tâche définie, et de rien qui soit seulement commode. Les exemples d’OWASP sont concrets : un assistant qui résume les courriels doit pouvoir lire les messages, mais pas les envoyer ni les supprimer, et une extension qui lit une base de données doit se connecter avec une identité limitée à la lecture. Le test consiste à vérifier que chaque permission se rattache à une étape de la tâche.
Quelles actions d’un agent IA doivent toujours exiger une validation humaine ?
Celles qui ne peuvent pas être annulées, celles qui sortent de votre organisation et celles qui déplacent de l’argent ou des accès : envoyer à des clients, publier, supprimer, payer, rembourser et modifier des droits. Le guide d’OpenAI donne en exemple les annulations de commandes, les remboursements importants et les paiements ; OWASP ajoute la publication sur les réseaux sociaux au nom d’un utilisateur. La validation pourra être assouplie plus tard pour une catégorie étroite, mais seulement par une décision consignée.
Une consigne dans le prompt suffit-elle à empêcher un agent de faire quelque chose ?
Non. Un prompt oriente le modèle, et le modèle est le composant qui peut être désorienté ou manipulé. OWASP recommande de faire appliquer l’autorisation par les systèmes auxquels l’agent se connecte, de sorte qu’une demande interdite y soit refusée quoi que décide le modèle. Servez-vous du prompt pour expliquer le travail, et des rôles, des portées et des règles de validation dans les systèmes cibles pour tracer les limites.
Quand peut-on accorder davantage de permissions à un agent sans danger ?
Quand il existe des preuves et un chemin de retour. Les preuves, c’est une période journalisée pendant laquelle les brouillons de l’agent pour cette catégorie ont été relus et acceptés selon un seuil fixé à l’avance. Le chemin de retour, c’est savoir comment annuler ce type d’action et comment retirer la permission. Ajoutez une permission à la fois, afin qu’un problème nouveau puisse être attribué à un seul changement.
Une petite entreprise a-t-elle besoin d’un cadre formel pour encadrer un agent IA ?
Pas d’un programme formel. Le cadre du NIST consacré aux risques de l’IA (AI Risk Management Framework) est d’application volontaire et rédigé pour des organisations de toutes tailles, et ses questions se transposent bien à petite échelle : qui est responsable, comment la supervision humaine est-elle définie, comment le système est-il surveillé et comment l’éteint-on. Une seule page qui y répond, tenue à jour, accomplit l’essentiel pour une petite équipe.