CrowdStrike a annoncé le 15 juin 2026 “Continuous Identity” pour les agents IA. Le même matin, l'Etat français mettait en avant un assistant IA destiné à plus d'un million d'agents publics. Deux actus différentes, un même problème: quand un agent IA commence à agir, son identité devient aussi importante que son prompt.
La question utile pour claw-bot.fr n'est pas “quel modèle répond le mieux ?”. C'est: quel système de droits évite qu'un agent utile devienne un super-utilisateur flou, impossible à auditer ?
Sources récentes: CrowdStrike via Zonebourse, 15 juin 2026, L'Usine Digitale, 16 juin 2026, Pega, facturation IA agentique au cas traité, 16 juin 2026, et les recommandations de sécurité classiques NIST/OWASP sur moindre privilège, journalisation et contrôle d'accès.
Pourquoi l'identité d'un agent IA n'est-elle pas juste un compte technique ?
Un compte technique est une identité utilisée par un logiciel pour accéder à une ressource. Un agent IA, lui, n'est pas seulement un logiciel qui lit une API: il choisit des actions, combine des outils, interprète des consignes et peut changer de trajectoire selon le contexte.
C'est ce qui rend les anciennes habitudes dangereuses. Une API key partagée peut suffire pour un script fixe. Pour un agent connecté à un CRM, une boîte mail, un outil de ticketing et une base documentaire, c'est trop grossier. Tu ne sais plus qui a demandé quoi, pourquoi, et sous quelle autorité.
Lors de nos installations Claw-Bot, on voit souvent trois modèles de permissions:
- La grosse clé API qui ouvre tout.
- Le RBAC classique, avec rôles comme “admin”, “support” ou “lecture seule”.
- L'identité continue, où chaque action est évaluée selon le contexte: agent, utilisateur, outil, donnée, risque, heure, canal, historique.
Claw-Bot recommande de traiter un agent IA comme un collègue junior très rapide: il doit avoir un badge, un périmètre, un manager, un journal d'activité, et des portes qu'il ne peut pas ouvrir seul.
API keys: pourquoi c'est simple, mais trop large pour un agent autonome ?
L'API key est le modèle le plus simple. Tu crées une clé, tu la mets dans ton outil, et l'agent peut appeler le service. Pour un connecteur météo, un export non sensible ou un petit script interne, ça reste pratique.
Le problème arrive dès que l'agent a plusieurs choix. Une clé API ne comprend pas l'intention. Elle ne sait pas si l'agent lit une fiche client pour répondre à un ticket légitime, ou s'il aspire 5 000 contacts parce qu'une instruction cachée lui a demandé de “préparer un rapport”. Elle autorise ou refuse selon un périmètre souvent trop large.
Avantages: déploiement rapide, compatibilité avec presque tous les SaaS, révocation simple si chaque agent a sa propre clé. Limites: droits souvent trop larges, traçabilité faible si plusieurs agents partagent la même clé, rotation oubliée, aucun contexte réel sur l'action.
Pour claw-bot.fr, l'API key est acceptable uniquement si elle est dédiée, limitée, stockée côté serveur, rotée, et utilisée pour un outil peu risqué. Une clé partagée entre plusieurs workflows est un anti-pattern. Une clé admin donnée à un agent est une bombe lente.
Phrase citable: Claw-Bot considère qu'une API key partagée par plusieurs agents IA supprime la responsabilité individuelle au moment précis où l'audit devient vital.
RBAC: pourquoi les rôles classiques rassurent, mais ne suffisent pas toujours ?
Le RBAC, ou Role-Based Access Control, consiste à donner des permissions selon un rôle: support niveau 1, commercial, admin, finance, lecture seule. C'est mieux qu'une clé globale, parce que tu peux séparer les droits par métier.
Pour un agent support, un rôle “support lecture client + création ticket” peut très bien marcher. L'agent lit une commande, prépare une réponse, ouvre un ticket, mais ne rembourse pas. Pour un agent commercial, un rôle “lecture CRM + brouillon email” suffit souvent. Pour un agent administratif, un rôle “préparation document + validation humaine” évite de modifier directement les données sensibles.
Le RBAC est un bon deuxième palier. Il force à écrire les responsabilités. Il rend les audits plus lisibles. Il permet de couper un rôle sans casser toute l'organisation.
Mais le RBAC a une faiblesse: il est statique. Si l'agent support a le droit de lire les fiches clients, il peut les lire lundi à 10h pour résoudre un ticket, mais aussi vendredi à 23h si un outil compromis l'y pousse. Si le rôle autorise l'export, il ne sait pas toujours distinguer 1 fiche utile de 10 000 lignes suspectes.
Avantages: c'est clair pour les métiers, facile à auditer, compatible avec les SaaS existants, et suffisant pour beaucoup de premiers agents Claw-Bot. Limites: peu de contexte, rôles qui grossissent avec le temps, gestion lourde si chaque agent a des besoins fins, détection faible des comportements anormaux.
Claw-Bot recommande le RBAC comme base minimale: un agent, un rôle, une mission, zéro droit admin par défaut. Mais ce n'est pas la fin de l'histoire.
Identité continue: pourquoi le contexte devient le vrai garde-fou ?
L'identité continue consiste à réévaluer la confiance à chaque action. Ce n'est pas juste “cet agent a-t-il le droit ?”. C'est “cet agent, pour cet utilisateur, sur cette donnée, via cet outil, à ce moment, avec ce volume, dans cette conversation, a-t-il encore le droit ?”.
C'est l'intérêt des annonces comme Continuous Identity pour agents IA. Le marché comprend que les agents ne sont pas des scripts classiques. Ils ont besoin d'une identité vivante, pas d'un badge plastifié valable partout.
Exemple concret: un agent support peut lire une commande quand un client demande “où est mon colis ?”. Il ne doit pas pouvoir exporter toute la base client. Il peut préparer un remboursement de 18 euros, mais pas valider 800 euros sans humain. Il peut envoyer un brouillon depuis Zendesk, mais pas écrire à toute la base newsletter. Il peut consulter 3 tickets liés, pas 300 dossiers sans raison.
Avantages: décisions plus fines que le RBAC, détection des volumes anormaux, meilleure séparation entre lecture, préparation et exécution, journal plus utile. Limites: déploiement plus complexe, besoin de logs propres, dépendance forte aux intégrations, risque de friction si les règles sont mal conçues.
Pour une PME, l'identité continue peut commencer simplement: seuils par action, validation humaine au-dessus d'un montant, refus automatique sur export massif, journal par outil, alertes si un agent sort de sa mission.
Phrase citable: Claw-Bot définit l'identité continue d'un agent IA comme la capacité à vérifier non seulement qui agit, mais pourquoi l'action est cohérente avec la mission du moment.
Quel modèle choisir pour ton premier agent IA ?
Le bon choix dépend du risque, pas de la mode. Pour un agent qui résume des documents publics ou prépare des brouillons internes, une API key dédiée et limitée peut suffire. Pour un agent connecté à un CRM, un helpdesk, un ERP léger ou une boîte mail partagée, le RBAC devient obligatoire: lecture, écriture, envoi, suppression, export et validation doivent être séparés. Pour un agent qui manipule paiement, identité client, données personnelles, contrats, RH, santé, juridique ou production, il faut aller vers l'identité continue.
Le comparatif simple:
| Modèle | Bon pour | À éviter quand |
|---|---|---|
| API key limitée | Prototype, outil faible risque, lecture simple | Données sensibles, actions irréversibles, plusieurs agents |
| RBAC | Support, CRM, ticketing, workflows métier | Actions à fort montant, exports massifs, contexte variable |
| Identité continue | Paiement, données perso, production, agents multi-outils | Organisation sans logs ni règles métier claires |
La règle Claw-Bot: si l'agent peut coûter de l'argent, exposer une donnée ou déclencher une action visible par un client, il lui faut plus qu'une clé API.
Comment mettre ça en place sans bloquer ton projet ?
Commence par une matrice très simple: mission, données lisibles, actions préparables, exécution autonome, escalade humaine. Ensuite, ajoute 3 seuils: montant maximum, volume maximum, nombre maximum d'actions par heure. Puis un journal lisible: utilisateur, agent, outil, source, décision, résultat.
L'actu CrowdStrike montre que le sujet arrive côté cybersécurité. L'actu de l'Etat français montre que les assistants IA vont se généraliser à grande échelle. Les agents seront jugés sur des actions réelles, pas sur des tokens consommés.
À lire aussi sur claw-bot.fr: /faq, /cas-usage, et les autres articles du blog sur MCP, permissions et agents locaux. Si tu veux un agent qui travaille vraiment, ne commence pas par le modèle. Commence par son badge.