Quand l'accès dépasse la gouvernance : le véritable risque interne de l'ère agentique

Les entreprises confient aux agents d'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 est en train de devenir, sans bruit, le problème de sécurité qui définit 2026, et les responsables de la sécurité le disent désormais eux-mêmes.

L'accès des agents vient de devenir la menace numéro un

Dans une étude menée par Sapio Research pour le compte d'Exabeam en juin 2026 et publiée le 16 septembre 2026 — The Agentic Insider: From Monitoring to Understanding, qui a interrogé 600 décideurs de la sécurité et de la finance dans sept pays —, 48 % des responsables de la sécurité ont désigné les agents d'IA opérant avec un accès excessif, compromis ou non prévu comme la plus grande menace pesant aujourd'hui sur leur organisation. Cela place l'accès des agents devant les acteurs malveillants externes (28 %), et bien devant les collaborateurs internes compromis et les collaborateurs internes 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 réellement comme « agent »

La manière dont l'étude définit son objet a son importance. Ses auteurs prennent soin de distinguer les « systèmes autonomes guidés par des objectifs, capables d'accéder aux ressources de l'entreprise et d'engager des actions avec une intervention humaine limitée » des « chatbots conversationnels ». Cette distinction, c'est tout le problème en miniature. Un chatbot répond dans une fenêtre de conversation ; un agent agit — il lit 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 formulé Gabrielle Hempel, d'Exabeam, dans une analyse connexe, un agent peut réunir « 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 — ce qui constitue toute la justification économique de son déploiement —, moins il devient réaliste de gouverner cet agent en décidant à l'avance, pour chaque tâche, exactement ce à quoi il peut toucher.

Pourquoi la restriction manuelle des accès s'effondre

C'est le piège dans lequel s'engage la plupart des organisations. La réponse instinctive à « l'agent a trop d'accès » consiste à le restreindre : rôles plus étroits, comptes de service plus serrés, revues d'autorisations agent par agent. Cela fonctionne pour le premier agent. Cela ne fonctionne pas pour le cinquantième, et cela fonctionne encore moins lorsque la tâche d'un même agent change d'heure en heure, ou lorsque le patrimoine de contenus qu'il doit atteindre couvre la messagerie, les partages de fichiers, les enregistrements du CRM et des données structurées que personne n'a inventoriées en pensant aux agents. La restriction manuelle suppose un ensemble de ressources statique et énumérable, et un ensemble de tâches statique et énumérable. L'IA agentique enfreint ces deux hypothèses en permanence.

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. Ainsi, 60 % 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 aux 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, Chief AI and Product Officer d'Exabeam, « les organisations progressent réellement dans la surveillance des agents d'IA, mais surveiller l'activité n'est pas la même chose que comprendre le comportement ». La surveillance indique ce qu'un agent a fait, une fois qu'il l'a fait. Elle ne dit pas, en amont, s'il aurait dû y être autorisé.

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

Une seconde contrainte aggrave la première : l'argent. Au total, 55 % des responsables de la sécurité déclarent avoir retardé ou réduit une initiative de sécurité faute d'avoir pu formuler le risque dans des termes financiers acceptables pour leur CFO — alors même que 93 % indiquent que la sécurité et la finance sont globalement alignées sur la tolérance au risque, et que 81 % estiment que leur CFO comprend le risque de cybersécurité dans ses grandes lignes. L'écart ne tient pas à la confiance, mais à la traduction. « Les CFO mettent rarement en doute la réalité d'un risque de cybersécurité », a noté Mike Byron, CFO d'Exabeam ; la tâche la plus difficile consiste à « comprendre comment l'investissement réduit le risque en termes commerciaux mesurables ». Un modèle de gouvernance capable de pointer des décisions précises et journalisées — telle identité s'est vu refuser telle donnée pour tel usage, à telle date — se traduit bien plus facilement en conversation budgétaire qu'un tableau de bord de surveillance.

La couche manquante : la politique décidée au moment de la demande

En rassemblant ces éléments, la forme d'une réponse praticable se dessine. Ce n'est pas une meilleure surveillance des agents après leur action, et ce n'est pas un tableur plus vaste d'autorisations par agent décidées avant leur action. C'est une couche de politique placée au point d'accès lui-même, qui évalue, pour chaque demande, si ces données peuvent être utilisées à cette fin par cette identité — humaine ou agentique — avant que quoi que ce soit ne bouge. Cette décision doit être prise dynamiquement, à partir des attributs de la donnée, de l'identité et de l'action demandée, plutôt que tranchée une fois pour toutes à l'avance pour un rôle qui finira immanquablement par se périmer. Et chaque décision, autorisation ou refus, doit être journalisée, afin que la trace de l'application de la politique serve aussi de preuve aux auditeurs comme aux CFO.

C'est la direction dans laquelle Kiteworks a construit avec son Data Policy Engine, qui évalue en temps réel la donnée, l'identité et l'action demandée au regard de la politique et applique une directive — bloquer, lecture seule, justification requise ou autoriser — en journalisant chaque décision dans une piste d'audit immuable. Étendu spécifiquement aux agents, Kiteworks décrit le même point de contrôle appliqué avant que toute 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ée. La façon dont l'entreprise formule elle-même l'enjeu est sans détour : les agents d'IA « n'exercent aucun jugement éthique indépendant. Ils accéderont à toutes les données auxquelles il ne leur est pas explicitement interdit de toucher ».

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 quelque chose qui se décide une fois, et de commencer à le traiter comme quelque chose qui se décide à 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 entamez la discussion. Aucune configuration de Claude ou de MCP n'est nécessaire pour poser la question. Parcourez le catalogue d'agents et la prise en charge des assistants.