Le contrôle d'accès d'un agent IA consiste à donner à un agent nommé l'autorité minimale du moment pour une seule finalité approuvée, à évaluer chaque action proposée au regard de cette autorité, à router les exceptions à fort enjeu vers un humain habilité, puis à consigner le résultat. Une conception complète va de la création de l'identité jusqu'à la révocation d'urgence. Elle résout les habilitations effectives en runtime, car les rôles, les affectations, la sensibilité des données, les montants et la politique peuvent changer entre la connexion et l'exécution.
Cet article traite de la conception et de l'exploitation du dispositif de contrôle. Le guide Permissions des agents IA couvre la revue périodique et la recertification des droits. Le guide Pistes d'audit des agents IA détaille la couche de preuve. Les recommandations sont indépendantes de tout éditeur et ont été vérifiées sur les sources primaires le 28 juillet 2026.
Un cycle de vie unique, de l'identité à la révocation
Attribuez à chaque agent un propriétaire durable, une finalité, une classe de risque, un environnement et une fiche d'identité avant d'ouvrir le moindre accès. Rattachez cette identité métier à une charge de travail ou à un client attesté. Accordez des habilitations étroites, avec une date d'expiration et une date de revue. Évaluez-les à chaque action. Consignez l'approbation et l'exécution sous les mêmes identifiants de corrélation. Retirez l'autorité dès que la finalité, le propriétaire, l'affectation, le risque ou l'environnement change.
Équivalent textuel. Le cycle commence par l'enregistrement et la liaison d'identité, passe par l'attribution, l'évaluation en runtime, l'approbation humaine, l'exécution, la preuve et la revue périodique, puis se termine par la révocation, la réconciliation et le rétablissement. Un changement de finalité, de propriétaire, de risque ou d'environnement ramène l'agent en revue avant toute exécution ultérieure.
Scroll horizontally to inspect the diagram.
Traitez l'accès comme un cycle de vie gouverné : un propriétaire, une expiration, une revue et un chemin de révocation testé.
Open full-size diagram| Étape | Décision | Responsable | Preuve |
|---|---|---|---|
| Enregistrer | Finalité de l'agent, risque, sponsor, tenant, environnement | Propriétaire métier | Fiche de registre et approbation |
| Lier l'identité | Agent, charge de travail, service et sujet délégué | Responsables IAM et plateforme | Émetteur, sujet, acteur, audience, attestation |
| Attribuer | Limites effectives d'outil, de ressource, de donnée, d'action et de contexte | Responsables des ressources et des politiques | Attribution, politique, expiration, dérogation |
| Évaluer | La demande du moment face à l'autorité du moment | Responsables autorisation et politiques | Entrées, résultat, codes de motif, versions |
| Approuver | Une personne habilitée libère la demande retenue, telle quelle | Responsable de l'autorité d'approbation | Instantané du rôle, justification, empreinte, expiration |
| Exécuter | La demande liée produit un seul effet | Responsables des outils et du processus | Accusé, état avant et après, effet aval |
| Revoir | L'accès reste nécessaire et proportionné | Propriétaire et réviseur indépendant | Population, exceptions, périmètre de certification |
| Révoquer | Couper l'autorité et solder les accès résiduels | Responsables incident, IAM et outils | Commandes, refus, sessions résiduelles, rétablissement |
Choisir le modèle d'identité avant d'attribuer des droits
Utilisez une identité d'agent dédiée pour une autorité d'entreprise récurrente. Ajoutez un sujet humain délégué lorsque l'affectation en cours de cette personne conditionne l'action. Rattachez l'agent à une identité de charge de travail (workload identity) pour que l'instance logicielle en cours d'exécution reste attribuable. Réservez les comptes de service partagés aux cibles historiques, derrière une passerelle obligatoire qui résout l'agent et la demande avant chaque appel.
| Modèle | À utiliser quand | Contrôle exigé | Risque principal |
|---|---|---|---|
| Agent dédié | L'organisation porte une autorité opérationnelle récurrente | Propriétaire nommé, attributions étroites, liaison à la charge de travail, cycle de vie | Accès permanent ou orphelin |
| Utilisateur délégué | Une personne reste titulaire de l'autorité | Liaison acteur-sujet, périmètre réduit, finalité, expiration | Privilège ambiant de l'utilisateur |
| Hybride | L'agent acteur et le sujet humain pèsent tous deux sur la décision | Échange de jetons ou double identité équivalente, audience, preuve | Confusion entre acteur et sujet |
| Compte de service intermédié | Une cible historique n'accepte qu'un seul identifiant technique | Passerelle obligatoire, politique par appel, détection de contournement, accusé | Identifiant partagé et attribution faible |
Combiner RBAC, ABAC et capacités de manière raisonnée
Le contrôle d'accès fondé sur les rôles (RBAC) fournit des devoirs de base lisibles. Le contrôle d'accès fondé sur les attributs (ABAC) resserre une demande à partir des attributs du sujet, de la ressource, de l'action et de l'environnement. Une capacité accorde à un porteur précis une autorité étroite, transférable selon des règles, sur une ressource ou une action. La plupart des systèmes agentiques en production utilisent les rôles pour l'affectation de base, les attributs pour le contexte du moment, et des capacités ou jetons de courte durée pour l'appel final.
| Modèle | Usage privilégié | Exemple | Exigence de contrôle |
|---|---|---|---|
| RBAC | Socles stables de poste ou de service | claims_reader lit les synthèses de sinistres qui lui sont affectées | Rôles restreints, séparation des tâches, revue périodique |
| ABAC | Décisions sensibles au contexte | Tenant, affectation, sensibilité, finalité, montant, localisation et heure concordent tous | Attributs fiables, fraîcheur, codes de motif |
| Capacité | Autorité d'appel étroite | Une attribution unique et de courte durée pour claim:1842 et settlement.propose | Audience, expiration, atténuation, défense contre le rejeu, révocation |
| Combinaison | Actions de production à fort enjeu | Le rôle ouvre l'éligibilité, les attributs bornent le contexte, la capacité lie l'appel | Une règle de précédence unique et un enregistrement de preuve unique |
Tenir les sept frontières du moindre privilège
La liste d'autorisation d'outils (allowlist) ne couvre qu'une frontière. La politique doit aussi borner les enregistrements, les champs, l'opération, le montant, la finalité métier, le déploiement et la durée. Attribuez à chaque frontière une source de vérité, un point d'application, un responsable de revue et un champ de preuve.
| Frontière | Question de politique | Exemple de contrôle | Preuve |
|---|---|---|---|
| Outil | Quel connecteur, quelle API ou quel serveur MCP peut recevoir un appel ? | Identité d'outil et destination sur liste d'autorisation | Identifiant d'outil, point de terminaison, version du serveur |
| Donnée | Quel tenant, quel enregistrement, quel champ, quelle région, quelle sensibilité ? | Dossier affecté et champs approuvés | Identifiants de ressource, jeu de champs, classification |
| Action | Quelle opération de lecture, de rédaction, de proposition, d'approbation ou d'exécution ? | Permissions distinctes pour proposer et pour exécuter | Opération et paramètres |
| Montant | Quel seuil de valeur ou de risque applique-t-on ? | Approbation à 25 000 euros, plafond à 100 000 euros | Devise, montant, seuils |
| Finalité | Quel usage métier déclaré autorise l'accès ? | La finalité vaut claim_settlement | Finalité, base légale ou contractuelle, dossier |
| Environnement | Quel tenant, quel compte, quelle région, quel réseau, quel déploiement ? | Une identité de production n'est acceptée qu'en production | Tenant, environnement, charge de travail |
| Durée | Quand et pour combien de temps ? | Jeton de 15 minutes, dans la limite de l'affectation active | Émission, prise d'effet, expiration, heure de décision |
Renvoyer un résultat de politique parmi quatre
Définissez la précédence et le comportement en cas de défaillance avant la mise en service. Une condition de blocage l'emporte. Une entrée obligatoire manquante ou une dépendance de politique indisponible fait basculer le système dans l'état sûr documenté. L'approbation ne libère que la demande, les paramètres, la preuve, la politique et le contexte que l'approbateur a effectivement vus.
Les quatre résultats restent des identifiants techniques : allow (autorisé), warn (autorisé avec signalement consigné), require_approval (retenu pour approbation humaine) et block (refusé avant tout effet).
| Résultat | Signification | Comportement d'exécution | Preuve |
|---|---|---|---|
allow | La demande entre dans l'autorité du moment et dans la politique | Exécuter la demande liée | Décision, versions, motifs, accusé |
warn | La demande peut aboutir avec un signalement consigné | Afficher le signalement et exécuter selon la politique définie | Signalement, règle d'acquittement, accusé |
require_approval | Une personne qualifiée doit trancher avant l'expiration | Retenir, puis approuver, refuser, demander des modifications ou escalader | Decision Request, autorité de l'approbateur, justification |
block | La demande dépasse l'autorité ou viole la politique | Arrêter avant l'effet | Motif de refus, empreinte de la demande, cible visée |
Placer l'approbation humaine là où l'action engage
Exigez une approbation pour les décisions qui affectent des droits, les effets irréversibles, les dérogations à la politique, les montants élevés, les communications externes sensibles, les élargissements d'accès et les situations d'incertitude inhabituelle. Résolvez au moment de la décision le rôle en cours de l'approbateur, sa limite de montant, sa délégation, sa formation, ses conflits d'intérêts et son lien avec l'initiateur.
En Europe, cette frontière recoupe souvent l'article 22 du RGPD : lorsqu'une décision entièrement automatisée produit des effets juridiques ou affecte la personne de manière significative, celle-ci peut obtenir une intervention humaine, exprimer son point de vue et contester la décision. Une approbation qui se limite à valider la proposition de l'agent sans accès aux faits sources ne constitue pas cette intervention. Le guide Gouvernance de l'IA dans les banques françaises et l'ACPR replace cette exigence dans le dispositif de contrôle interne.
- Montrer l'action proposée exacte, la cible, les valeurs, la personne concernée et l'effet attendu.
- Montrer le résultat de politique, les règles déclenchées, les codes de motif, les faits sources, l'incertitude et les faits manquants.
- Lier l'approbation à l'empreinte de la demande, à la version de politique, à l'instantané de la preuve, à l'approbateur et à l'expiration.
- Réévaluer l'autorité et la politique juste avant la libération.
- Garder ouverts les chemins de refus, de demande de modification, d'escalade, d'expiration et de recours.
Mener la revue des habilitations comme un test de contrôle
Partez de la population complète des agents et des comptes de service. Comparez l'autorité demandée, approuvée, configurée et observée. Examinez les attributions directes, les rôles hérités, les appartenances de groupe, les accès délégués, les serveurs MCP, les secrets de connecteurs, les dérogations d'urgence, les identités dormantes, la durée de vie des jetons et les permissions dans les systèmes cibles.
Téléchargez la trame de revue des habilitations des agents IA : demande de preuves, recensement des comptes de service, tests par échantillon, journal des dérogations et signature du réviseur.
| Rubrique | Valeur exigée | Test |
|---|---|---|
| Population | Tout agent, charge de travail, identité de service, passerelle et chemin délégué en production | Réconcilier registre, fournisseur d'identité, secrets, passerelles, outils et journaux d'exécution |
| Autorité | Outil, donnée, action, montant, finalité, environnement et durée effectifs | Comparer la politique approuvée à l'accès configuré puis à l'accès observé |
| Propriétaire et besoin | Propriétaire responsable nommé et finalité métier en cours | Faire confirmer par un réviseur indépendant |
| Dérogations | Motif, mesure compensatoire, approbateur, expiration | Rejeter les dérogations expirées ou sans propriétaire |
| Révocation | Actionneurs, dépendances, dernier test, accès résiduels | Exercer une désactivation représentative |
| Conclusion | Périmètre, critères, période, échantillons, constats, limites, prochaine revue | Consigner le périmètre de certification |
Recenser les comptes de service dans tous les plans de contrôle
Les comptes de service échappent souvent au registre des agents. Réconciliez l'IAM cloud, les applications du fournisseur d'identité, les identités de charge de travail, les comptes de service Kubernetes, les identités d'intégration continue, les entrées de coffre-fort et de gestionnaire de secrets, les passerelles d'API, les enregistrements de serveurs MCP, les installations de connecteurs, les journaux d'audit des systèmes cibles et les traces de sortie réseau.
- Signaler les credentials sans propriétaire, sans dernier usage connu, sans expiration, à périmètre générique, ou utilisés depuis plusieurs environnements.
- Tracer chaque identifiant partagé à travers la passerelle jusqu'à l'agent, au tenant, à la demande et à l'accusé aval.
- Comparer les destinations et opérations observées aux frontières d'outil et d'action approuvées.
- Renouveler ou retirer les credentials dormants selon la procédure de changement et de rétablissement de l'organisation.
Rendre la révocation d'urgence exécutable
Définissez à l'avance qui peut déclarer l'incident, quel périmètre cette personne peut arrêter et comment les intervenants vérifient le confinement. Préservez la preuve pendant la réponse. Soldez les effets aval avant de rétablir l'autorité.
| Étape | Action | Preuve |
|---|---|---|
| 1. Cadrer | Identifier tenant, agent, charge de travail, credentials, sessions, outils, demandes et traitements aval | Identifiants d'incident et de corrélation |
| 2. Arrêter | Annuler les exécutions en cours et retenir les travaux en file ou en attente d'approbation | Résultats d'annulation et transitions refusées |
| 3. Révoquer | Désactiver l'identité, révoquer jetons, secrets, capacités, sessions et délégations | Réponses des actionneurs et refus ultérieurs |
| 4. Isoler | Bloquer les chemins réseau, connecteurs ou comptes cibles quand la révocation des credentials reste incomplète | Décisions réseau et systèmes cibles |
| 5. Réconcilier | Retrouver les effets complets et partiels, compenser lorsque cela est autorisé | Accusés, état avant et après, compensation |
| 6. Rétablir | Corriger la cause, émettre une autorité neuve, tester l'état sûr, approuver la reprise | Changement, test, approbateur, heure de reprise |
Capturer la preuve au point de décision
L'enregistrement de preuve doit permettre à un réviseur de reconstituer la chaîne d'identité, l'autorité effective, le contexte évalué, le résultat, la décision humaine, l'effet produit et la révocation ultérieure. Utilisez des identifiants stables pour relier les enregistrements natifs faisant foi. Le schéma public d'événement d'audit des agents IA fournit une enveloppe d'événement portable.
| Frontière | Champs exigés |
|---|---|
| Identité | tenant, principal, agent, charge de travail, sujet délégué, émetteur, audience, événement d'authentification |
| Habilitation | rôles effectifs, attributs, capacités, outil, ressource, donnée, action, montant, finalité, environnement, durée |
| Politique | versions de politique et de règle, champs évalués, résultat, codes de motif, dérogation |
| Approbation | identifiant et empreinte de la demande, approbateur éligible, instantané du rôle, décision, justification, expiration |
| Exécution | clé d'idempotence, appel d'outil, accusé, état avant et après, effet aval |
| Cycle de vie | propriétaire, revue, changement, révocation, refus, accès résiduel, compensation, rétablissement |
Cas pratique : règlement d'un sinistre en assurance
Un assureur affecte un agent sinistres au dossier CL-1842. Une identité d'agent dédiée s'exécute sous une charge de travail de production attestée. La politique autorise le dossier affecté, les champs de sinistre approuvés, la lecture de documents, la rédaction du règlement et des propositions de règlement jusqu'à 100 000 euros pour la finalité claim_settlement, pendant la durée de l'affectation.
Une proposition à 32 000 euros renvoie require_approval, car elle dépasse le seuil d'approbation de 25 000 euros. Un responsable sinistres qualifié, indépendant du demandeur, examine les faits sources, les motifs de politique, le bénéficiaire proposé, le montant et l'effet comptable attendu. L'approbation lie ces valeurs pendant dix minutes. Le système réévalue la politique, exécute une seule fois, puis rattache l'accusé aval à la demande et à la décision.
Un bénéficiaire différent, un champ médical interdit, une affectation expirée, une nouvelle finalité, une preuve modifiée, un montant supérieur à 100 000 euros ou un résultat de politique obligatoire manquant renvoient block. La révocation d'urgence annule les travaux en cours, désactive les credentials de l'agent et de la charge de travail, bloque le connecteur, solde les effets partiels et consigne l'approbation de reprise.
| Étape | Résultat | Preuve |
|---|---|---|
| Identité | Agent, charge de travail, tenant, affectation au dossier et finalité valides | Émetteur, sujets, attestation, affectation, expiration |
| Habilitation | Dossier, champs, outils, action, plafond, environnement et durée concordent | Attributions effectives et attributs |
| Politique | require_approval à 32 000 euros | Version de politique, seuil, motifs, empreinte de la demande |
| Approbation | Un responsable indépendant approuve la demande exacte pour dix minutes | Éligibilité, rôle, justification, expiration |
| Exécution | Politique revérifiée, ordre de virement approuvé émis une seule fois | Accusé, clé d'idempotence, effet comptable |
| Revue | Le réviseur échantillonne demande, décision, exécution et capacité de révocation | Feuille de travail, exception, conclusion |
Traiter l'autorisation MCP comme une frontière d'intégration
Le Model Context Protocol (MCP) définit les échanges d'autorisation pour les transports HTTP et renvoie les implémentations vers les bonnes pratiques de sécurité OAuth. Le contrôle d'accès de l'entreprise conserve la responsabilité de l'identité de l'agent, du rattachement au tenant, des droits dans les systèmes cibles, des listes d'autorisation d'outils, des limites de données et d'actions, de l'approbation, de la preuve et de la révocation en incident.
Consignez l'identité du serveur, les outils annoncés, le serveur d'autorisation, les audiences, les portées, le consentement ou l'approbation, la durée de vie du jeton, les arguments de l'outil, le résultat et l'effet aval. La matrice OWASP Agentic AI Top 10 et règlement européen sur l'IA rattache ces risques d'intégration aux obligations réglementaires.
Rattacher le modèle aux contrats KLA actuels
Le KLA Control Plane gouverne les actions instrumentées en runtime. Ce rattachement reflète le code présent au commit 8fd582a6. Le déploiement et le comportement en production restent non vérifiés. Les fournisseurs d'identité, les émetteurs de credentials, les annuaires, les autorisateurs d'outils et les inventaires d'habilitations des systèmes sources demeurent des autorités externes.
| Fonction | Rattachement KLA actuel | Source | Statut |
|---|---|---|---|
| Authentification et rattachement au tenant | L'Execution API vérifie l'émetteur et l'audience JWT autorisés, puis en dérive le rattachement au tenant. | middleware d'authentification et route d'exécution | Code présent |
| Contexte d'action et quatre résultats | Les demandes de politique portent principal, ressource, action, acteur, environnement, outil, destination, sensibilité des données et contexte métier. Les résultats sont allow, warn, require_approval ou block. | contrats de politique | Code présent, champs propres à chaque producteur |
| Autorisation du plan de contrôle | permissionProcedure authentifie l'appelant et échoue de manière fermée quand la permission nommée est absente. protectedProcedure authentifie seulement ; integrations.list, llmProviders.list et usage.getQuotaStatus l'utilisent sans contrôle de permission explicite. La couverture d'autorisation dépend de chaque procédure. | définitions de procédures, intégrations, fournisseurs et usage | Code présent, vérifier chaque procédure |
| Isolation des données par tenant | Le contexte de tenant borne les requêtes. Les tables API rattachées à un tenant utilisent la sécurité au niveau ligne forcée prévue par le contrat de migration ; la couverture reste propre à chaque table et à chaque service. | middleware de tenant et migration RLS | Code présent, vérifier chaque service et chaque table |
| Point de contrôle fermé par défaut | Le transition gate bloque un contexte de tâche manquant, des contrats de pack non résolus, une validation de sortie en échec, une erreur d'évaluation et un résultat block avant toute progression. | transition gate | Code présent |
| Approbation humaine | Le Decision Desk vérifie la permission de décision, le rôle requis, l'état en attente, l'identité de l'initiateur et l'échéance des Decision Requests. | routeur d'approbations | Code présent, champs dépendants du producteur |
| Annulation en cours d'exécution | Une route bornée au tenant signale les workflows actifs ou retenus. La révocation côté fournisseur d'identité et côté jetons aval reste assurée par des actionneurs externes. | annulation d'exécution | Code présent, propagation de révocation partielle |
| Audit et preuve | Les enregistrements du worker portent identité, politique, approbation, exécution, empreintes et corrélation de trace. L'Evidence Room regroupe les enregistrements retenus sous un manifeste et des preuves d'intégrité. | événements d'audit et contrat de preuve | Code présent sur les enregistrements faisant foi |
Garder explicite le périmètre de KLA
KLA évalue et consigne les chemins d'action gouvernés qui sont intégrés au KLA Control Plane. La visibilité universelle sur chaque identité, credential, compte de service, connecteur et permission de système cible sort de ce périmètre.
- Cycle de vie des identités. Les fournisseurs d'identité, les annuaires RH, les autorités d'attestation de charge de travail et les inventaires de comptes de service portent la création, le statut et le recensement des identités.
- Cycle de vie des credentials. Les émetteurs, coffres-forts, connecteurs et systèmes cibles portent l'émission, la rotation, l'intermédiation et la révocation des credentials en aval.
- Normalisation des habilitations. Les contrats KLA acceptent un contexte d'action et un contexte métier souples. Les producteurs restent responsables des faits normalisés de finalité, de montant, de donnée, de relation et de durée.
- Modèle d'autorisation. RBAC, ABAC et capacités sont des choix d'architecture. Le contrat de politique KLA reste indépendant du modèle.
- Certification. KLA consigne les contrôles et les preuves. L'organisation définit les critères de revue, la population complète, les échantillons, la conclusion et tout périmètre de certification.
- Propagation de la révocation. L'annulation en cours d'exécution existe. La désactivation d'identité de bout en bout, la révocation des jetons, l'isolation réseau, l'annulation en aval, la compensation et le rétablissement exigent des actions externes coordonnées.
Sources primaires et fraîcheur des références
Ce guide a été vérifié le 28 juillet 2026. Les normes, spécifications, projets de lignes directrices et transpositions locales évoluent. Revérifiez la source primaire et le comportement déployé avant toute décision d'audit, d'achat, juridique ou de sécurité. Les sources ci-dessous sont publiées en anglais.
- NIST SP 800-53 Rev. 5, AC-6 Least Privilege
- NIST SP 800-162, Guide to Attribute Based Access Control
- NIST Role Based Access Control, projet et norme de référence
- NIST NCCoE, note de cadrage sur l'identité et l'autorisation des agents logiciels et IA (projet, publié le 5 février 2026)
- RFC 8693, OAuth 2.0 Token Exchange
- RFC 8707, Resource Indicators for OAuth 2.0
- RFC 9396, OAuth 2.0 Rich Authorization Requests
- Spécification d'autorisation du Model Context Protocol, 25 novembre 2025 (dernière version publiée disponible lors de cette vérification)
- Model Context Protocol, version candidate 2026-07-28 (gelée le 21 mai 2026 ; la publication définitive était prévue le 28 juillet et n'était pas encore disponible lors de cette vérification)
- Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l'intelligence artificielle
- Règlement (UE) 2016/679 (RGPD), article 22
Foire aux questions
Qu'est-ce que le contrôle d'accès d'un agent IA ?
Le contrôle d'accès d'un agent IA identifie l'agent et sa charge de travail, résout les habilitations du moment, évalue l'action proposée et son contexte, route les demandes à fort enjeu vers un humain habilité, puis consigne la décision et son effet.
Comment appliquer le moindre privilège à un agent IA ?
N'accordez que l'outil, la donnée, l'action, le montant, la finalité, l'environnement et la durée nécessaires à la tâche approuvée. Réévaluez ces frontières avant chaque action à fort enjeu.
Faut-il choisir RBAC ou ABAC pour un agent IA ?
Utilisez RBAC pour des devoirs de base lisibles et ABAC pour le contexte propre à chaque demande. Une capacité ou un jeton de courte durée peut lier la ressource, l'action, l'audience et l'expiration au moment de l'appel final.
Quand un agent IA doit-il exiger une approbation humaine ?
Exigez une approbation pour les décisions affectant des droits, les effets irréversibles, les dérogations, les montants élevés, les communications sensibles, les élargissements d'accès et les incertitudes inhabituelles. Liez la décision à la demande exacte et à une expiration.
Une approbation humaine suffit-elle au titre de l'article 22 du RGPD ?
Non, si elle se limite à valider la proposition de l'agent. L'article 22 suppose une intervention humaine effective : l'approbateur doit disposer des faits sources, de l'autorité de refuser et de la capacité de modifier la décision, et la personne concernée doit pouvoir exprimer son point de vue et contester.
À quelle fréquence revoir les habilitations des agents IA ?
Fixez une cadence proportionnée au risque et déclenchez une revue dès que le propriétaire, la finalité, le risque, les outils, les données, la politique, l'environnement ou le système cible changent. Les accès permanents à fort impact demandent des intervalles plus courts.
Comment recenser les comptes de service des agents IA ?
Réconciliez le registre des agents avec l'IAM cloud, les applications du fournisseur d'identité, les plateformes de charge de travail, l'intégration continue, les coffres-forts, les secrets, les passerelles d'API, les serveurs MCP, les connecteurs, les journaux des systèmes cibles et les traces de sortie réseau.
Que doit arrêter une révocation d'urgence ?
Arrêter les travaux en cours et en file, révoquer identités, jetons, secrets, sessions, délégations et capacités, isoler les chemins restants, solder les effets produits, corriger la cause, puis approuver le rétablissement.
Quelle preuve démontre que le contrôle d'accès a fonctionné ?
Reliez sous des identifiants stables l'identité et l'authentification, les habilitations effectives, les entrées et le résultat de politique, la décision humaine, l'accusé d'exécution, les changements de cycle de vie, la révocation, les contrôles d'accès résiduel et le rétablissement.
Points clés à retenir
Un contrôle d'accès efficace pour les agents IA repose sur une population d'identités complète, des habilitations étroites et révisables, quatre résultats explicites en runtime, une approbation humaine habilitée, une révocation d'urgence testée et une preuve reliée de bout en bout. Utilisez la trame de revue des habilitations, auditez les droits avec le guide des permissions, consolidez la couche de preuve avec les pistes d'audit et implémentez les champs portables du schéma d'événement d'audit des agents IA.