Accès juste-à-temps pour les agents IA : mode d’emploi

Ce que signifie l’accès juste-à-temps pour un agent IA

L’accès juste-à-temps pour un agent IA est une permission accordée au moment où l’agent en a besoin, limitée à une intégration et à un type d’action, pour une fenêtre bornée, et retirée sans que personne ait à y penser. L’agent demande à l’exécution, une politique décide, chaque appel d’outil est vérifié contre le résultat, et l’attribution prend fin à son échéance ou après un seul appel.

Nous avons traité le cas général dans L’accès juste-à-temps pour les collaborateurs et les agents IA : pourquoi l’accès permanent revient dans les rapports de violation, comment fonctionnent les durées et les approbations, et ce qui se passe à l’échéance. Cet article ne le répète pas. Il porte sur ce qui change quand le demandeur est un logiciel : où la décision est prise, ce que doit contenir une politique d’accès pour agents, et comment fonctionne la révocation quand il n’y a aucun compte à déprovisionner.

Pourquoi l’accès permanent est pire pour un agent

La manière habituelle de donner un accès à un agent consiste à coller une clé d’API dans sa configuration. Nous avons décrit ce schéma dans La gouvernance MCP : la clé porte tout ce que son créateur pouvait faire, elle expire rarement, et rien n’enregistre ce que l’agent en a fait.

Une personne qui détient un accès permanent doit encore décider de s’en servir. Un agent se sert de tout ce qu’il détient dès que ses instructions, ou le texte qu’il lit en chemin, l’y poussent. Son propriétaire change d’équipe et la clé fonctionne toujours. Le projet se termine et l’agent tourne encore. Un accès permanent sur un agent n’est pas une permission dormante. C’est une permission attachée à quelque chose qui agit en continu, à la vitesse d’une machine, sur des entrées que personne ne relit une à une.

Remplacer l’accès permanent par des décisions d’accès à l’exécution

Le changement tient à l’endroit où la décision se prend. Avec l’accès permanent, elle est prise une fois, à la mise en place, par la personne qui a configuré l’agent, et chaque appel ultérieur en hérite. Avec les décisions d’accès à l’exécution, elle est prise quand l’agent a réellement besoin de l’accès, contre la politique telle qu’elle est à cet instant, et chaque appel est vérifié contre le résultat.

Dans Lutril, cette décision se prend dans le proxy MCP. Les agents se connectent à un seul point d’accès MCP. Quand un appel d’outil échoue faute de permission, l’agent appelle un outil nommé request_access avec l’intégration, la portée (lecture ou écriture), un motif, et au besoin une durée en heures ou un indicateur d’usage unique. Voici la suite.

Quand la politique indique approbation requise, la demande part vers un approbateur dans Slack ou Teams, et l’agent est invité à rappeler request_access une fois la demande tranchée. L’approbateur choisit la fenêtre sur la carte. Pour des fenêtres de l’ordre de l’heure, inscrivez la durée dans la politique : les attributions approuvées automatiquement prennent le maximum de la politique ou moins, et les attributions à usage unique durent un appel.

Tant qu’aucune politique n’existe pour une intégration, l’accès juste-à-temps y est désactivé et le chemin par défaut s’applique : une lecture peut être approuvée automatiquement quand le demandeur détient déjà l’application avec un rôle éligible, et toute écriture passe par un humain. Rien ne change tant que vous n’avez pas écrit de politique, ce qui permet un déploiement sans risque, une intégration à la fois.

Ce que contient une politique d’accès pour agents IA

Les politiques se configurent par application sur la page Politiques, et chacune vise un seul public : les collaborateurs ou les agents IA. Une politique d’agent a la même forme que la version pour les collaborateurs décrite dans l’article général. Ce qui diffère, c’est le comportement de chaque réglage quand le demandeur est un agent.

Deux réglages sur l’agent lui-même complètent le tableau. Les rattachements du Registre des agents constituent le socle permanent de l’agent : les intégrations qu’il détient sans rien demander, éventuellement réduites à une liste d’outils, et jamais au-delà de ce que détient son propriétaire. L’interrupteur Usage unique seul fait de chaque attribution obtenue par l’agent une attribution d’un seul appel, sauf si la politique de l’intégration autorise l’accès permanent. Un schéma qui fonctionne : une liste de rattachements courte, l’usage unique seul pour les agents qui agissent rarement, et tout le reste derrière request_access.

Quatre règles propres aux agents

Les politiques d’agents tournent sur le même moteur que celles des collaborateurs. Quatre règles s’y ajoutent, et chacune comble une faille qui n’existerait pas pour une personne.

• Un agent ne peut jamais dépasser les accès de son propriétaire. La vérification s’exécute avant toute recherche d’attribution, et couvre donc l’approbation automatique, les demandes en attente et la réutilisation d’une attribution existante. La même vérification s’applique à la création d’un rattachement. Un refus est journalisé avec le motif owner_no_access.
• Le sujet est l’humain qui pilote l’agent. Les conditions comme le service, le statut RH ou les formations en attente s’évaluent contre cette personne, pas contre un compte de service sans attribut. Une condition du type « le service est Ingénierie » cesse donc de tenir pour l’agent dès qu’elle cesse de tenir pour la personne.
• La lecture ne devient pas écriture. La portée est appariée exactement, si bien qu’une politique de lecture ne répond jamais à une demande d’écriture. Sans politique, toute demande d’écriture passe par un approbateur humain.
• Une attribution peut durer exactement un appel. Une attribution à usage unique est consommée par le premier appel d’outil réussi. Un appel en échec ne la consomme pas. Une expiration de sécurité, dix minutes par défaut, la retire si l’appel n’arrive jamais.

Exemple concret : un agent SRE pendant un incident

Un cas courant : un agent d’astreinte doit lire le runbook et mettre à jour le ticket d’incident tant que l’incident est ouvert, et rien ne doit subsister ensuite. La mise en place tient en trois décisions. L’agent est enregistré avec l’ingénieur d’astreinte comme propriétaire, qui détient Notion et Redmine. La politique agents IA sur Notion approuve automatiquement pour le service ingénierie, avec un maximum de quatre heures. La politique agents IA sur Redmine approuve automatiquement sous la même condition, avec un maximum d’une heure, et l’agent demande l’usage unique quand il écrit.

Lisez ce journal comme le ferait un post-mortem. L’agent a obtenu la lecture du runbook en deux secondes, sans réveiller personne à deux heures du matin. Il a tenté d’atteindre une intégration que son propriétaire ne détient pas et a été refusé, avec le motif consigné. Il a obtenu l’écriture pour exactement une mise à jour de ticket, et cet accès avait disparu trois secondes plus tard. L’attribution Notion a cessé de fonctionner à son échéance, et la tâche de fond l’a marquée expirée à son passage suivant. Personne n’a ouvert de ticket pour retirer quoi que ce soit, et personne n’a eu à s’en souvenir.

C’est la réponse à la question que posent les équipes sécurité à propos des agents SRE en production : l’autorisation limitée dans le temps et la révocation automatique ne sont pas deux fonctionnalités à assembler. C’est une seule attribution, avec sa fin intégrée.

Comment fonctionne la révocation quand il n’y a aucun compte à retirer

Pour un collaborateur, l’expiration signifie un déprovisionnement à la source : la licence, l’appartenance au groupe, le rôle. Pour un agent qui passe par le proxy, il n’y a souvent aucune licence à retirer. Le proxy effectue l’appel avec le connecteur installé par votre administrateur, et l’attribution est un enregistrement que le proxy lit à chaque appel. La révocation, c’est l’attribution qui cesse d’être valide, ce qui peut arriver de quatre façons.

• Expiration. Une attribution dont l’échéance est passée n’est pas honorée au prochain appel. Une tâche de fond la marque ensuite expirée et journalise mcp.access.expired.
• Consommation. Une attribution à usage unique est marquée consommée, horodatage compris, par son premier appel réussi.
• Révocation manuelle. La page de l’agent dans le registre liste ses attributions en cours avec leur échéance et un bouton Révoquer. Le prochain appel d’outil sous une attribution révoquée est refusé.
• Suspension. Suspendre ou révoquer l’agent révoque toutes ses attributions actives et bloque ses identifiants. Le coupe-circuit prend effet au prochain appel de l’agent, en quelques secondes.

Ce qu’il faut demander à tout produit qui promet un accès limité dans le temps pour les agents

Si vous comparez des produits de contrôle d’accès pour agents IA, ces questions distinguent une vraie autorisation à l’exécution d’une colonne d’expiration dans une base de données.

L’accès juste-à-temps pour les agents n’est pas une discipline distincte de l’accès juste-à-temps pour les personnes. C’est le même moteur de politique, avec le sujet remplacé et quatre règles ajoutées, appliqué à l’endroit où un agent agit réellement. Pour le versant collaborateurs et la mécanique des échéances, lisez l’article général. Pour la couche proxy elle-même, lisez La gouvernance MCP. L’objectif est le même dans les deux cas : un accès que personne n’a renouvelé cesse d’exister, de lui-même.