Une revue d'accès d'un agent d'IA est une décision périodique et signée sur chaque droit détenu par chaque agent : le conserver, le retirer ou le modifier. Les banques mènent déjà ce cycle pour les personnes : extraire chaque habilitation, adresser chaque ligne à un évaluateur responsable, consigner la certification ou la révocation, supprimer ce qui a été révoqué et conserver les preuves. Les agents ont besoin du même cycle avec une ligne plus large. Un droit d'agent couvre l'outil, l'action, le montant, les données, l'environnement, la porte d'approbation placée devant l'action et la date de fin du droit.
Ce guide décrit comment mener cette campagne. Le guide des permissions des agents d'IA explique comment concevoir les droits au départ, et l'article de référence sur le contrôle d'accès couvre le modèle opérationnel, de l'identité à la révocation. Cet article commence une fois les droits en place et se demande comment un évaluateur les certifie. Informations générales, à jour au 23 octobre 2026 ; elles ne remplacent pas un conseil juridique ou d'audit.
Ce que l'évaluateur certifie
Une revue des accès utilisateurs demande si une personne a toujours besoin d'un rôle. Une revue d'agent pose une question plus longue : cet agent a-t-il toujours besoin de chaque action qu'il peut effectuer, à cette limite, sur ces données, avec cette porte d'approbation, sous ce responsable, jusqu'à cette date ? Un nom de rôle y répond rarement. Deux agents ayant le même rôle peuvent détenir des outils différents, des limites de montant différentes et des exceptions différentes.
Certifiez l'autorité effective, c'est-à-dire les droits que l'agent peut réellement exercer aujourd'hui. Comparez quatre vues de chaque droit : ce que le responsable a demandé, ce qui a été approuvé, ce qui est configuré dans le fournisseur d'identité, la passerelle d'outils et la politique, et ce que l'agent a utilisé pendant la période de revue. Un droit approuvé et configuré mais jamais utilisé est candidat à la suppression. Un droit utilisé mais jamais approuvé constitue une constatation.
| Champ | Ce que voit l'évaluateur | Question à trancher |
|---|---|---|
| Agent et Release | Nom de l'agent, identifiant dans l'Agent Registry, Release actuelle, responsable | Le responsable est-il toujours en poste et toujours responsable ? |
| Action | Outil et opération, par exemple payments.create_transfer | Le processus métier a-t-il toujours besoin de cette action ? |
| Limite | Montant par action et par jour, règles de destination, limite de débit | La limite est-elle la plus basse qui permette encore au processus de fonctionner ? |
| Data Boundary | Systèmes, champs, régions et finalités que l'agent peut lire ou écrire | L'agent lit-il des données qu'il n'utilise plus ? |
| Porte d'approbation | La règle de politique qui renvoie require_approval et le rôle d'évaluateur vers lequel elle oriente | La porte est-elle toujours en place, et le rôle est-il toujours le bon ? |
| Identifiant | Identité, jeton ou secret, émetteur, durée de vie, dernière utilisation | L'identifiant est-il limité à cet agent et toujours nécessaire ? |
| Utilisation sur la période | Nombre d’actions autorisées, avec avertissement, approuvées, rejetées et bloquées | L'utilisation observée correspond-elle à la finalité déclarée ? |
| Date de fin | Expiration du mandat ou de l'exception | Le droit doit-il prendre fin plus tôt que prévu ? |
Reprendre le cycle de recertification bancaire
Une campagne de recertification a une population fixe, une date d'arrêté fixe, des évaluateurs nommés, une échéance et une étape de remédiation que quelqu'un vérifie. Conservez cette structure. Modifiez la ligne et ajoutez deux tests dont les revues humaines ont rarement besoin : la preuve que la porte d'approbation oriente toujours les demandes, et la preuve que la révocation arrête l'action suivante.
| Étape | Travail | Livrable |
|---|---|---|
| 1. Périmètre | Fixez la date d'arrêté. Rapprochez l'Agent Registry du fournisseur d'identité, du coffre de secrets, de la passerelle d'outils, des enregistrements de serveurs MCP et des journaux du runtime, afin que la population inclue les agents que personne n'a enregistrés. | Liste de la population avec la source de chaque entrée et les agents trouvés hors du registre |
| 2. Extraction | Exportez les droits effectifs de chaque agent sous forme de lignes, avec l'utilisation sur la période de revue. | Extraction signée ou hachée, avec son heure de génération |
| 3. Affectation | Adressez chaque agent à son responsable. Adressez les droits à privilèges et les exceptions à un second évaluateur extérieur à l'équipe propriétaire. | Affectation des évaluateurs avec contrôle des conflits d'intérêts |
| 4. Décision | Pour chaque ligne : certifier, modifier, révoquer ou consigner une exception avec une date de fin. | Une décision, un motif, un évaluateur et une heure par ligne |
| 5. Remédiation | Appliquez chaque modification et chaque révocation dans le système propriétaire du droit. | Reçu de modification par ligne, lié à la décision |
| 6. Vérification | Refaites l’extraction et comparez. Tentez une action révoquée par agent dans un environnement de test ou au moyen d’une simulation de politique. | Comparaison en boucle fermée et tentative refusée pour chaque droit révoqué |
| 7. Validation | Le responsable de la campagne consigne le périmètre, le taux de réalisation, les éléments en retard, les constatations et les limites. | Dossier de campagne prêt pour l'audit interne |
Fixer la fréquence des revues selon le risque et les événements
Pour les entités financières de l'UE soumises à DORA, la norme relative à la gestion du risque lié aux TIC fixe un plancher. L'article 21, paragraphe 1, point e), du règlement délégué (UE) 2024/1774 de la Commission exige des procédures de gestion des comptes qui attribuent les rôles et responsabilités pour « l'octroi, le réexamen et la révocation des droits d'accès », retirent sans retard injustifié les droits d'accès qui ne sont plus nécessaires et prévoient « la mise à jour des droits d’accès lorsque des modifications sont nécessaires et au moins une fois par an » pour les systèmes de TIC, et « au moins tous les six mois » pour les systèmes de TIC soutenant des fonctions critiques ou importantes. L'article 21, paragraphe 1, point a), exige que les droits suivent les principes du besoin d'en connaître, du besoin d'utiliser et du moindre privilège, et l'article 21, paragraphe 1, point c), exige que les utilisateurs soient « à tout moment identifiables pour les actions effectuées dans les systèmes de TIC ».
Le règlement traite des droits d'accès aux actifs de TIC en général et ne mentionne pas les agents d'IA. Un agent qui détient des identifiants d'accès à un système de TIC soutenant une fonction critique ou importante détient des droits d'accès à ce système. Demandez à votre fonction conformité si le plancher de six mois s'applique à lui. De nombreuses équipes revoient les agents plus souvent que les personnes, car un agent peut utiliser un droit des milliers de fois entre deux campagnes.
| Profil de l'agent | Revue planifiée | Événement déclenchant une revue immédiate |
|---|---|---|
| Déplace des fonds, modifie des dossiers clients ou envoie des communications externes | Trimestrielle | Nouvel outil, limite relevée, nouvelle Release, changement de responsable, incident ou série d'actions bloquées |
| Soutient une fonction critique ou importante sans accès en écriture | Tous les six mois | Nouvelle source de données, nouvelle région ou changement de finalité |
| Interne, en lecture seule, sans données personnelles | Annuelle | Toute demande d'accès en écriture |
Faire en sorte que chaque décision change quelque chose
Une revue qui se contente de collecter des approbations prouve peu de chose. Chaque décision doit laisser une trace dans la configuration ou dans un registre des exceptions daté.
| Décision | Suite à donner | Preuve |
|---|---|---|
| Certifier | Aucun changement. Le droit conserve sa date de fin actuelle. | Évaluateur, heure, motif et ligne d'extraction certifiée |
| Modifier | Abaisser une limite, restreindre une Data Boundary, avancer une date de fin ou ajouter une porte d'approbation. | Valeurs avant et après, reçu de modification, version de politique |
| Révoquer | Supprimer le droit dans le système propriétaire et révoquer tout identifiant qui ne servait qu'à lui. | Reçu de modification et tentative refusée après la suppression |
| Exception | Conserver un droit qui enfreint une règle, avec un contrôle compensatoire et une date de fin au plus tard à la campagne suivante. | Responsable de l'exception, approbateur, contrôle compensatoire, expiration |
| Absence de réponse à l'échéance | Remonter au supérieur hiérarchique du responsable. Votre politique détermine si le droit est suspendu à l'échéance finale. | Historique des remontées et état final du droit |
Des tests qui repèrent ce qu'une validation laisse passer
Exécutez ces tests sur l'extraction avant que les évaluateurs ne la voient, et affichez les résultats sur la ligne. Ils transforment une appréciation en constatation chiffrée.
- Droit inutilisé : accordé pendant toute la période et jamais exercé. Proposez la révocation par défaut et demandez au responsable de justifier son maintien.
- Utilisation non approuvée : l'agent a exercé un droit sans enregistrement d'approbation. Émettez une constatation avant la clôture de la campagne.
- Combinaison toxique : un même agent peut à la fois créer un bénéficiaire et libérer un paiement, ou à la fois rédiger et approuver. Séparez les droits ou placez un rôle humain différent d'un côté.
- Porte manquante : une modification de politique depuis la dernière campagne a supprimé ou affaibli une règle require_approval. Comparez les versions de politique ligne par ligne.
- Auto-évaluation : l'évaluateur est la personne qui a demandé le droit ou qui parraine l'agent. Réaffectez.
- Responsable orphelin : le responsable est parti ou a changé de fonction. Suspendez les nouveaux droits jusqu'à ce qu'un nouveau responsable accepte.
- Identifiant partagé : un même secret sert plusieurs agents. L'utilisation ne peut pas être attribuée, la ligne ne peut donc pas être certifiée.
- Exception expirée toujours active : la date de fin de l'exception est passée et le droit fonctionne encore.
Exemple détaillé : revue trimestrielle d'un agent de paiement
L'agent, les chiffres et les identités ci-dessous sont synthétiques. Un agent des opérations de trésorerie prépare et libère les paiements fournisseurs. La période de revue va du 1er juillet au 30 septembre 2026. Son responsable est le responsable des opérations de trésorerie ; les lignes à privilèges vont à un second évaluateur au sein du risque opérationnel.
| Ligne | Observé sur la période | Décision | Suite donnée |
|---|---|---|---|
| payments.create_transfer jusqu’à 50 000 EUR vers des bénéficiaires existants | 1 412 actions autorisées, 0 bloquée | Certifier | Aucune |
| payments.create_transfer au-delà de 50 000 EUR, soumis à require_approval auprès d’un vérificateur de trésorerie | 37 demandes d'approbation, 35 approuvées, 2 rejetées | Certifier | Aucune ; porte confirmée dans la version de politique actuelle |
| beneficiaries.create | 3 utilisations, toutes pour un projet d'intégration de fournisseur terminé en août | Révoquer | Droit supprimé ; la tentative en test a renvoyé block |
| erp.read_invoices sur toutes les filiales | Lectures dans deux des cinq filiales | Modifier | Data Boundary restreinte aux deux filiales |
| Exception : libération avant nouveau filtrage sanctions pour les virements intragroupe | Accordée en juin avec une date de fin au 30 septembre 2026 | Exception expirée | Exception clôturée ; le droit suit désormais la règle standard |
| Clé d'API partagée avec l'agent de rapprochement | L'utilisation ne peut pas être répartie par agent | Constatation | Nouvel identifiant propre à l’agent émis ; clé partagée révoquée |
La place de KLA dans une revue d'accès
KLA ne dispose d'aucun module de campagne de revue d'accès. La revue se déroule dans votre outil de gouvernance des identités ou dans votre dossier de travail. KLA Control Plane détient plusieurs des éléments dont un évaluateur a besoin et applique la décision de révocation sur le chemin des actions gouvernées. Cette section décrit le code source actuel.
Pour les agents qui agissent via l'entrée des actions d'agents de KLA, chaque agent opère sous un mandat d'agent : un enregistrement versionné comprenant un responsable, un mandant institutionnel, les outils, opérations et destinations autorisés, les finalités, les environnements, des contraintes de seuil sur les paramètres des actions et une période de validité avec une date de fin obligatoire. La personne qui a créé un mandat ne peut pas l'approuver. La liste des mandats d'un agent renvoie ce périmètre avec ses dates de validité et les acteurs de son cycle de vie, ce qui fournit à l'évaluateur les lignes pour ce chemin.
Une décision de révocation correspond à la révocation du mandat. Seuls les rôles d'administrateur du tenant et de responsable de la conformité peuvent révoquer, et un motif est obligatoire. La révocation bloque les propositions ouvertes liées à ce mandat avec le code motif mandate_revoked et annule leurs Decision Requests en attente. L'action suivante que l'agent propose sous un mandat révoqué ou expiré est refusée avant d'être enregistrée comme proposition. Une action déjà admise peut encore aboutir. Chaque révocation est écrite dans un enregistrement en ajout seul du cycle de vie du mandat, inclus dans l'export des preuves.
Chaque action gouvernée reçoit l'un de quatre résultats de politique : allow, warn, require_approval ou block. Ces résultats fournissent les compteurs d'utilisation de la ligne. Decision Desk refuse les décisions du demandeur enregistré, vérifie le rôle d'évaluateur requis et enregistre la décision avec une note et les rôles de l'évaluateur à ce moment-là. Les droits détenus hors de KLA, tels que les groupes du fournisseur d'identité, les secrets du coffre et les comptes des systèmes cibles, restent dans leurs systèmes propriétaires et nécessitent leur propre extraction.
Une ligne certifiée ne tient que si l'application des règles vérifie la même identité d'agent. En août 2026, en rédigeant une règle d'approbation des paiements dans notre propre tenant de test, nous avons constaté que le périmètre d'agent d'une politique n'était pas encore appliqué à l'exécution. Nous avons modifié la correspondance des politiques pour qu'elle vérifie l'identité de l'agent agissant à chaque appel et échoue en mode fermé lorsque cette identité manque. Nos tests d'acceptation automatisés dans les tenants de test utilisent aussi deux identités, l'une pour lancer un run gouverné et l'autre pour trancher ses Decision Requests, car Decision Desk refuse une décision du demandeur et exige un motif pour chaque décision.
Sources primaires
Revue des sources achevée le 23 octobre 2026. Le règlement délégué (UE) 2024/1774 de la Commission complète le règlement (UE) 2022/2554 (DORA) par des normes techniques de réglementation précisant le cadre de gestion du risque lié aux TIC. Les citations ci-dessus proviennent de l'article 21, « Contrôle d'accès ». Le règlement fixe des obligations aux entités financières relevant de DORA ; la table de cadence, les champs des lignes, les tests et l'exemple détaillé de ce guide sont des modèles de mise en œuvre sans valeur juridique. Vérifiez avec votre fonction conformité quelles fonctions vous classez comme critiques ou importantes.
Foire aux questions
Qu'est-ce qu'une revue d'accès d'un agent d'IA ?
C'est une campagne périodique au cours de laquelle un évaluateur nommément désigné décide, pour chaque droit détenu par un agent, de le certifier, de le modifier, de le révoquer ou de le conserver comme exception limitée dans le temps. Le droit couvre l'outil, l'action, le montant, les données, l'environnement, la porte d'approbation, l'identifiant et la date de fin.
À quelle fréquence faut-il revoir les accès des agents d'IA ?
Fixez la cadence selon le risque et ajoutez des revues déclenchées par des événements. Pour les entités financières de l'UE soumises à DORA, le règlement délégué (UE) 2024/1774 impose de mettre à jour les droits d'accès au moins une fois par an, et au moins tous les six mois pour les systèmes de TIC soutenant des fonctions critiques ou importantes. Les agents qui déplacent des fonds ou modifient des dossiers clients sont souvent revus chaque trimestre.
Qui doit revoir les habilitations d'un agent d'IA ?
Le responsable de l'agent revoit les droits ordinaires. Un second évaluateur extérieur à l'équipe propriétaire revoit les droits à privilèges et les exceptions. La personne qui a demandé un droit ne doit pas le certifier.
Comment auditer et certifier les droits d'accès des agents d'IA ?
Rapprochez la population complète des agents entre le registre, le fournisseur d'identité, les secrets, les passerelles et les journaux. Extrayez les droits effectifs avec l'utilisation sur la période. Adressez chaque ligne à un évaluateur, consignez la certification, la modification, la révocation ou l'exception, appliquez les changements, refaites l'extraction pour les confirmer, et tentez une action révoquée pour prouver qu'elle est refusée.
Quelles preuves un auditeur attend-il d'une revue des accès d'agents ?
La population et la manière dont elle a été rapprochée, l'extraction avec son heure de génération, les affectations des évaluateurs, une décision par ligne avec motif et heure, les reçus de modification pour chaque modification et révocation, la comparaison après nouvelle extraction, les tentatives refusées pour les droits révoqués, le registre des exceptions et la validation de la campagne avec ses limites.
En quoi une revue des accès d'agents diffère-t-elle d'une revue des accès utilisateurs ?
Le cycle est le même. La ligne est plus large, car un droit d'agent inclut des limites de montant, un périmètre de données, la porte d'approbation placée devant l'action et une date de fin. Les données d'utilisation sont plus riches, ce qui permet de mesurer les droits inutilisés et les utilisations non approuvées. La révocation doit aussi être testée, car un agent peut agir de nouveau en quelques secondes.
Points clés à retenir
Menez la campagne des agents avec la même rigueur que celle que les banques appliquent aux personnes : une population fixe, un évaluateur pour chaque ligne, une décision qui change quelque chose, une vérification que le changement a pris effet et un enregistrement signé. Commencez par la checklist de revue des habilitations, faites passer un agent à haut risque par les sept étapes et conservez le dossier de campagne pour le prochain audit.