Pendant près de vingt ans, la cybersécurité d’entreprise a reposé sur une idée relativement stable : l’environnement informatique pouvait être inventorié, cartographié et contrôlé. Les équipes sécurité pouvaient acheter des outils, lister les utilisateurs, suivre les actifs, définir des politiques d’accès et s’appuyer sur des tableaux de bord fournis par des éditeurs.
Ce modèle n’était pas parfait, mais il fonctionnait dans un monde où les changements se produisaient à une vitesse humaine. L’arrivée des agents d’intelligence artificielle change brutalement cette équation. Ces agents ne sont pas de simples applications. Ils peuvent agir de manière autonome, appeler des outils, utiliser des identifiants, accéder à plusieurs systèmes et modifier leur comportement selon le contexte.
Certains agents IA sont officiellement déployés dans des plateformes SaaS. D’autres apparaissent localement sur les postes de développeurs ou dans des workflows internes, parfois sans validation formelle. Ils peuvent exploiter des accès humains, conserver des jetons actifs, interagir avec des données sensibles, puis disparaître avant le prochain inventaire.
La conséquence est majeure : le vieux débat « faut-il acheter ou développer son outil de sécurité ? » devient trop simpliste. À l’ère des agents IA, la vraie question est plutôt : quelle couche de sécurité l’entreprise doit-elle maîtriser elle-même, et quelle couche doit-elle acheter comme fondation fiable ?
Pourquoi les agents IA compliquent la sécurité d’entreprise
Un logiciel traditionnel suit généralement un périmètre assez clair : il a un rôle défini, des permissions connues, des utilisateurs identifiés et un cycle de vie relativement prévisible. Un agent IA, lui, peut être beaucoup plus mouvant.
Il peut être déclenché par un utilisateur, automatiser une tâche, exécuter du code, interroger une base de données, appeler une API, manipuler des fichiers, utiliser un compte de service ou hériter des permissions d’un employé. Dans certains cas, il n’a même pas d’identité propre et apparaît dans les journaux comme s’il s’agissait d’un humain.
Selon des travaux cités par Token Security sur les usages réels des agents IA en entreprise, les déploiements observés vont du simple chatbot déclenché par un utilisateur à des services autonomes connectés à la production. L’un des points les plus préoccupants est que plus d’un cinquième des agents locaux étudiés disposaient déjà d’un accès direct à des sources de données de production.
Ce chiffre illustre un risque très concret : l’IA agentique ne reste pas cantonnée à des environnements de test. Elle touche déjà des systèmes critiques.
Le problème n’est pas seulement l’IA, mais l’accès
Un agent IA devient dangereux lorsqu’il peut atteindre des ressources sensibles sans contrôle suffisant. Le risque ne se limite donc pas à ce qu’il « dit » ou à la qualité de ses réponses. Il concerne surtout ce qu’il peut faire, où il peut aller et quelles données il peut manipuler.
Autrement dit, le centre de gravité de la sécurité des agents IA n’est pas uniquement le filtrage des prompts ou la détection de réponses problématiques. Il se situe dans la gouvernance des identités, permissions, jetons, comptes de service et chemins d’accès.
Les workflows de sécurité figés ne suffisent plus
Les outils de cybersécurité savent déjà détecter de nombreux problèmes classiques : comptes sur-privilégiés, identifiants obsolètes, administrateurs dormants, permissions excessives, accès persistants à la production ou comptes de service mal gouvernés.
Ces capacités restent utiles. Mais elles ne répondent pas toujours aux questions spécifiques que posent les agents IA dans un environnement réel. Par exemple :
- Quels agents créés au cours des deux dernières semaines peuvent accéder à la production via des identifiants hérités d’un utilisateur ?
- Quels agents de développement local conservent encore des jetons actifs après la fin d’un projet ?
- Quel chemin d’attaque permettrait de passer d’un outil SaaS à une base de données critique via un agent IA ?
- Quels agents utilisent des permissions incompatibles avec leur objectif déclaré ?
- Quels agents n’ont plus de propriétaire clair dans l’organisation ?
Ces questions dépendent de l’architecture cloud, des outils SaaS utilisés, des pratiques DevOps, du modèle d’ownership interne, des obligations de conformité et du niveau d’adoption de l’IA dans chaque entreprise.
Aucun éditeur ne peut anticiper toutes ces combinaisons dans un tableau de bord générique. C’est là que se crée un écart opérationnel : les équipes sécurité savent identifier les grandes familles de risques, mais peinent parfois à traduire ces risques en actions précises adaptées à leur propre environnement.
Le piège du « on va simplement le développer nous-mêmes »
L’IA générative a considérablement accéléré le développement d’applications internes. Un outil qui demandait auparavant plusieurs semaines peut désormais être prototypé en quelques heures. Cette évolution change profondément le rapport entre achat logiciel et développement maison.
Le rapport 2026 Build vs. Buy de Retool, cité dans la source, indique que 35 % des équipes avaient déjà remplacé au moins un outil SaaS par une solution développée en interne, et que 78 % prévoyaient de développer davantage au cours de l’année.
Pour les équipes cybersécurité, cette tendance est séduisante : pourquoi attendre une fonctionnalité éditeur pendant plusieurs trimestres si l’on peut créer rapidement un workflow interne avec l’aide de l’IA ?
Mais dans la sécurité, la difficulté n’est pas seulement d’écrire du code. Le vrai défi se situe dans la couche de données.
La donnée sécurité est difficile à consolider
Un workflow de sécurité pertinent a besoin de données fiables sur les identités, les permissions, les propriétaires, les activités, les ressources, les jetons, les secrets, les comptes de service et les dépendances entre systèmes.
Construire une petite application interne est une chose. La connecter proprement à AWS, Azure, GitHub, Salesforce, Okta, aux gestionnaires de secrets, aux pipelines CI/CD, aux plateformes SaaS, aux frameworks d’agents IA et aux systèmes on-premise en est une autre.
Les équipes ne devraient pas avoir à maintenir seules des connecteurs fragiles, normaliser tous les schémas de données, surveiller les changements d’API et corriger des scripts cassés dès qu’un fournisseur modifie son fonctionnement.
C’est le coût caché du « construisons-le nous-mêmes ». Le code n’est que la partie visible. La fondation de données, elle, doit être vivante, normalisée, sécurisée, complète et maintenue en continu.
Le nouveau modèle : acheter la fondation, construire la couche opérationnelle
La réponse la plus réaliste n’est ni « tout acheter » ni « tout développer ». Pour sécuriser les agents IA, le modèle le plus durable consiste à acheter ou adopter une fondation solide, puis à construire la couche opérationnelle propre à l’entreprise.
La fondation doit couvrir les éléments difficiles à maintenir en interne :
- découverte continue des agents, comptes, accès et ressources ;
- intégrations avec les clouds, outils SaaS, annuaires, dépôts de code et pipelines ;
- normalisation des données d’identité et de permissions ;
- corrélation entre utilisateurs, comptes de service, agents et ressources ;
- cartographie des accès et chemins d’attaque ;
- contrôles de gouvernance et de conformité ;
- journalisation et auditabilité ;
- barrières d’exécution sécurisées.
Ces briques exigent une maintenance constante, une profondeur technique importante et une couverture large de l’écosystème IT. Ce n’est généralement pas là que les équipes sécurité doivent concentrer leur temps d’ingénierie limité.
En revanche, elles doivent garder la main sur la couche opérationnelle : les workflows, rapports, revues d’accès, règles de priorisation, automatisations et processus de remédiation qui reflètent la réalité de leur organisation.
Ce que les équipes sécurité doivent vraiment personnaliser
Chaque entreprise a ses propres contraintes. Certaines privilégient la conformité réglementaire. D’autres doivent protéger des environnements de production très sensibles. D’autres encore cherchent à encadrer rapidement l’usage d’agents IA par les développeurs sans freiner l’innovation.
La couche opérationnelle doit donc répondre à des questions très concrètes :
- Qui est responsable de chaque agent IA ?
- Quel est l’objectif métier ou technique de cet agent ?
- Quels systèmes peut-il atteindre ?
- Ses permissions sont-elles cohérentes avec sa mission ?
- Quelles exceptions sont acceptables, et pendant combien de temps ?
- Quel niveau de risque déclenche une alerte, une revue ou une révocation automatique ?
- Que se passe-t-il lorsqu’un agent est abandonné, compromis ou modifié ?
C’est à ce niveau que l’entreprise doit adapter les contrôles à son contexte. La fondation doit fournir la visibilité et les données fiables ; la couche opérationnelle doit traduire ces données en décisions et actions.
L’identité devient le plan de contrôle central des agents IA
Pour les agents IA, la couche la plus structurante est l’identité. Tout agent utile finit par avoir besoin d’un accès : il s’authentifie, utilise des identifiants, invoque des outils, interagit avec des données ou déclenche des actions.
Le problème est qu’un agent n’a pas toujours une identité distincte. Il peut utiliser celle d’un employé, s’appuyer sur un jeton local, exploiter un compte de service ou hériter de droits existants. Dans les journaux d’audit, il peut alors devenir difficile de distinguer l’action humaine de l’action automatisée.
C’est pourquoi l’identité devient le plan de contrôle le plus fiable pour gouverner l’IA agentique. Les garde-fous de prompts et les filtres comportementaux permettent d’encadrer ce que l’agent exprime ou tente de produire. L’identité, elle, gouverne ce qu’il peut réellement atteindre.
Et c’est bien cette portée d’accès qui détermine le rayon d’impact en cas d’erreur, de mauvaise configuration ou de compromission.
Conseils pratiques pour reprendre le contrôle
Les entreprises n’ont pas besoin d’attendre un grand programme de transformation pour commencer à mieux encadrer les agents IA. Plusieurs mesures concrètes peuvent déjà réduire le risque.
1. Inventorier les agents IA visibles et invisibles
La première étape consiste à identifier les agents déjà présents : assistants de développement, automatisations locales, bots connectés à des outils SaaS, scripts enrichis par IA, agents de support, agents métiers ou services autonomes.
L’inventaire doit inclure les agents officiellement déployés, mais aussi les usages non sanctionnés. Le shadow AI est souvent là où les accès sont les moins bien maîtrisés.
2. Relier chaque agent à un propriétaire
Un agent sans propriétaire clair devient rapidement un risque. Chaque agent devrait être associé à une équipe, un responsable métier ou technique, un objectif documenté et une durée de vie attendue.
Cette simple règle facilite les revues d’accès, la suppression des agents inutiles et la gestion des incidents.
3. Cartographier les permissions réelles
Il ne suffit pas de connaître l’objectif annoncé d’un agent. Il faut vérifier ses accès effectifs : bases de données, dépôts de code, tickets internes, messageries, outils cloud, fichiers, API et environnements de production.
La question centrale est simple : l’accès accordé correspond-il réellement à l’intention de l’agent ?
4. Limiter les jetons persistants et les accès hérités
Les jetons locaux, les clés d’API oubliées et les permissions héritées d’utilisateurs humains créent des angles morts. Les équipes doivent surveiller leur durée de vie, imposer une rotation régulière et révoquer les accès à la fin des projets.
5. Automatiser les revues et la remédiation
Lorsque les agents se multiplient, les contrôles manuels deviennent insuffisants. Les revues d’accès, alertes sur permissions excessives, détections d’agents abandonnés et révocations de jetons doivent être automatisées autant que possible.
Ce que les équipes efficaces feront différemment
Le manuel de sécurité conçu pour un environnement entièrement prévisible ne reviendra pas. Les agents IA rendent les systèmes plus dynamiques, plus spécifiques et plus difficiles à anticiper. Les équipes qui réussiront ne seront pas nécessairement celles qui empilent le plus d’outils ou possèdent les tableaux de bord les plus complets.
Les plus efficaces seront celles qui sauront distinguer les couches à maîtriser :
- ne pas reconstruire inutilement la fondation, car les intégrations, la normalisation et la cartographie des identités demandent une maintenance permanente ;
- posséder la couche opérationnelle, car les workflows, priorités, exceptions et règles de remédiation dépendent fortement du contexte interne ;
- placer l’identité au centre, car elle permet de contrôler ce que les agents peuvent réellement atteindre ;
- adapter les contrôles en continu, car les agents apparaissent, changent et disparaissent plus vite que les cycles classiques de gouvernance.
À l’ère de l’IA agentique, sécuriser l’entreprise ne consiste plus seulement à surveiller des applications connues. Il faut gouverner des entités autonomes ou semi-autonomes qui manipulent des accès, des données et des outils au rythme de l’automatisation.
Le nouveau playbook est donc plus adaptatif : une fondation d’identité vivante, des données d’accès fiables, et une couche opérationnelle construite autour des risques réels de l’entreprise. C’est cette combinaison qui permettra d’aller vite avec l’IA, sans perdre le contrôle.