Autoriser un agent IA tâche par tâche : pourquoi les rôles ne suffisent plus

Presque toutes les entreprises ont une politique d'accès pour leurs agents IA, la moitié seulement la vérifie au moment où l'agent agit. Le rôle ne suffit plus : il faut autoriser tâche par tâche.

Une enquête publiée fin septembre 2026 auprès de 2 254 responsables informatiques et sécurité, dans huit pays dont la France, donne la mesure d'un écart. Presque tous déclarent une politique écrite sur les données que les outils et agents d'IA peuvent atteindre. Environ la moitié seulement déclare vérifier ces accès en temps réel au regard de cette politique, et moins d'un sur cinq a détecté sur le moment le dernier accès hors périmètre. Un peu plus d'un tiers seulement sait toujours remonter d'un accès d'IA à des données sensibles jusqu'à la personne qui l'a autorisé. La politique est écrite, mais elle n'est pas vérifiée au moment où l'agent agit.

J'appelle ici agent un programme qui, conduit par un modèle, décide lui-même des outils qu'il appelle et des actions qu'il enchaîne. Pour les humains, l'entreprise a réglé la question des droits avec le rôle. Pour un salarié, le rôle inscrit dans l'annuaire reprend un dossier déjà validé, contrat, fiche de poste, demande d'accès passée par le manager. Ce modèle, décrit en 1992 par deux chercheurs du NIST, a tenu parce qu'un rôle changeait lentement et parce qu'un auditeur pouvait relire la matrice et la signer. Ce que l'annuaire dit d'un agent, qui n'a rien de ce dossier, doit donc être réévalué à chaque appel d'outil, au regard de la tâche en cours.

Quatre raisons pour lesquelles le rôle décroche

Prenons un agent d'achats que sollicitent trois collaborateurs. La trésorerie demande une synthèse de risque fournisseur, les opérations une commande de lubrifiant industriel, le juridique les clauses d'un contrat cadre. Faute d'un contrôle qui réduise le périmètre selon l'appelant et l'action, le rôle attaché à l'agent couvre l'union de ce que les trois pourraient un jour lui demander. L'agent porte alors en permanence une autorité qu'aucun de ses appels ne justifie.

La deuxième raison tient à la tâche. Le même agent, qui cherche trois fournisseurs bien notés puis renégocie un contrat cadre, n'a pas besoin des mêmes droits pour les deux. La première lit une base, la seconde écrit dans des contrats, sous plafond de dépense. La troisième raison est combinatoire. À titre d'illustration, un rôle par agent, par tâche et par appelant donnerait, avec dix agents, vingt tâches et mille collaborateurs, deux cent mille rôles qu'aucun auditeur ne relirait. La quatrième tient à l'agent lui-même, dont le choix des outils peut varier d'une exécution à l'autre. Vérifier le rôle à l'ouverture de la session, puis faire confiance, revient à autoriser à la cinquième minute un outil que rien ne laissait prévoir à la troisième. La décision doit donc être prise à chaque appel d'outil.

En avril 2026, un hébergeur d'applications a annoncé une intrusion dans ses systèmes internes. Elle est partie d'un outil d'IA tiers auquel un salarié avait accordé, depuis son compte d'entreprise, toutes les permissions que l'outil demandait sur sa suite bureautique en ligne. L'outil a été compromis, son jeton rejoué, et l'attaquant est entré dans l'espace de travail du salarié, puis plus loin. Selon l'éditeur de l'outil, un jeton OAuth compromis a suffi pour entrer dans cet espace de travail. Les permissions, accordées une fois, étaient restées actives. Le modèle de menace publié le 12 octobre par la fondation OpenID pour les agents qui appellent des outils d'une autre plateforme retient le même motif, un accès qui survit à la tâche.

Un mandat par tâche

L'analogie utile est celle du mandat, qu'un avocat ou un agent immobilier reçoit pour une opération précise et une durée précise, et qui ne voyage pas vers une autre affaire. L'autorisation d'un agent IA peut prendre cette forme, rendue vérifiable par la cryptographie. L'agent reçoit, au départ d'une tâche, un jeton signé qui décrit ce qu'il peut faire, sur quelles ressources, pour qui et jusqu'à quelle heure. Le jeton porte la tâche, il ne porte pas un rôle. Il vit quelques minutes, ce qui réduit la fenêtre de rejeu sans la supprimer. Journalisé, il répond à "quelle tâche, quel utilisateur, quelles données, quel moment". Quand un agent en sollicite un autre, le serveur d'autorisation émet un jeton dérivé, limité à cette délégation et jamais plus large que le premier.

Rien de cela n'attend une invention, car l'échange de jetons OAuth, les demandes d'autorisation enrichies et le protocole GNAP, publiés par l'IETF entre 2020 et 2024, prévoient déjà des mécanismes pour transmettre une autorisation en la restreignant. Un brouillon de l'IETF daté de septembre 2026 applique l'échange de jetons aux agents IA, et le NIST a mis en consultation en février un projet de démonstration sur le sujet.

Pour les entités financières, DORA demande de limiter l'accès logique aux actifs de TIC à ce que requièrent des fonctions légitimes et approuvées, et ses normes techniques une journalisation qui enregistre les accès. NIS 2, pas encore transposée en France, demande des politiques de contrôle d'accès. Un rôle partagé entre trois appelants et vingt tâches produit, à mon sens, difficilement cette preuve.

Cinq gestes avec l'IAM en place

Le premier dresse l'inventaire des agents, avec les outils qu'ils atteignent et l'identifiant qui porte le droit, et signale tout agent branché sur plus de dix outils, par exemple, ou sur les données de plusieurs métiers. Le deuxième donne à chaque sollicitation d'un agent un identifiant de tâche qui suit tous ses appels, sans quoi le journal retombe à la granularité de la session. Le troisième place devant chaque outil, à côté de l'IAM existant, un contrôle que l'agent ne peut contourner et qui décide à chaque appel. Le quatrième fait porter aux appels d'agent à outil et d'agent à agent une délégation explicite, par échange de jetons. Le cinquième journalise à la granularité de la tâche, qui a lancé, quel périmètre, quelle décision, et route ce journal vers la supervision de sécurité. Pour commencer lundi, une question écrite à la DSI suffit : "Quels agents disposent aujourd'hui d'accès permanents, accordés par qui, et révoqués comment ?"

Sources

Enquête Delinea auprès de 2 254 responsables IT et sécurité, septembre 2026 : delinea.com/resources/ai-policy-enforcement-report
Incident d’avril 2026 : bulletin de sécurité de Vercel du 19 avril 2026, vercel.com/kb/bulletin/vercel-april-2026-security-incident
Modèle de menace de la fondation OpenID pour les agents IA, 12 octobre 2026 : openid.net
Standards IETF sur l’échange et la restriction des autorisations (2020-2024) et brouillon sur l’identité des agents IA (septembre 2026) : datatracker.ietf.org ; projet du NIST, février 2026 : nist.gov
DORA, article 9 ; NIS 2, article 21.