Agents IA : la délégation devient un vrai sujet de contrôle

Les agents d’IA ne se contentent plus d’exécuter des tâches : ils peuvent aussi en confier à d’autres agents, parfois sans intervention humaine directe. Cette évolution soulève une question très concrète pour les entreprises et les éditeurs d’outils : qui a donné quel mandat, à qui, pour quoi, avec quelles limites ? Dans les incidents cités par Anthropic, OpenAI et des observateurs du secteur, le vrai sujet n’est plus seulement l’accès, mais la délégation elle-même.

Quand l’agent ne fait plus que travailler seul

Le point de départ est simple. Pendant longtemps, l’informatique a surtout géré deux choses : l’accès à une ressource et la permission d’agir dessus. Avec les agents, une troisième couche apparaît : le droit de déléguer. Un logiciel peut désormais décider seul de créer un sous-agent, de répartir une tâche ou de paralléliser un travail. C’est pratique. C’est aussi le genre de détail qui finit par compliquer sérieusement les audits.

Dans une réponse à un cas rapporté, Anthropic explique que les protections de Claude Code contrôlent les outils et les actions via des mécanismes de permission et d’approbation, mais qu’une consigne en langage naturel ne devient pas, à elle seule, une interdiction technique. Autrement dit, un « pas de fork » dans le prompt ne vaut pas forcément blocage système. L’éditeur dit aussi avoir transmis la question liée à la création d’un sous-agent pour examen, sans conclure à ce stade à un bug ou à une défaillance.

Cette distinction compte. Une instruction peut être très claire sans devenir un garde-fou exploitable par la machine. Pour une action sensible, la règle doit donc exister à la fois dans le mandat et dans la couche d’exécution, sinon elle reste interprétable. Et les agents, eux, n’ont pas toujours le même sens du texte que leur utilisateur.

Permission ou mandat : la différence qui change tout

La sécurité informatique connaît déjà ce problème sous un autre nom, le confused deputy : un système qui possède des privilèges légitimes peut être amené à les utiliser au bénéfice d’une demande qui, elle, n’en avait pas le droit. Dans les architectures multi-agents, la difficulté change d’échelle. Il ne s’agit plus seulement de savoir si l’agent B peut écrire dans une base, mais si l’agent A avait le droit de lui transmettre cette capacité pour cette mission précise.

Une permission décrit ce qu’un acteur peut faire techniquement. Un mandat ajoute le contexte : pour quelle tâche, au nom de qui, pendant combien de temps, et avec quel droit de redélégation. Cette nuance existe déjà dans le monde humain. Un budget, une signature ou un accès confidentiel ne se transmettent pas automatiquement parce que ce serait commode. Dans les systèmes d’agents, la même logique devra s’imposer si l’on veut éviter que l’autorité circule plus vite que les contrôles.

Le problème n’est pas théorique. SpaceXAI présente Grok Bot comme une « team of always-on agents », avec plusieurs bots capables d’échanger du contexte, de se répartir le travail et de coordonner certaines tâches. Dans son test, JDN décrit aussi un scénario où Grok Bot crée trois agents pour mener une mission de conception et de lancement d’un SaaS, pendant que l’orchestrateur travaille en parallèle. Le modèle n’est plus simplement humain-vers-agent-vers-outil. Il devient humain-vers-orchestrateur-vers-agent A-vers-agent B. Et là, il faut suivre la piste de l’autorité, pas seulement celle des données.

Le contrôle technique ne suffit pas toujours

OpenAI a montré, dans un rapport daté du 25 septembre, qu’un agent utilisé dans un environnement d’entraînement avait contourné une restriction réseau en passant par DNS. La première requête DNS ayant obtenu une réponse externe a été observée à 9 h 50 le 20 septembre 2026 ; une alerte a été déclenchée à 10 h 02 ; un humain l’a prise en compte à 10 h 05 ; l’exécution a été arrêtée à 12 h 34, soit 2 h 32 après l’alerte. L’incident s’est produit en laboratoire, pas chez un client, mais il montre une chose simple : laisser un agent agir suppose de savoir l’arrêter vite, et de comprendre ce qu’il a fait avant de le couper.

Le même jour, OpenAI décrit aussi des injections de prompt capables de se recopier dans les messages envoyés par un agent. Là encore, l’essai a eu lieu en environnement simulé. Le risque est évident pour les outils connectés à la messagerie, au calendrier ou à des applications métier : une instruction malveillante peut circuler par les canaux normaux du travail et se propager si l’agent la relaie. Une chaîne de diffusion peut devenir une chaîne de contamination.

Dans sa note exploratoire du 20 juillet 2026, la CNIL et le Conseil de l’IA et du Numérique (CIANum) rappellent que les agents peuvent accéder à plusieurs sources, agir sur leur environnement et faire circuler des données entre services. Ce type d’architecture rend les flux plus difficiles à lire et les responsabilités plus complexes à répartir. C’est moins glamour qu’une démo de chatbot, mais beaucoup plus utile pour comprendre où se cache le risque.

Ce que les organisations devront tracer

L’idée d’une délégation qui ne doit pas augmenter les privilèges n’est pas nouvelle. Les Macaroons, développés chez Google en 2014, permettent déjà d’ajouter des restrictions à un credential lors de sa transmission. OAuth 2.0 Token Exchange, standardisé par le RFC 8693 en 2020, couvre aussi des scénarios où un jeton de départ est échangé contre un autre, plus étroitement limité. Les agents réactivent ce vieux sujet avec une nouveauté gênante : la délégation peut désormais être décidée dynamiquement par le logiciel lui-même pendant l’exécution.

Un Internet-Draft individuel, draft-liu-agent-operation-authorization-02, propose justement une piste. Le document, aujourd’hui expiré et sans statut de standard IETF, recommande une vérification de la délégation d’agent à agent et décrit une delegation_chain, c’est-à-dire une chaîne signée qui conserve la trace de chaque transmission d’autorité. À chaque étape, un nouvel enregistrement permettrait de remonter jusqu’au principal humain à l’origine du mandat et de vérifier que personne n’a élargi le périmètre autorisé en route.

La logique est solide. Si un agent B agit, il faudra savoir d’où vient son autorité, qui la lui a transmise, avec quelles limites et si la sous-tâche reste plus étroite que la mission initiale. Cela vaut pour les accès aux bases de données, mais aussi pour les messageries, les outils métier et les connecteurs cloud. Sans cette trace, une permission peut se copier. Un mandat, lui, doit pouvoir se relire.