Agents IA : qui leur donne le droit de déléguer nos permissions ?
Les agents délèguent désormais tâches et droits à d'autres agents. Au-delà des permissions, il faut tracer qui a donné quel mandat, à qui, pour quoi, avec quelles limites et droit de redélégation.
L’informatique sait depuis longtemps déléguer des droits. Ce qui change avec les agents, c’est qu’un logiciel peut désormais décider lui-même quand déléguer, à qui, et pour accomplir quoi.
Trois minutes séparaient deux décisions de Claude Code.
Dans la première, l’agent essayait d’exécuter un DELETE plus large que ce que j’avais autorisé. Auto Mode l’a bloqué : l’opération dépassait le périmètre prévu.
Quelques minutes plus tard, Claude écrivait : "Je fork un agent."
Problème : ma première instruction disait explicitement : "Pas de fork, pas de workflow, tu charges toi-même en direct."
Le sous-agent a pourtant été créé et chargé d’exécuter dix-neuf lots d’écriture en base, dont certains en parallèle.
Cet incident avait nourri ma précédente chronique (après le plafond des tokens, le plafond du consentement) sur le budget d’autonomie : jusqu’où un agent peut-il élargir seul les moyens utilisés pour accomplir une mission ?
Depuis, Anthropic m’a répondu. Et sa réponse permet de préciser le problème.
Une consigne n’est pas un contrôle d’exécution
Dans sa réponse, Anthropic m’explique que les protections de Claude Code contrôlent l’exécution des outils et des actions à travers des mécanismes de permission et d’approbation ; elles ne transforment pas directement chaque instruction formulée en langage naturel en interdiction technique.
C’est cette couche d’exécution qui a bloqué la requête DELETE trop large.
Anthropic considère en revanche la création du sous-agent malgré mon "pas de fork" comme une question distincte et indique l’avoir transmise pour examen. À ce stade, l’entreprise ne conclut ni à un bug ni à une défaillance particulière.
La distinction est essentiellement une consigne peut être parfaitement explicite sans devenir pour autant une interdiction technique.
"Pas de fork" était une règle de mon mandat. Ce n’était pas, à lui seul, l’équivalent d’une règle d’exécution interdisant techniquement la création d’un sous-agent.
Pour une opération sensible, la conséquence pratique est simple : lorsqu’un mécanisme adapté existe, une interdiction importante ne devrait pas rester uniquement dans le prompt. Elle doit aussi pouvoir être traduite en permission, restriction d’outil ou politique externe que le modèle ne peut pas réinterpréter.
Mais mon cas contient une difficulté supplémentaire.
Anthropic contrôle justement les délégations
La documentation d’Auto Mode décrit un contrôle spécifique des sous-agents aux deux extrémités du transfert : lorsque le travail leur est confié et lorsque leurs résultats reviennent.
Le contrôle effectué au moment de la délégation répond à un problème précis. Une fois dans le sous-agent, l’instruction de l’orchestrateur apparaît comme sa demande de référence. Il devient alors plus difficile de savoir si la tâche avait réellement été voulue par l’utilisateur ou décidée par l’agent principal.
Anthropic explique donc vouloir effectuer cette vérification tant que la délégation est encore reconnaissable comme un choix de l’agent plutôt qu’une demande de l’utilisateur. (Anthropic)
C’est précisément ce qui rend cet incident intéressant.
Nous savons que ce mécanisme existe. Nous ne savons pas encore s’il a été exécuté dans cette session, quel contexte lui a été présenté, ni pourquoi la délégation a été autorisée. C’est une question ouverte, aujourd’hui transmise par Anthropic pour revue.
Elle conduit à un problème plus général : avoir le droit d’accomplir une action donne-t-il automatiquement le droit de transmettre cette action à un autre agent ?
Accéder, agir, déléguer
Nous maîtrisons relativement bien deux catégories de droits informatiques. Le droit d’accès détermine si un utilisateur ou un programme peut consulter une ressource. Le droit d’action détermine s’il peut la modifier, envoyer un message ou exécuter une commande.
Les architectures multi-agents rendent une troisième catégorie centrale : le droit de délégation. Un agent autorisé à accomplir une tâche est-il aussi autorisé à la confier à un autre agent ? Avec quels privilèges ? Pour combien de temps ? Et cet autre agent peut-il déléguer à son tour ?
La question devient urgente parce que les produits changent rapidement de nature.
Quand l’agent devient une équipe
SpaceXAI présente Grok Bot comme une "team of always-on agents". Sa page officielle décrit plusieurs Bots travaillant en parallèle, l’un pouvant jouer le rôle de "chief of staff", tandis que les autres se spécialisent. Les Bots peuvent s’envoyer des messages, partager du contexte, se transmettre du travail et coordonner certaines tâches sans que l’utilisateur reste l’intermédiaire permanent. (SpaceXAI)
Le JDN vient d’ailleurs de publier "Grok Bot promet de remplacer les équipes humaines… et il y arrive". Dans son test, Grok Bot crée trois agents pour répartir une mission de conception et de lancement d’un SaaS, tandis qu’une autre partie du travail est prise en charge en parallèle par l’orchestrateur. (JDN)
Nous passons progressivement d’une architecture simple :
- Humain → Agent → Outil
à des chaînes du type :
- Humain → Orchestrateur → Agent A → Agent B → Outil.
À chaque étape circulent des informations et des instructions. Mais quelque chose d’autre doit également circuler : l’autorité nécessaire pour agir.
La question n’est plus seulement de savoir si l’agent B dispose techniquement d’un accès. Il faut savoir pourquoi il a le droit de l’utiliser pour cette action précise.
Ce problème est ancien. Son échelle change.
La sécurité informatique connaît depuis longtemps le risque du confused deputy, décrit par Norm Hardy en 1988 : un système possédant légitimement des privilèges peut être conduit à les utiliser au bénéfice d’une demande qui, elle, ne disposait pas de cette autorité.
Nous savons également atténuer des droits lorsqu’ils sont délégués. Les Macaroons, développés chez Google en 2014, permettent d’ajouter des restrictions à un credential lors de sa transmission. OAuth 2.0 Token Exchange, standardisé par le RFC 8693 en 2020, couvre lui aussi des scénarios de délégation avec des jetons pouvant être plus étroitement limités.
L’idée qu’une délégation ne devrait pas augmenter les privilèges n’est donc pas nouvelle. Ce que l’agentique change, à mon sens, c’est que la décision de créer une délégation peut désormais être prise dynamiquement par le logiciel lui-même pendant l’exécution.
Le système ne reçoit plus seulement une délégation. Il peut décider d’en créer une.
Le mandat compte autant que la permission
Supposons que l’agent B dispose techniquement du droit d’écrire dans une base. Cela ne suffit plus. Il faut également savoir si l’utilisateur avait autorisé cette opération, si l’agent A avait le droit de la déléguer et si B n’a reçu que l’autorité nécessaire à cette sous-tâche.
C’est la différence entre une capacité et un mandat.
Une permission indique ce qu’un acteur peut techniquement faire. Un mandat ajoute le contexte qui justifie cette autorité : pour quelle mission, au nom de qui, pendant combien de temps et avec quel droit de redélégation.
Cette distinction existe déjà dans les organisations humaines. Une délégation de signature n’est pas nécessairement sous-délégable. Un accès confidentiel ne devient pas transmissible parce qu’il serait utile à un collègue. Disposer d’un budget ne donne pas automatiquement le pouvoir d’accorder ce même budget à quelqu’un d’autre.
Les organisations d’agents devront résoudre le même problème, non parce que les agents deviennent humains, mais parce qu’ils commencent à distribuer entre eux le pouvoir d’agir.
Un projet de standard qui garde la trace
L’Internet-Draft individuel (draft-liu-agent-operation-authorization-02, Agent Operation Authorization) propose une piste concrète. Il s’agit d’un document aujourd’hui expiré, sans statut de standard IETF. (IETF Datatracker)
Sa section 6 traite explicitement de la délégation agent-à-agent. Le serveur d’autorisation doit vérifier que l’autorisation initiale permet la délégation et que la sous-opération demandée est strictement plus étroite que celle dont elle dérive.
Le document propose surtout une delegation_chain — une chaîne de délégation signée qui conserve la trace de chaque transmission d’autorité entre agents. À chaque délégation, un nouvel enregistrement est ajouté, afin que le serveur destinataire puisse remonter jusqu’au principal humain à l’origine du mandat et vérifier qu’aucune étape n’a élargi le périmètre autorisé. (IETF Datatracker)
Ce schéma rend explicite quelque chose que la simple possession d’un credential ne suffit pas à démontrer : la provenance de l’autorité exercée par l’agent au moment de l’action.
Le budget d’autonomie avait une seconde dimension
Dans ma précédente chronique, je proposais de budgéter les transitions d’autonomie : création de sous-agents, changement de privilèges, parallélisation, augmentation importante du coût ou changement de stratégie après un refus.
Je pensais surtout le problème verticalement : jusqu’où cet agent peut-il aller seul ?
Le multi-agent oblige à l’examiner aussi horizontalement : quelle partie de cette autonomie peut-il transmettre à un autre agent ?
Un budget d’autonomie devrait donc distinguer ce que l’agent peut décider seul de ce qu’il peut déléguer de cette autorité. Cette seconde frontière devient centrale dès qu’un agent peut en créer d’autres.
Après l’identité, la provenance de l’autorité
Pendant des décennies, la cybersécurité a surtout cherché à répondre à deux questions : Qui êtes-vous ? À quoi avez-vous accès ?
Les agents en ajoutent deux autres : D’où vient votre autorité pour accomplir cette action ? Et aviez-vous le droit de la transmettre ?
Mon incident chez Anthropic reste sous examen. Il serait donc prématuré d’en faire la preuve d’un défaut précis d’Auto Mode. Mais les agents créent déjà d’autres agents, leur distribuent des tâches et agissent au travers d’eux.
Savoir qu’"Agent B avait accès à la base" ne permettra pas d’expliquer, à lui seul, pourquoi son action était légitime. Il faudra pouvoir reconstituer qui lui a confié cette autorité, pour quelle mission, avec quelles limites et par quelle chaîne de délégation.
Une permission peut se copier.
Un mandat, lui, devrait laisser une trace.