Quand l’accès dépasse la gouvernance : le risque interne des agents IA

Les entreprises confient à des agents IA les clés de leurs contenus les plus sensibles plus vite que quiconque n’écrit les règles d’usage de ces clés. Cet écart entre la vitesse de déploiement et la maturité de la gouvernance devient, sans bruit, le problème de sécurité majeur de 2026, et les responsables de la sécurité le disent désormais eux-mêmes.

L’accès des agents devient la menace numéro un

Selon une étude réalisée par Sapio Research pour Exabeam en juin 2026 et publiée le 16 septembre 2026 — The Agentic Insider: From Monitoring to Understanding, menée auprès de 600 décideurs de la sécurité et de la finance dans sept pays —, 48 % des responsables de la sécurité désignent les agents IA disposant d’accès excessifs, compromis ou non prévus comme la plus grande menace qui pèse aujourd’hui sur leur organisation. L’accès des agents passe ainsi devant les acteurs malveillants externes (28 %), et loin devant les initiés compromis et les initiés malveillants (12 % chacun). Pour la première fois dans une catégorie de menaces que les équipes de sécurité suivent depuis des années, un problème d’infrastructure devance un adversaire.

Ce qui compte vraiment comme un « agent »

La façon dont l’étude définit son objet a son importance. Ses auteurs distinguent soigneusement les « systèmes autonomes, orientés vers un objectif, capables d’accéder aux ressources de l’entreprise et d’agir avec une intervention humaine limitée » des « chatbots conversationnels ». Cette distinction résume tout le problème. Un chatbot répond dans une fenêtre de discussion ; un agent agit : il consulte un référentiel de contrats, extrait une fiche client, rédige et envoie un message, met à jour un système de référence, et il le fait, par conception, avec une intervention humaine limitée. Comme l’a résumé Gabrielle Hempel, d’Exabeam, dans une analyse connexe, un agent peut présenter « une identité valide, un accès autorisé, les outils attendus, aucun attaquant » et provoquer malgré tout un incident. Plus une organisation accorde d’autonomie à un agent (et c’est tout l’intérêt économique de son déploiement), moins il est réaliste de l’encadrer en décidant à l’avance, pour chaque tâche, de ce à quoi il peut toucher.

Pourquoi la définition manuelle des périmètres ne tient pas

C’est le piège dans lequel tombent la plupart des organisations. Face à un agent qui a « trop d’accès », le réflexe est de réduire son périmètre : rôles plus étroits, comptes de service plus restreints, revues des droits agent par agent. Cela fonctionne pour le premier agent. Pas pour le cinquantième, et encore moins lorsque la tâche d’un même agent change d’heure en heure, ou lorsque les contenus auxquels il doit accéder s’étendent aux e-mails, aux partages de fichiers, aux fiches CRM et à des données structurées que personne n’a inventoriées en pensant aux agents. La définition manuelle des périmètres suppose un ensemble de ressources statique et dénombrable, et un ensemble de tâches tout aussi statique et dénombrable. L’IA agentique contredit en permanence ces deux hypothèses.

Surveiller n’est pas comprendre

Les données d’Exabeam montrent la tension que cela crée, même là où la gouvernance n’a pas été négligée. Soixante pour cent des responsables de la sécurité ont mis en place des outils dédiés à la sécurité ou à la gouvernance de l’IA, et 56 % ont étendu leurs plateformes SIEM et de détection existantes pour couvrir les agents. Mais 27 % citent encore le manque de contexte comportemental et de corrélation comme leur principale lacune de surveillance et, comme l’a observé Steve Wilson, directeur de l’IA et des produits d’Exabeam, « les organisations progressent réellement dans la surveillance des agents IA, mais surveiller une activité, ce n’est pas comprendre un comportement ». La surveillance vous dit ce qu’un agent a fait, après coup. Elle ne vous dit pas, avant, s’il aurait dû y être autorisé.

Le problème budgétaire derrière le problème de sécurité

Une seconde contrainte s’ajoute à la première : l’argent. Cinquante-cinq pour cent des responsables de la sécurité déclarent avoir retardé ou réduit un projet de sécurité faute d’avoir pu exprimer le risque en termes financiers acceptables pour leur directeur financier, alors que 93 % signalent que la sécurité et la finance sont globalement alignées sur la tolérance au risque, et que 81 % estiment que leur directeur financier comprend le cyberrisque dans ses grandes lignes. Le fossé ne tient pas à la confiance, mais à la traduction. « Les directeurs financiers remettent rarement en question la réalité d’un cyberrisque », a noté Mike Byron, directeur financier d’Exabeam ; la difficulté est de « comprendre comment l’investissement réduit le risque en termes métier mesurables ». Un modèle de gouvernance capable de montrer des décisions précises et journalisées (telle identité s’est vu refuser telles données pour telle finalité, à telle date) se traduit bien plus facilement en discussion budgétaire qu’un tableau de bord de surveillance.

La couche manquante : une politique décidée au moment de la requête

Assemblez ces éléments et les contours d’une réponse réaliste apparaissent. Il ne s’agit pas de mieux surveiller les agents après qu’ils ont agi, ni d’allonger un tableur de droits par agent décidés avant qu’ils n’agissent. Il s’agit d’une couche de politique placée au point d’accès lui-même, qui évalue pour chaque requête si ces données peuvent être utilisées pour cette finalité par cette identité, humaine ou agent, avant que quoi que ce soit ne bouge. Cette décision doit être prise de façon dynamique, à partir des attributs des données, de l’identité et de l’action demandée, plutôt que fixée une fois pour toutes pour un rôle qui finira inévitablement par devenir obsolète. Et chaque décision, autorisation ou refus, doit être journalisée, afin que la trace de l’application des règles serve aussi de preuve aux auditeurs comme aux directeurs financiers.

C’est dans cette direction que Kiteworks a construit son Data Policy Engine, qui évalue en temps réel les données, l’identité et l’action demandée au regard de la politique et applique une directive (blocage, consultation seule, justification obligatoire ou autorisation), en consignant chaque décision dans une piste d’audit immuable. Pour les agents, Kiteworks décrit ce même point de contrôle, appliqué avant qu’une requête d’IA ne touche des données : vérification de l’identité, évaluation de la politique fondée sur les attributs et journalisation d’audit, l’identité de l’agent étant rattachée à la personne qui l’a autorisé. L’entreprise ne mâche pas ses mots sur l’enjeu : les agents IA « n’exercent aucun jugement éthique indépendant. Ils accéderont à toutes les données auxquelles on ne les empêche pas explicitement d’accéder. »

Ce n’est pas une raison de ralentir le déploiement des agents. C’est une raison de cesser de traiter l’accès comme une décision prise une fois pour toutes, et de commencer à le traiter comme une décision prise à chaque fois.

Si vous réfléchissez à ce que devrait être une limite de politique pour les agents dans votre propre environnement, écrivez à sales@kiteworks.com ou prenez contact avec nous. Inutile d’avoir configuré Claude ou MCP pour poser la question. Consultez le catalogue d’agents et la page sur la prise en charge des assistants.