Identités invisibles, accès trop larges, journaux à trous. Voilà le terrain meuble sur lequel les agents IA posent leurs valises dans l’entreprise. D’après BleepingComputer, qui relaie une analyse de Token Security, ces systèmes lisent des données, déclenchent des workflows et agissent dans plusieurs applications métier avec des privilèges dignes d’un humain. Parfois davantage.
Le souci n’est pas que technique. Quand un agent pilote des comptes de service, des clés API ou des rôles cloud pour accomplir sa tâche, il devient une identité non humaine à part entière. Et c’est exactement la couche que les attaquants adorent viser : vol de jetons, identifiants recyclés n’importe comment, agents abandonnés sans propriétaire, permissions trop larges qui ne expirent jamais.
Points clés
- Les agents IA agissent avec des privilèges proches (ou supérieurs) à ceux d’un humain, créant des identités non humaines à gouverner
- Comptes partagés, agents orphelins et permissions trop larges exposent les données à des vols de jetons et escalades de privilèges
- Token Security prône une approche identity-first : identité unique, propriétaire humain, droits minimaux et journalisation exploitable
- Microsoft et la Cloud Security Alliance publient leurs propres cadres (identité des agents, Agent Access Management)
Un agent IA n’est pas une macro Excel
Le constat de Token Security tient en une phrase : trop d’organisations déploient un agent IA comme une vulgaire automatisation, compte technique partagé et droits étendus pour ne pas brider les usages. Sauf qu’un agent ne se comporte pas comme un script figé. Il enchaîne les actions, appelle plusieurs outils, interroge des bases et tranche en temps réel selon le contexte.
Dans un billet du 5 juin, l’éditeur décrit ces agents comme une identité hybride, à mi-chemin entre souplesse humaine et automatisation machine. Si un agent GPT accède à Salesforce via un jeton API personnel, la frontière entre identité humaine et identité de service se brouille. Résultat : responsabilité diluée, révocation casse-tête, audit hasardeux.
Microsoft a publié mi-juin ses recommandations sur l’identité des agents IA, en rappelant les questions de base qu’un bon modèle doit savoir résoudre : quel agent a lancé l’action, quels outils ont été appelés, quelles ressources ont changé, et peut-on rejouer l’événement lors d’un contrôle ? La Cloud Security Alliance, elle, a forgé la notion d’Agent Access Management pour encadrer l’accès des identités non humaines aux données d’entreprise.
L’angle mort de l’IAM
La vitesse complique tout. Un agent crée, utilise et renouvelle des identités machine à une cadence qui laisse les équipes de sécurité loin derrière. Les contrôles IAM classiques, taillés pour des utilisateurs humains ou des services stables, ne suivent plus le cycle de vie complet d’un agent : création, attribution, surveillance, révocation.
Token Security plaide donc pour une approche identity-first : une identité unique par agent, un propriétaire humain identifié, des droits minimaux, des règles d’expiration et une journalisation réellement exploitable. Objectif : éliminer l’agent orphelin encore actif après un départ d’équipe, ou l’agent trop permissif qui se fait détourner par un prompt malveillant, une session compromise ou une intégration bancale.
« Les agents IA non gérés peuvent escalader leurs privilèges d’un environnement à l’autre, persister comme des comptes orphelins après le départ d’employés, et exposer des données sensibles à grande échelle. » (Token Security, sur son blog)
Plusieurs éditeurs partagent ce diagnostic. Okta a expliqué qu’un agent modélisé comme une simple application de service peut contourner les restrictions propres à l’utilisateur qui l’a lancé. Oracle, côté cloud, parle de scope d’identité, de scope d’outil et de scope de données, avec des accès juste-à-temps pour les opérations sensibles.
Des « privileged insiders » automatisés
Le sujet devient concret à mesure que les agents quittent la phase pilote. Les fonctions visées sont déjà là : support client, gestion documentaire, opérations financières, accès aux ERP, exécution de tâches dans le cloud. À chaque fois, l’agent touche à des données sensibles ou déclenche une action qui, chez un employé, aurait exigé une validation.
Le changement de statut est radical : les agents ne sont plus des outils mais des identités à gouverner comme des comptes privilégiés. L’enjeu n’est pas de leur interdire l’accès, c’est d’encadrer ce qu’ils font, avec quelles données, pour combien de temps et sous quelle surveillance.
Comparer tout ça aux vieux débats sur les comptes de service serait trompeur. Un agent IA n’est pas un backend silencieux : il interagit, s’adapte, sollicite plusieurs systèmes et peut enchaîner des actions imprévues si sa chaîne d’outils ou ses instructions sont détournées. L’identité redevient la première ligne de défense, bien avant le modèle ou l’interface conversationnelle.
