Décider de ce qu'un agent IA est autorisé à toucher : la limite des autorisations qui survit à une mauvaise journée

La question intéressante à propos d’un agent IA n’est pas « pouvons-nous lui faire faire la chose ? Il s'agit de savoir « à quoi ressemblera la reprise le jour où elle fera quelque chose de mal ? »

La plupart des écrits sur les autorisations des agents IA concernent soit le contenu du fournisseur de gestion des identités (diagrammes en forme d'Okta, tables de portée, taxonomies OWASP), soit les cadres de conformité de sécurité d'entreprise (preuves SOC 2, références croisées de l'EU AI Act). Les deux sont utiles dans le bon contexte et ce dont un petit opérateur a réellement besoin le jour où il remet à une machine les clés de son référentiel git ou de son site de production en direct n'est pas non plus utile. Ce dont ils ont besoin, c'est d'un cadre de décision qui répond honnêtement à une question par action que l'agent pourrait entreprendre : quel est le pire résultat plausible lors d'une mauvaise journée, et à quoi ressemble la récupération après cela ?

Cet article est ce cadre, rédigé après avoir effectivement donné aux agents un accès en écriture à ce site Web. Tout ce qui suit est soit quelque chose que je fais, soit quelque chose dont j'ai décidé que le coût de récupération est trop élevé pour justifier la commodité. Il ne s’agit pas d’un argumentaire de fournisseur de sécurité et il ne vous vend pas un moteur de politique.

Pourquoi « moindre privilège » n'est pas la bonne première question

Le cadrage standard de l'industrie est le least privilege : donner à un agent uniquement ce dont il a strictement besoin. C'est un beau principe, mais il est très tardif. Il répond « combien d'accès ? » sans d'abord répondre « à quelle classe d'action peut-on accorder en toute sécurité n'importe quel niveau d'accès ? »

L'ordre qui aide réellement un petit opérateur est le suivant :

1. Classez l'action par rayon d'explosion. Non pas selon qu'elle soit réalisable (tout ce qu'une API prend en charge peut être fait) mais selon ce qui se passe si cela tourne mal et ne peut pas être annulé. C’est là que la plupart des décisions en matière d’autorisations devraient commencer et c’est là qu’elles ne le font presque jamais. 2. Décidez si l'action appartient à une classe que vous laisserez les agents effectuer. Certaines classes ne le font tout simplement pas, quelle que soit la portée du jeton. 3. Alors seulement, pour les actions qui franchissent les deux premières portes, appliquez le moindre privilège aux étendues et aux jetons spécifiques.

Sauter les étapes 1 et 2 est la façon dont vous vous retrouvez avec un agent qui "a juste besoin d'une autorisation de suppression pour ce dossier" et qui, un mauvais jour plus tard, a supprimé quelque chose que vous ne pouvez pas récupérer.

La taxonomie du rayon de souffle qui décide de tout le reste

Il existe essentiellement quatre classes d'action, et c'est la classe qui détermine si un agent doit toucher à l'action, et non la liste de portées de l'API.

Classe 1 — Réversible par l'agent lui-même, en quelques secondes. L'agent modifie un brouillon. L'agent exécute une requête et inspecte le résultat. L'agent génère du contenu dans un fichier qui lui appartient également. La récupération après une mauvaise action de classe 1 consiste pour l'agent à réessayer. Il n'y a pas de rayon d'explosion significatif car l'action n'a jamais quitté le bac à sable de l'agent. Accordez-les gratuitement ; ne pas le faire est ce qui fait que les agents d’IA se sentent inutiles.

Classe 2 — Réversible par un humain en quelques minutes. L'agent s'engage auprès de git. L'agent pousse vers une succursale. L'agent télécharge un brouillon sur un CMS. L'agent met un e-mail en file d'attente dans une file d'attente « révision avant envoi ». La récupération est qu'un humain remarque, annule ou révise. Le rayon d'explosion est réel mais limité : un mauvais commit est un mauvais commit, et git revert est une vraie réponse qui coûte environ trois minutes. Accordez-les avec la piste d’audit qui permet à l’humain de le remarquer.

Classe 3 — Réversible en heures ou en jours, à un coût réel. L'agent publie publiquement. L'agent envoie un e-mail à une vraie liste. L'agent modifie une base de données de production en direct. La récupération est qu'un humain remarque ET prend une action qui elle-même a des conséquences (suppression d'une publication publique, envoi d'un e-mail de correction, annulation d'une migration). Accordez-les uniquement si le rayon d'action de l'action spécifique est petit ET que la piste d'audit vous permet de détecter le mauvais cas en quelques minutes, et non en quelques heures.

Classe 4 — Irréversible, ou réversible uniquement au prix d'une modification de l'activité. L'agent supprime un enregistrement client. L'agent déplace de l'argent. L'agent modifie les informations d'identification du compte. L'agent publie quelque chose qui est capté par le fil avant que la correction n'arrive. La récupération, c'est que vous passez une semaine à vous excuser ou à payer, et le coût de la confiance est permanent. Ne les accordez pas. Jamais. Quelle que soit la compétence de l'agent, quelle que soit la portée étroite du jeton. La commodité de l'automatisation d'une action de classe 4 ne vaut jamais le prix d'une erreur une seule fois.

Les frontières entre les classes ne sont pas floues dans la pratique. Ce qui les rend flous, c'est que l'industrie vous vend des outils qui peuvent techniquement effectuer chaque action et vous laisse décider laquelle. La taxonomie ci-dessus est la décision préalable à l'outil : avant d'écrire une seule ligne de code susceptible de toucher une action de classe 4, demandez-vous si l'action appartient au code.

Les choses spécifiques que je laisse faire mes agents

Pour plus de concret, voici la portée exacte que j'accorde sur ce site, mappée aux classes ci-dessus. Il ne s'agit pas d'un modèle – votre opération est différente – mais c'est un exemple concret du framework.

Classe 1, accordée : tout ce qui lit. Lisez les fichiers du dépôt, lisez le plan du site, lisez les journaux de déploiement, lisez le résumé, lisez la liste de travail, lisez le backlog. L'agent de publication lit tout ce qu'il peut, à tout moment, et il n'y a aucun coût de récupération car les lectures ne changent rien.

Classe 1, accordée : tout ce qui écrit dans des fichiers appartenant à la session de l'agent et inspecté avant la validation. Brouillons d'articles, couvertures générées, cartes OG générées, métadonnées du backlog mises à jour. Le mauvais cas est un mauvais brouillon ; la récupération consiste à "supprimer le fichier, réessayer".

Classe 2, accordée : s'engage à main lorsque la porte de construction passe. C'est l'important. J'accorde explicitement à l'agent la possibilité d'écrire dans la branche déployée par Cloudflare Pages, sans étape de révision humaine, à la condition spécifique que npm run build renvoie zéro. La porte de construction est ce qui en fait une action de classe 2 plutôt que de classe 3 : un déploiement interrompu est intercepté par check-posts, check-links et check-search avant d'atterrir, et un mauvais commit qui passe les portes est toujours git revert -capable en quelques minutes.

Classe 2, accordée : pousse au origin/main . Même raisonnement : le pipeline de déploiement a sa propre porte de construction du côté éloigné, et Cloudflare Pages conserve les déploiements précédents pour la restauration. Un simple clic annule n’importe quel déploiement.

Classe 2, accordée : Appels d'API GitHub pour créer des validations, ouvrir des problèmes et mettre à jour l'état du problème sur la liste de travail. Tous ces éléments sont vérifiables dans l’historique du repo et annulables à la main.

Classe 3, considérée et NON accordée : publication sur LinkedIn ou sur toute plateforme sociale sous mon nom. Le coût de récupération d’une mauvaise publication sur LinkedIn est une publication supprimée dont tous ceux qui l’ont vue ont également partagé une capture d’écran, plus une taxe sur la réputation. La commodité d'automatiser la « publication de l'article en tant que mise à jour LinkedIn » n'en vaut pas la peine. C'est la raison spécifique pour laquelle le document AUTOMATION-PLAN du site dit explicitement « Cela ne touche ni LinkedIn ni le courrier électronique » – le cours a été pris en compte et rejeté, pas simplement laissé de côté.

Classe 3, considérée et NON accordée : envoi d'e-mail à la liste newsletter. Même raisonnement. La récupération d'un mauvais e-mail vers une vraie liste est un e-mail de correction que les gens lisent également comme « ces personnes ne peuvent pas garder leurs systèmes en ordre », ainsi que des désabonnements permanents. Les newsletters sont expédiées lorsqu'un humain clique sur envoyer.

Classe 4, bloqué en dur : suppression de toute publication publiée, suppression de tout enregistrement d'abonné, modifications des dépendances _headers , _redirects , functions/ ou package.json sans réexamen explicite. L'agent peut les PROPOSER - dans une entrée du journal d'exécution - mais le commit qui les amène doit être celui que j'ai lu, et non celui rédigé par l'agent. C’est une véritable friction pour l’agent, et c’est une friction que je souhaite.

Classe 4, bloqué en dur : tout ce qui a trait aux paramètres du compte Cloudflare, au DNS ou aux règles d'accès. Les informations d'identification du compte ne se trouvent pas du tout dans l'environnement de l'agent. S’ils ont besoin d’être changés, je les change.

Les deux questions à se poser avant d'accorder une action à un agent

Avant d'étendre les autorisations d'un agent pour inclure une nouvelle fonctionnalité, forcez-vous à répondre à ces deux questions dans un seul paragraphe chacune. Pas une liste de contrôle – des phrases réelles.

Question 1 : Quel est le pire résultat plausible d'une telle action qui tourne mal, et combien de temps prendra la reprise ? Ce n'est pas le résultat moyen ; le pire plausible. Si l'agent pourrait théoriquement effectuer l'action dix mille fois avant que vous ne le remarquiez, utilisez ce numéro, pas un. « L'agent pourrait envoyer un mauvais e-mail » est une action de classe 3 ; "L'agent pourrait boucler et envoyer le même mauvais e-mail à un millier de destinataires avant que quoi que ce soit ne l'attrape" est une action de classe 4. C'est l'autonomie qui change la classe.

Question 2 : Quelle classe de personnes la récupération nécessitera-t-elle, et seront-elles disponibles lors d'une mauvaise journée ? Une récupération qui nécessite que vous soyez personnellement joignable dans les 15 minutes pour que la récupération soit toujours une action de classe 2 n'est pas vraiment de classe 2 : il s'agit de classe 3 avec une hypothèse de timing chanceux. Soyez honnête quant à savoir qui d’autre possède les informations d’identification nécessaires pour résoudre un mauvais cas et avec quelle fiabilité ces personnes peuvent être contactées.

Si vous ne pouvez pas répondre aux deux questions de manière satisfaisante dans un seul paragraphe chacune, la réponse à « dois-je accorder l'action ? » c'est non.

Les trois modes de défaillance que j'ai réellement vus

Mode d'échec 1 : "Ceci est uniquement pour la démo". Un agent obtient une autorisation plus large que nécessaire pendant le développement, car il est plus rapide de tout accorder et de la restreindre plus tard. Ensuite, la démo fonctionne, la démo devient une mise en scène, la mise en scène devient une production, et personne ne se souvient de restreindre les autorisations jusqu'au jour où l'agent se lance dans une affaire que lui-même, plus tard, aurait refusée. Grant est étroit dès la première ligne, même pendant le développement - cela prend dix minutes au début et c'est impossible après la mise en service car le véritable travail en dépend désormais.

Mode d'échec 2 : "La portée n'inclut pas les actions destructrices". La portée repo de GitHub, par exemple, inclut la suppression de branches, la poussée forcée et la suppression de fichiers. Cela ressemble à une portée en lecture-écriture et il s'agit en fait d'une portée « faire n'importe quoi sur ce référentiel ». Lisez les autorisations réelles de l'étendue avant de l'accorder, pas le nom de l'étendue. La plupart des étendues OAuth regroupent les actions que l'appelant n'a pas l'intention d'autoriser ; le regroupement est l'endroit où réside le rayon de souffle.

Mode d'échec 3 : "Nous ajouterons la surveillance plus tard". Toute autorisation de classe 2 ou de classe 3 accordée sans piste d'audit qui vous permet de remarquer une mauvaise action est silencieusement une action de classe 4, car l'horloge de récupération ne démarre que lorsque quelqu'un le remarque, et si personne ne le remarque, il n'y a pas de récupération - il y a simplement des dommages accumulés. La piste d'audit est ce qui définit la classe autant que l'action. C’est tout l’argument du what to log when an AI agent acts on your behalf : la journalisation n’est pas une documentation, c’est la mesure de confinement.

Le "l'humain a-t-il sa place ici ?" question

Une fois que vous avez classé une action, une décision spécifique sépare l'automatisation bien gérée du théâtre : mettez-vous un humain dans le circuit ?

La valeur par défaut de l'industrie est : oui, sur tout ce qui est de classe 3 ou supérieure. C'est la mauvaise réponse, et c'est la mauvaise réponse pour la même raison que « ajouter simplement une étape de révision » échoue partout ailleurs : un humain qui doit approuver deux cents choses par semaine n'est pas un contrôle, il s'agit d'un tampon en caoutchouc avec une chaise. Le contrôle humain n'est réel que si l'humain peut réellement distinguer un bon résultat d'un mauvais, et si le volume est suffisamment faible pour qu'il puisse y prêter attention.

Deux règles qui fonctionnent en pratique :

1. Un contrôle humain n'est un contrôle que lorsque l'humain peut refuser. Si refuser coûte cher (bloque la libération, retarde le client, signifie une conversation difficile), l'humain ne refusera pas systématiquement, le contrôle est donc du théâtre. Si le travail de l'évaluateur est d'avoir raison, pas d'être populaire, et que refuser est véritablement gratuit, le contrôle fonctionne. 2. Un contrôle humain sur 20 articles par semaine est un contrôle ; un contrôle humain sur 200 articles par semaine ne l'est pas. En dessous d'un seuil, les humains y prêtent attention. Au-dessus, ils arrêtent de lire. Le seuil varie selon la tâche, mais il est bien inférieur à ce que la plupart des systèmes supposent : j'utilise "si j'ouvre chacun d'entre eux individuellement, il est en dessous du seuil ; si je survole, ce n'est pas le cas".

Là où un contrôle humain est un théâtre, la réponse honnête n’est pas « d’ajouter une meilleure liste de contrôle ». Il s'agit soit d'automatiser entièrement la décision spécifique (le contrôle n'ajoute pas de valeur ; supprimez-la), soit de réduire le volume jusqu'à ce qu'un humain puisse réellement le prendre (le contrôle est important ; le volume est le problème, pas le contrôle). L’automatisation avec une étape de tamponnage est pire que l’automatisation sans étape, car la présence de l’étape détourne le blâme de la conception qui a rendu le volume trop élevé.

Les artefacts spécifiques dont une décision d'autorisation a besoin

Pour chaque classe d'action que vous accordez à un agent, trois artefacts spécifiques doivent exister. Si l’un des trois manque, l’autorisation n’a pas été accordée de manière responsable – elle a été accordée avec optimisme.

Artefact 1 — la piste d'audit externe à l'agent. Il ne s'agit pas du propre journal de l'agent sur ce qu'il a fait. Un enregistrement externe (un historique git, un journal de réponses API, une file d'attente de courrier électronique avec des ID de message) qui survit à la mort de l'agent, à la mort du processus et à la perte d'alimentation de la machine. La véritable preuve de l'action réside en dehors de l'acteur. Voir l'argumentation complète au what to log when an AI agent acts on your behalf ; la version très courte est que l’agent est le témoin le moins fiable de ses propres actions.

Artefact 2 — la procédure de récupération, écrite. Un document d'un paragraphe par classe d'action qui dit : "Si l'action X se déclenche mal, effectuez Y et Z dans cet ordre et attendez-vous à ce que la récupération se termine dans W minutes." Si la procédure n'existe pas, l'action n'est pas réellement récupérable : elle n'est pas récupérée mais n'est pas encore détectée. Écrivez la procédure avant la première fois que vous accordez l'autorisation, et non après la première fois que vous en avez besoin.

Artefact 3 — le kill switch. Un endroit nommé unique où vous pouvez révoquer la capacité de l'agent à effectuer cette action en quelques secondes. Pour moi, sur ce site, les kill switch sont : la rotation du jeton GitHub OAuth (tue tout accès en écriture), la rotation du jeton de l'API Cloudflare (tue la vérification du déploiement) et la définition du cron exécuté quotidiennement sur désactivé (tue le déclencheur). Tous les trois sont documentés, tous les trois constituent une commande chacun et tous les trois sont des éléments que j'ai utilisés au moins une fois.

Sans un véritable kill switch, l’autorisation n’est pas une autorisation – c’est un fait accompli. N'accordez rien que vous ne puissiez révoquer en moins d'une minute.

Le plus difficile : les autorisations permanentes ou les autorisations juste à temps

L'erreur la plus courante dans les autorisations des agents consiste à accorder un accès permanent à une action de classe 3 afin que l'agent puisse « la gérer en cas de besoin ». Les autorisations permanentes sont la raison pour laquelle les actions de classe 3 se transforment en problèmes de classe 4 : un agent inactif ou compromis bénéficiant de privilèges permanents n'est pas inactif : il est exposé. C'est pourquoi les Microsoft's own guidance et industry security research on AI agent identities convergent tous deux vers la même recommandation : accorder des autorisations élevées uniquement pour le moment où elles sont nécessaires, avec un TTL court et une révocation automatique.

Le modèle juste à temps est le suivant : l'agent demande l'autorisation lorsqu'il en a besoin, obtient un jeton dont la durée de vie est mesurée en minutes et non en mois, et le jeton expire, que l'agent ait besoin de l'utiliser ou non. Si l'agent n'a pas besoin de l'autorisation pendant l'heure suivante, aucune exposition n'existe. Si l'agent est compromis au cours de cette heure, l'attaquant hérite d'un jeton qui expire avant de pouvoir pivoter.

C'est plus de travail à mettre en place. C’est aussi la différence entre un modèle d’autorisation qui survit à une mauvaise journée et un modèle qui transforme une mauvaise journée en un mauvais trimestre. Si vous envisagez de créer un seul élément d'infrastructure non évident pour votre agent, c'est celui-là.

Que faire mardi prochain

Si vous exécutez déjà des agents sur vos propres systèmes, effectuez les deux exercices suivants cette semaine.

Exercice 1. Notez chaque action que votre agent peut actuellement effectuer. Pas les noms des outils, mais les actions. "Engagez-vous à git." "Envoyer un HTTP POST à ​​mon point de terminaison d'analyse." "Lire une ligne de base de données." "Écrivez une ligne de base de données." Pour chacun, marquez la classe de la taxonomie ci-dessus.

Exercice 2. Pour chaque action de classe 3 ou de classe 4 de la liste, répondez au test des trois artefacts : piste d'audit de l'extérieur, procédure de récupération écrite, kill switch. Toute action qui échoue sur l'un des trois, soit rétrogradez l'action (révoquer l'autorisation jusqu'à ce que les artefacts existent), soit prenez le temps de construire l'artefact avant la prochaine exécution.

Si l’exercice dure une heure, vous avez une petite opération et cela vaut une heure. Si cela prend une semaine, vous avez une opération plus importante et le délai pour la réaliser maintenant est inférieur au coût de la première mauvaise journée à laquelle vous ne vous êtes pas préparé.

Où cela correspond-il au reste du travail

La limite des autorisations est le côté confinement de l’exécution d’agents sans surveillance. La piste d'audit est le côté diagnostic, au what to log when an AI agent acts on your behalf — le journal est ce qui vous indique pourquoi l'agent a fait ce qu'il a fait ; les autorisations limitent ce que l'agent aurait pu faire. Ensemble, ils constituent ce qui rend un système autonome opérationnel.

Si votre problème se situe en amont – vous n'avez pas encore décidé quelles tâches confier à un agent – ​​le cadrage du how to automate your work with AI est la première question. Et si votre mode de défaillance spécifique est le flux de travail qui fonctionne en vert et ne fait rien – une action silencieuse de classe 2 prétendant être terminée – le diagnostic se trouve au the automation failure nobody catches .

##FAQ

Combien de temps un jeton d'agent juste à temps doit-il durer ?

Assez longtemps pour l'action spécifique, et pas plus. Pour un cycle de validation et de diffusion de quelques minutes ; pour un travail par lots qui s'exécute en boucle, il s'agit de la longueur de la boucle plus un petit tampon. Si vous ne pouvez pas indiquer le nombre en minutes, le jeton est un accès permanent en costume.

Dois-je imposer une étape d'examen humain à chaque action de classe 3, ou l'automatiser entièrement ?

Ni par défaut. Si l'évaluateur peut véritablement refuser sans punition et que le volume est suffisamment faible pour qu'il lise chaque élément, conservez l'avis. Sinon, choisissez-en une : automatisez entièrement la décision ou réduisez le volume jusqu'à ce que l'examen soit réel. Une mesure d’approbation automatique est pire que rien, car elle blanchit la responsabilité.

Que se passe-t-il si mon agent a besoin d'une autorisation de classe 4 pour un cas limite spécifique ?

Ensuite, ce cas limite n’est pas automatisé. L'agent peut préparer l'action, enregistrer la demande et appeler un humain, mais la validation, l'envoi ou la suppression sont effectués par l'humain. La commodité de l’automatisation d’un cas de classe 4 ne vaut jamais la peine de construire la plomberie qui pourrait tous les exécuter.

Combien d'actions est-ce trop pour un jeton d'agent ?

Comptez les classes, pas les actions. Un jeton contenant n’importe quelle combinaison d’actions de classe 1 et de classe 2 convient ; un seul jeton couvrant les classes 2 et 3 est celui où le rayon d'explosion s'infiltre silencieusement, car les attentes d'audit pour les deux sont différentes. Divisez les jetons le long des limites de classe, et non le long des limites de fonctionnalités.

Ai-je besoin d'un kill switch si l'agent s'exécute uniquement selon un planning ?

Oui. Un agent planifié qui s'est déjà déclenché et qui est à mi-boucle est exactement le moment où vous devez révoquer l'accès, et « attendre la fenêtre suivante » n'est pas un kill switch. Si la rotation du jeton ou la désactivation du déclencheur ne constituent pas une seule commande documentée que vous avez exécutée au moins une fois, vous n'en avez pas.

L'agent doit-il rédiger son propre journal d'audit ou dois-je m'appuyer sur des systèmes externes ?

Systèmes externes. L'agent est le témoin le moins fiable de ses propres actions : un agent en panne, tué ou compromis ne finira pas d'écrire son journal. L'historique Git, les journaux de réponses API et les files d'attente de messages survivent à la mort de l'agent ; le propre journal de bord de l'agent est une commodité et non une preuve.

Quel est le moyen le plus rapide d'auditer les autorisations que j'ai déjà accordées ?

Répertoriez toutes les actions que l'agent peut actuellement effectuer en anglais simple, marquez chacune d'entre elles avec une classe de la taxonomie et, pour chaque ligne de classe 3 ou de classe 4, vérifiez les trois artefacts : piste d'audit externe, procédure de récupération écrite, kill switch à une commande. Toute ligne manquant un artefact est révoquée jusqu'à ce que l'artefact existe. Une heure de ce travail coûte moins cher que la première mauvaise journée à laquelle vous ne vous êtes pas préparé.

La version en une phrase

Classez chaque action d'agent par rayon d'explosion avant de la classer par portée ; refuser entièrement les actions de classe 4, quelle que soit la portée du jeton ; exiger trois artefacts – piste d'audit externe, procédure de récupération écrite, kill switch à une commande – pour chaque autorisation de classe 2 et de classe 3 que vous accordez ; et n'accordez jamais d'accès permanent à une action de classe 3 lorsque le juste à temps suffit. Le modèle d’autorisations qui survit à une mauvaise journée est celui conçu autour de la mauvaise journée, et non de la bonne.