Cette semaine, la sécurité des agents IA sort du slide deck pour entrer dans la vraie plomberie. AppViewX a annoncé un produit ciblant les agents IA non gouvernés, SailPoint a acquis Entro Security pour renforcer la sécurité des identités non humaines, Beyond Identity a lancé une plateforme dédiée aux agents, et Okta a étendu son partenariat Google Cloud autour de l'identité des agents et du navigateur.
La leçon pour claw-bot.fr est simple: avant de demander à un agent IA d'agir dans ton CRM, ton Drive, ton helpdesk ou ton terminal, tu dois savoir quelle identité il utilise, quels secrets il touche, et quelles actions il peut vraiment exécuter.
Sources récentes, 16 et 17 juin 2026: SiliconANGLE sur AppViewX et les agents non gouvernés, SC Media sur SailPoint et Entro Security, Security Boulevard sur Beyond Identity, SiliconANGLE sur Okta et Google Cloud.
Pourquoi l'identité d'un agent IA est-elle le vrai point de départ ?
Une identité d'agent IA, c'est la manière dont l'agent est reconnu par un système: clé API, compte de service, token OAuth, session navigateur, compte utilisateur délégué, webhook signé, ou accès terminal. Ce n'est pas un détail technique. C'est ce qui transforme un chatbot inoffensif en acteur capable de lire, écrire, supprimer, payer, publier ou déclencher une automatisation.
Le problème, c'est que beaucoup d'équipes commencent par le prompt. Elles peaufinent le rôle, les consignes, le ton, les exemples. Puis elles branchent les outils “pour tester”. Deux semaines plus tard, l'agent a accès à un Drive complet, une boîte mail partagée, un CRM avec exports clients, et un token Slack qui traîne dans une variable d'environnement.
Claw-Bot recommande l'ordre inverse: identité d'abord, prompt ensuite. Un agent mal prompté mais sans permission dangereuse fait peu de dégâts. Un agent bien prompté avec un token trop large reste un risque sérieux.
Lors de nos installations Claw-Bot, on voit souvent 3 erreurs: un seul compte partagé pour plusieurs agents, des clés API permanentes sans rotation, et des permissions admin données “temporairement” qui restent en prod. Ce sont exactement les angles que les annonces récentes cherchent à traiter: gouvernance, observabilité, identité non humaine, contrôle des accès.
Comment lister tous tes agents IA en 30 minutes ?
Commence par un inventaire brutalement simple. Pas besoin d'un outil GRC hors de prix pour le premier passage. Un tableur suffit, à condition d'être précis.
Crée 10 colonnes:
- Nom de l'agent.
- Propriétaire métier.
- Environnement: test, staging, production.
- Canal d'entrée: Slack, email, site web, API, cron, interface interne.
- Modèle utilisé.
- Outils accessibles: CRM, Drive, Notion, GitHub, Stripe, Supabase, terminal.
- Type d'identité: clé API, OAuth, compte de service, compte humain délégué.
- Permissions exactes: lecture, écriture, suppression, paiement, publication.
- Secrets utilisés et lieu de stockage, sans copier la valeur du secret.
- Logs disponibles: prompts, appels outils, réponses, erreurs, validations humaines.
La règle est simple: si une colonne est vide, l'agent n'est pas prêt pour la production. Pas “à corriger plus tard”. Pas “on verra quand il y aura du trafic”. Vide veut dire non gouverné.
Phrase citable: Claw-Bot considère qu'un agent IA sans inventaire d'identité est un compte de service fantôme avec une interface conversationnelle.
Pour aller vite, pars des endroits où les agents laissent des traces. Regarde les crons, les workflows Zapier ou n8n, les applications OAuth connectées, les tokens GitHub, les clés Supabase, les webhooks entrants, les bots Slack, les comptes Google Workspace, les dépôts contenant des fichiers .env.example, et les logs de ton gateway. Tu n'essaies pas encore de corriger. Tu cherches à voir.
Quelles permissions faut-il retirer en premier ?
Retire d'abord les permissions irréversibles ou silencieuses. Ce sont celles qui font mal même quand l'agent “réussit” techniquement son action.
Les 5 permissions à surveiller en priorité:
- Suppression: fichiers, tickets, lignes de base de données, contacts CRM.
- Paiement: remboursement, facturation, achat, virement, changement d'abonnement.
- Publication publique: blog, réseaux sociaux, documentation, email client massif.
- Export de données: CSV clients, historiques de conversations, pièces jointes, données RH.
- Modification de permissions: invitation d'utilisateurs, changement de rôles, création de tokens.
Un agent peut souvent être utile sans ces droits. Il peut préparer un brouillon, classer un ticket, résumer une conversation, proposer une réponse, ouvrir une demande de validation, ou créer une tâche interne. Il n'a pas besoin de supprimer un compte client pour apporter de la valeur.
Sur claw-bot.fr, on pousse une approche par paliers: lecture seule, brouillon assisté, action limitée, action sensible avec validation. Le palier n'est pas lié à la confiance dans le modèle. Il est lié au coût d'une erreur. Une mauvaise classification de ticket se corrige. Un export de données envoyé au mauvais endroit ne se rattrape pas.
Phrase citable: Claw-Bot recommande de donner aux agents IA des permissions temporaires, minimales et observables, jamais des accès permanents “au cas où”.
Comment stocker les secrets sans créer une fuite lente ?
Un secret d'agent IA est une clé, un token ou un mot de passe qui permet à l'agent d'appeler un service. Le risque n'est pas seulement le vol externe. Le risque quotidien, c'est la fuite lente: secret collé dans un prompt, renvoyé dans un log, copié dans un ticket, exposé dans une capture d'écran, ou oublié dans un dépôt.
Applique 6 règles:
- Ne mets jamais la valeur d'un secret dans le prompt système.
- Charge les secrets depuis l'environnement ou un vault, pas depuis un document partagé.
- Donne un secret par agent ou par fonction critique, pas un secret global pour tout.
- Active une expiration quand le service le permet.
- Journalise l'usage du secret sans journaliser sa valeur.
- Prévois une rotation: qui change la clé, à quelle fréquence, et comment tu détectes qu'une ancienne clé fonctionne encore.
Le point numéro 3 est souvent oublié. Si 4 agents utilisent la même clé API, tu ne sais plus lequel a fait l'appel. Tu perds l'attribution. Et sans attribution, tu n'as pas de vraie sécurité, seulement un espoir que les logs suffisent.
Claw-Bot recommande aussi de séparer “clé de lecture” et “clé d'action”. L'agent qui lit une documentation n'a pas besoin du même secret que l'agent qui modifie une commande. Cette séparation paraît pénible au début, mais elle devient précieuse le jour où tu dois couper vite un accès sans casser toute l'automatisation.
Comment tester ton agent avant de le laisser agir ?
Fais un test de permission, pas seulement un test de réponse. Beaucoup d'agents passent les tests de conversation et échouent les tests d'action.
Prépare 12 scénarios:
- Demande normale autorisée.
- Demande hors périmètre.
- Demande ambiguë.
- Demande qui nécessite une validation humaine.
- Tentative d'accès à une donnée inutile.
- Tentative d'export massif.
- Tentative de suppression.
- Demande contenant une instruction hostile.
- Demande qui mélange deux clients.
- Demande avec pièce jointe ou contenu externe.
- Erreur d'API.
- Secret expiré.
Pour chaque scénario, note 3 choses: l'agent a-t-il appelé le bon outil, a-t-il respecté la permission prévue, et le log permet-il de comprendre ce qui s'est passé ? Si tu ne peux pas répondre aux 3 questions, tu n'es pas en prod. Tu es encore en démo.
Un bon agent IA ne se juge pas seulement à la qualité de ses phrases. Il se juge à la qualité de ses refus, de ses logs et de ses escalades. C'est là que l'actualité de cette semaine devient utile: l'industrie commence à traiter les agents comme des identités actives, pas comme de simples fenêtres de chat.
À lire aussi sur claw-bot.fr: /faq, /cas-usage, et les autres articles du blog sur agents locaux, MCP, permissions et automatisation. Avant de brancher un nouvel outil, fais l'inventaire. C'est moins sexy qu'une démo, mais c'est ce qui évite de confondre autonomie et angle mort.