Un agent IA ne se contente pas de répondre. Il peut consulter un CRM, lire des documents, préparer un email, modifier une fiche client ou déclencher une action. La connexion ne précise pourtant pas pourquoi cet accès existe, qui l’assume, ce qui est permis ou comment tout arrêter.
Pour IZZY, une autorisation d’agent IA est une décision d’exploitation qui relie une identité et une source d’autorité à une ressource, une action, une catégorie de données, une durée, une règle de validation, une trace et une procédure de révocation. Il s’agit d’une définition de travail IZZY, pas d’une norme externe.
La gestion des accès des agents IA doit donc suivre un cycle de vie, pas une simple liste d’applications connectées.
La réponse en 60 secondes
- Recensez les agents, assistants connectés et automatisations utilisant l’IA.
- Attribuez à chacun un responsable métier et un responsable technique.
- Notez l’identité utilisée : compte salarié, identité technique, accès temporaire ou identifiant partagé.
- Limitez l’accès par ressource, action et durée.
- Faites valider séparément les actions externes, financières, destructrices ou difficiles à annuler.
- Journalisez tentatives, décisions et résultats sans enregistrer de secrets.
- Définissez les événements qui imposent une revue, une date d’expiration et une procédure d’arrêt testée.
Conservez ces décisions dans un registre des accès des agents IA : un outil d’exploitation IZZY, pas un registre légal, un certificat ou un audit de sécurité.
Dans cet article
- Que couvre réellement une autorisation d’agent IA ?
- Comment la dette d’autorisations apparaît-elle dans une PME ?
- Que faut-il inscrire dans le registre des accès ?
- Quelle identité utiliser et comment limiter les droits ?
- Comment organiser validations, journaux et délégations ?
- Quand revoir ou supprimer les accès ?
1. Que couvre réellement une autorisation d’agent IA ?
Traitez chaque autorisation comme neuf décisions liées :
identité + source d’autorité + ressource + action + catégorie de données + durée + validation + journalisation + révocation
| Élément | Question à trancher |
|---|---|
| Identité | Quel compte, application ou identité technique présente la demande ? |
| Autorité | Au nom de quelle personne ou mission l’agent agit-il ? |
| Ressource | Quel espace, dossier, projet, table ou groupe de fiches peut-il atteindre ? |
| Action | Peut-il lire, créer, modifier, envoyer, supprimer ou administrer ? |
| Données | Traite-t-il des informations personnelles, financières ou confidentielles ? |
| Durée | L’accès vaut-il pour une demande, une tâche, un pilote ou sans échéance ? |
| Validation | Quelle action exacte exige une décision indépendante ? |
| Preuve | Que faut-il enregistrer pour comprendre la tentative et son résultat ? |
| Révocation | Quel compte, jeton, rôle, service ou travail planifié doit être arrêté ? |
« Accès au CRM » est trop vague. Lire les opportunités attribuées n’équivaut pas à exporter ou supprimer tous les contacts.
Le NIST étudie l’identité, l’autorisation et l’audit des agents. Son document de février 2026 est un projet conceptuel initial, pas une norme finale.
En France, la note exploratoire publiée le 20 juillet 2026 par la CNIL et le Conseil de l’IA et du Numérique souligne les services connectés, la mémoire persistante, l’action au nom de l’utilisateur et la complexité des responsabilités. Elle n’instaure pas une nouvelle règle, mais confirme le besoin d’un périmètre gouvernable.
2. Comment la dette d’autorisations apparaît-elle dans une PME ?
La dette d’autorisations est l’écart entre les accès existants et ceux que l’entreprise sait encore expliquer, contrôler et retirer. C’est un modèle IZZY, pas une statistique de marché.
| Situation observée | Problème réel | Décision à reprendre |
|---|---|---|
| Aucun propriétaire métier | L’informatique maintient la connexion, mais personne ne confirme son utilité. | Nommer qui peut la renouveler, modifier ou arrêter. |
| Identité ambiguë | L’agent utilise la session d’un salarié ou un compte partagé. | Séparer l’identité ou rendre la chaîne d’autorité traçable. |
| Droits accumulés | De nouveaux outils sont ajoutés sans retirer les anciens. | Comparer les droits à la mission actuelle. |
| Pas de fin prévue | Le test continue sans date, revue ni décision de passage en production. | Définir expiration et événements de réexamen. |
| Délégation invisible | Un outil en appelle un autre sans conserver l’origine. | Rendre le parcours vérifiable ou le revoir. |
Exemple : un prototype commercial commence avec quelques fiches CRM, puis reçoit calendrier, documents clients et envoi d’emails. Il dépasse alors sa mission d’origine.
N’attendez pas l’étiquette « production ». Réexaminez l’accès dès que l’agent atteint des données personnelles, un système métier, une communication externe, un paiement ou les droits d’autrui.
3. Que faut-il inscrire dans le registre des accès ?
Commencez sans plateforme spécialisée : le registre peut vivre dans votre catalogue de services, votre documentation ou un tableau maintenu.
Une ligne par agent ou déploiement doit indiquer :
- nom, environnement, mission et propriétaires ;
- identité, source d’autorité et identifiant utilisé ;
- logiciels, ressources, actions et données accessibles ;
- validation, durée, expiration et déclencheur de revue ;
- traces, parcours de délégation, arrêt, révocation et solution manuelle.
Écrivez une mission vérifiable. « Aider le service client » est vague ; « classer la file France et préparer une réponse, sans l’envoyer ni modifier le compte » fixe une limite testable.
Le responsable métier confirme la finalité et les conséquences acceptables ; le responsable technique sait comment arrêter la connexion. Une personne peut porter les deux rôles, mais les décisions restent distinctes.
Microsoft propose également un inventaire indiquant propriétaire, objectif et étendue d’accès. C’est un exemple de produit, pas un modèle obligatoire ; un registre manuel peut suffire à petite échelle.
4. Quelle identité utiliser et comment limiter les droits ?
Déterminez d’abord l’autorité utilisée :
- déléguée : l’agent agit dans le contexte d’une personne identifiée ;
- technique : le flux possède un compte distinct, révocable séparément ;
- temporaire : l’accès existe pour une tâche ou une courte fenêtre ;
- partagée : plusieurs flux utilisent le même identifiant, limitant l’attribution.
Pouvez-vous désactiver l’agent sans bloquer un salarié ou une autre intégration ? Sinon, la séparation est insuffisante.
Organisez ensuite le contrôle des accès selon le principe du moindre privilège, sur trois axes :
- Ressource : seulement le dossier, la boîte, le projet ou les fiches nécessaires.
- Action : séparer consultation, préparation, envoi, modification, suppression et administration.
- Durée : limiter l’accès à la tâche ou fixer une échéance et une revue.
La CNIL recommande de limiter les habilitations aux besoins de la mission, de les faire valider, revoir et supprimer lorsqu’elles deviennent inutiles. Cette fiche vise d’abord les utilisateurs de systèmes traitant des données personnelles ; ses principes éclairent néanmoins l’accès d’un agent.
RFC 9700 recommande de restreindre les jetons OAuth au serveur, aux ressources et aux actions prévus, puis de vérifier chaque requête. Le guide MCP recommande des jetons courts et la validation du serveur destinataire. Ces mécanismes ne remplacent ni la mission, ni le propriétaire, ni la sortie.
5. Comment organiser validations, journaux et délégations ?
Installer une application et approuver une action sont deux décisions différentes. Placez la friction là où la conséquence change.
| Action | Traitement par défaut |
|---|---|
| Lecture limitée | Autoriser et journaliser. |
| Brouillon | Une personne décide avant engagement. |
| Modification réversible | Limiter et tester l’annulation. |
| Communication externe | Afficher destinataire et contenu avant envoi. |
| Paiement, suppression, droits ou production | Exiger une validation indépendante. |
La validation doit désigner agent, outil, cible, paramètres et durée. « Gérer les emails » n’équivaut pas à « envoyer ce message à ces trois destinataires maintenant ».
L’OWASP recommande des permissions limitées par outil, une autorisation explicite des opérations sensibles et la séparation décision-exécution pour l’irréversible. L’ANSSI recommande de maîtriser les interactions avec les applications métier, de limiter les actions automatiques issues d’entrées non maîtrisées et de journaliser les traitements.
Pour une action sensible, le journal doit montrer :
- la tentative : outil, cible, action et paramètres utiles ;
- la décision : identité, autorité, règle et validation ;
- le résultat : réussite, refus, erreur, annulation ou arrêt.
N’enregistrez ni jeton, ni mot de passe, ni données inutiles. La CNIL rappelle que la journalisation aide à détecter les accès non autorisés, tout en devant rester proportionnée, protégée et limitée.
Si un agent délègue, le second ne doit pas hériter automatiquement de tous ses droits. Conservez la chaîne entre demandeur, agent initial, intermédiaire, outil cible et résultat.
6. Quand revoir ou supprimer les accès ?
Commencez par une équipe, un processus ou les agents reliés au même CRM.
- Inventoriez agents, tests oubliés, clés, comptes partagés, connecteurs et tâches planifiées.
- Classez chaque accès par propriétaire, mission, identité, données, actions et conséquence maximale.
- Réduisez outils inutiles, droits génériques et autorisations permanentes évitables.
- Déclenchez une revue si mission, propriétaire, fournisseur, modèle, mémoire, données, outil ou action change.
- Testez l’arrêt : désactivez le droit et vérifiez sessions, jetons, délégations et travaux programmés.
- Organisez la suite : nommez qui renouvelle, traite les exceptions et suspend le flux.
Le NCSC recommande l’accès minimal pendant la durée la plus courte nécessaire, des identifiants temporaires, une surveillance et un plan d’incident. La cadence dépend néanmoins du contexte.
Avec des données personnelles, demandez : la fiche complète est-elle nécessaire ? l’historique ou la mémoire subsistent-ils ? un fournisseur ou sous-agent reçoit-il les données ? quand copies, traces et identifiants disparaissent-ils ?
La CNIL recommande de limiter les données partagées par API au nécessaire, de clarifier les rôles et de revoir les habilitations. Base juridique, responsabilités RGPD, information, transferts ou analyse d’impact exigent une étude propre au cas.
Conclusion : un accès doit rester explicable jusqu’à sa suppression
Une connexion indique seulement qu’un outil peut atteindre un autre système. Une autorisation exploitable précise pourquoi cet accès existe, qui l’assume, ce qu’il permet et comment il prend fin.
Commencez par un registre simple. Séparez les identités lorsque cela améliore l’attribution et la révocation. Limitez chaque droit par ressource, action et durée. Validez les conséquences sensibles, conservez les traces utiles et testez réellement l’arrêt.
Cette discipline transforme une expérimentation utile en processus maîtrisé, sans comptes partagés ni droits oubliés.
Cartographiez un premier périmètre d’accès IA
Apportez une liste limitée d’agents, d’automatisations et d’outils IA, les systèmes qu’ils atteignent et les propriétaires connus. En 30 minutes, IZZY peut cadrer un premier registre des accès, identifier les décisions non résolues et comparer les options d’organisation, de produit, de cloud et d’identité.
Questions fréquentes
Un assistant produit généralement une réponse. Un agent peut aussi appeler des outils pour consulter, modifier, envoyer ou déclencher une opération.
Non. Il faut encore une finalité, un responsable, un périmètre, une durée, des validations, des traces et une révocation.
Il n’existe pas de règle universelle. Une identité distincte facilite attribution et révocation ; une autorité déléguée conserve le contexte utilisateur. Évitez les comptes impossibles à arrêter séparément.
Prévoyez une cadence adaptée au risque et une revue lors de tout changement de mission, propriétaire, données, fournisseur, modèle, mémoire, outil ou conséquence.
Non. Le registre est un outil d’exploitation. Un audit formel possède un périmètre, une méthode, des preuves et des responsables qualifiés distincts.
Révoquez comptes, jetons, rôles et consentements ; terminez les travaux ; vérifiez services délégués et données conservées ; documentez le nouveau périmètre ou l’arrêt.
Sources et méthode
- CNIL et CIANum : IA agentique et données personnelles
- CNIL : gérer les habilitations
- CNIL : sécuriser les API
- CNIL : recommandation relative à la journalisation
- ANSSI : recommandations de sécurité pour un système d’IA générative
- NIST NCCoE : projet conceptuel sur l’identité et l’autorisation des agents
- OWASP : AI Agent Security Cheat Sheet
- IETF : RFC 9700, bonnes pratiques de sécurité OAuth 2.0
- Model Context Protocol : comprendre l’autorisation
- NCSC : adopter l’IA agentique avec prudence
- Microsoft Learn : gérer et sécuriser les agents IA
Article préparé à partir de sources primaires, officielles et de documentation technique vérifiées le 20 juillet 2026. Le registre, la définition de l’autorisation, le modèle de dette et le parcours de revue sont des cadres opérationnels IZZY, pas des normes externes. Ce contenu général ne constitue ni un audit de sécurité, ni un test d’intrusion, ni un avis juridique, ni une décision de conformité.