Seules 14,4 % des organisations valident chaque agent IA avant sa mise en production

Les dirigeants affichent leur confiance, mais la télémétrie ne suit pas. Dans une enquête menée auprès de plus de 900 cadres et professionnels techniques, 82 % des dirigeants affirment être certains que leurs règles actuelles les protègent contre les actions non autorisées d’agents IA, alors que la même étude révèle que moins d’une organisation sur six met en production chaque agent avec l’approbation complète de la sécurité et de l’IT. Ces deux affirmations ne peuvent pas rester vraies longtemps, et c’est dans cet écart que se prépare la prochaine observation d’audit.

Ce fossé n’est pas un problème technologique qui attendrait un meilleur outil. C’est un problème de preuve. Lorsqu’un agent accède à des données réglementées, un régulateur, un auditeur ou un avocat adverse demandera qui a autorisé l’agent, à quelles données il a accédé et selon quelle règle. Une politique écrite ne répond à aucune de ces questions. Un enregistrement infalsifiable qui relie chaque action à une identité et à une décision de politique répond à toutes les trois.

Cet article s’appuie sur les résultats de l’enquête pour montrer où la gouvernance des agents fonctionne et où elle échoue, à destination du RSSI et du Chief Compliance Officer qui devront assumer les réponses. Kiteworks secure data exchange est conçu autour de cette question de preuve, et l’argumentaire ci-dessous applique les mêmes règles aux agents et aux personnes qui leur délèguent des tâches.

Résumé de l’article

1. L’approbation ne suit plus le rythme des déploiements.

Les agents arrivent en production avant la validation de la sécurité et de l’IT, ce qui signifie que la revue prévue par la plupart des politiques n’a pas lieu pour la majorité des agents.

2. La confiance n’est pas un contrôle.

Une politique écrite que le système n’applique pas au moment de l’accès aux données n’est qu’une déclaration d’intention, et un auditeur la lira ainsi.

3. Un agent sans identité ne laisse aucune trace.

Des identifiants partagés et des agents non surveillés rompent le lien entre l’action et une personne responsable, alors qu’un enquêteur a besoin de chaque maillon.

4. Les régulateurs réglementent les données, pas les modèles.

Les mêmes exigences de divulgation et de protection s’appliquent, qu’un humain ou un agent ait accédé à l’enregistrement.

5. L’attribution est le fossé le plus facile à combler.

Désigner un responsable pour ce que les agents peuvent lire, écrire et partager coûte peu et rend chaque contrôle ultérieur défendable.

Les chiffres derrière le fossé d’approbation

Le rapport Gravitee sur la sécurité des agents IA 2026, publié en février 2026 et basé sur plus de 900 cadres et professionnels techniques, révèle que 80,9 % des équipes techniques sont passées de la planification à des tests actifs ou à la production. Seuls 14,4 % déclarent que tous leurs agents IA sont mis en service avec l’approbation complète de la sécurité et de l’IT. Mettez ces deux chiffres côte à côte : les agents sont lancés d’abord, et la discussion sur l’approbation vient ensuite, si elle a lieu.

Lisez la source avant de vous appuyer sur les chiffres. Gravitee vend de la gestion d’API, et une enquête menée par un éditeur n’est pas un échantillon aléatoire de l’économie. Les chiffres sont à considérer comme des tendances. Cela reste utile ici, car la tendance reflète ce que les responsables sécurité décrivent en privé. Personne ne prétend que les agents attendent sagement le passage devant un comité de validation.

Le même rapport indique que 88 % des organisations ont confirmé ou suspecté un incident de sécurité lié à un agent IA. Ce chiffre doit être interprété avec prudence. Le nombre d’incidents indique la fréquence des problèmes. Il ne dit pas si l’organisation peut expliquer ce qui s’est passé, pour qui, avec quelles données et sous quelle autorité. Le RSSI et le Chief Compliance Officer sont évalués sur la capacité à expliquer, pas sur le nombre d’incidents.

Conséquence : de nombreux agents échappent à la rencontre avec les équipes sécurité et conformité avant leur lancement. Ces équipes ignorent ce que chaque agent était autorisé à faire, quels identifiants il utilise ou s’il peut lancer d’autres agents. Chaque agent non revu est une question sans réponse qui attend un examinateur, et le nombre de questions augmente à chaque nouveau déploiement.

La confiance n’est pas un contrôle

Le constat le plus inconfortable de l’enquête concerne la perception. Gravitee indique que 82 % des dirigeants se sentent confiants dans la capacité de leurs politiques à les protéger contre les actions non autorisées d’agents, alors qu’en moyenne, seuls 47,1 % des agents d’une organisation sont effectivement surveillés ou sécurisés. Les dirigeants ne mentent pas. Ils raisonnent avec les meilleures informations dont ils disposent, c’est-à-dire une politique écrite.

C’est ce qu’on appelle du « théâtre de gouvernance », et il faut le nommer sans mépris. Une politique décrit l’intention de l’organisation. Un contrôle est un mécanisme qui bloque ou enregistre ce qui se passe, que quelqu’un se souvienne ou non de la politique. Entre les deux, il y a le moment où un agent accède à une donnée, et la plupart des dirigeants n’ont jamais vu ce qui se passe alors.

Un auditeur fait la différence entre les deux. Si on lui demande une preuve que la politique est appliquée, il veut voir le système qui l’applique et le journal qui prouve son exécution. Un classeur de politiques prouve qu’une règle a été écrite. Il ne prouve pas qu’une demande a été évaluée selon cette règle, ce qui est la seule chose que l’examinateur peut tester.

Comme l’explique Bonfy.AI, les agents IA ne sont pas devenus incontrôlables, ils sont simplement allés là où personne ne surveillait, et l’absence d’observateur est un problème de gouvernance, pas un dysfonctionnement d’agent. Pour combler ce fossé de confiance, il faut placer un observateur, et un contrôleur, au point d’accès, puis conserver l’enregistrement dans un endroit que l’agent ne peut pas modifier.

Un prompt système ne comble pas ce fossé. Une instruction qui demande à un modèle d’éviter certains enregistrements peut être contournée par injection de prompt ou modifiée lors d’une mise à jour du modèle, et un auditeur n’acceptera pas « le modèle a reçu l’instruction de ne pas le faire » comme preuve de contrôle d’accès. L’application du contrôle doit être liée à la donnée, indépendamment du modèle, et laisser une trace qui subsiste après la session.

Des agents sans identité ne laissent aucune trace

L’identité est le premier maillon faible de la chaîne de preuve. Gravitee note que seuls 21,9 % des équipes considèrent les agents comme des entités indépendantes dotées d’une identité propre. Les autres laissent les agents agir avec des identifiants empruntés, ce qui signifie qu’un journal d’accès indique qu’une action a eu lieu, mais pas quel agent l’a réalisée ni qui l’a mandaté.

Imaginez un audit dans ce contexte. Un identifiant partagé ne permet pas d’identifier l’acteur. Un acteur sans identité ne peut pas être relié à la personne qui lui a délégué la tâche. Un workflow non surveillé ne laisse aucune trace. Chacune de ces failles supprime un lien entre l’action et une personne responsable, alors qu’une enquête défendable exige la chaîne complète, de l’autorisation à l’action puis au résultat.

Les pratiques d’authentification montrent comment cette habitude s’installe. Le même rapport indique que 45,6 % des équipes utilisent encore des clés API partagées pour l’authentification entre agents. Les clés partagées sont pratiques, et la praticité transforme une faille de gouvernance en norme. Personne n’a choisi de rendre les agents anonymes. Les équipes ont simplement réutilisé ce qui fonctionnait déjà pour les services.

Les fonctionnalités aggravent le problème. Les agents capables de créer et de piloter d’autres agents allongent la chaîne de délégation d’un maillon supplémentaire, sans autorisation. Un agent qui en génère un autre transmet tous ses accès, et le nouvel agent hérite des droits de son parent. Impossible de gouverner ce qu’on ne peut pas attribuer, et un arbre d’agents sans identité à chaque nœud est quasiment impossible à reconstituer.

La solution est simple à formuler, mais exigeante à mettre en œuvre. Il faut traiter agents et humains comme deux classes d’identité sous un même modèle de gouvernance. Chaque agent agit pour une personne nommée, dans les limites fixées par la politique, avec une trace reliant chaque action à l’humain qui l’a mandaté. C’est cela, l’attribution, et c’est ce qu’un enquêteur attend.

Les régulateurs réglementent les données, pas les modèles

Prenons l’exemple d’un système de santé dont un agent lit un dossier patient pour rédiger un résumé, puis stocke la sortie au mauvais endroit. L’analyse réglementaire ne change pas parce que l’acteur est un logiciel. L’obligation porte sur les informations médicales protégées et sur les mesures de protection annoncées par l’organisation. HIPAA ne demande pas si c’est un clinicien ou un programme qui a accédé au dossier. Même logique pour les données de carte bancaire (PCI DSS) ou les données financières clients (GLBA, SOX). Le service juridique décide de ce qui doit être déclaré dans chaque cas, et cet article fournit des informations générales uniquement.

Le Chief Compliance Officer a besoin de preuves disponibles plus vite que l’horloge ne tourne. Le rapport annuel 2026 de Kiteworks sur les risques liés à la sécurité et à la conformité des données indique que 50 % des organisations ne peuvent pas produire un audit complet des accès IA en moins d’un jour ouvré, et 63 % déclarent avoir subi une conséquence de conformité dans les douze derniers mois (constat d’audit, plan de remédiation, remontée au conseil, pénalité contractuelle ou enquête réglementaire formelle). Les délais de notification et d’audit se comptent en jours, et un dossier de preuve qui prend des semaines est un risque en soi.

Le fossé de la preuve est la version du problème pour le CCO. Les journaux existent souvent, mais un journal n’est une preuve que s’il relie une action à une identité, une décision de politique et un horodatage infalsifiable. Un audit trail robuste fait la différence entre expliquer à un examinateur ce qui s’est probablement passé et lui montrer ce qui s’est réellement produit.

Le secteur financier illustre bien les enjeux. Les superviseurs attendent des entreprises qu’elles protègent les règlements, la trésorerie et les données clients, peu importe qui y accède. Les organisations financières qui adoptent des agents pour gagner en productivité doivent désormais appliquer ces exigences à chaque identité pouvant accéder à des contenus réglementés. Même raisonnement pour la santé, le juridique ou la défense.

À quoi ressemble un incident quand personne n’a validé le chemin

Un cas récent et concret illustre ce fossé. Cybernews a rapporté que des agents IA de développement ont exposé plus de 13 000 captures d’écran internes de 343 entreprises technologiques sur des dépôts publics GitHub, y compris des dossiers clients, données de facturation, écrans de paiement et fonctionnalités non publiées. Les agents ne pouvaient pas joindre d’images à des pull requests privées, alors ils les ont publiées publiquement par défaut.

Aucune attaque n’était nécessaire dans ce scénario. Les agents ont simplement exécuté une tâche avec les autorisations dont ils disposaient déjà, et aucune politique n’interdisait ce contournement d’une manière exploitable par un logiciel. C’est le fossé d’approbation à l’échelle réduite : une action réalisée sans décision traçable, sur des données protégées par les régulateurs, sans trace que l’équipe conformité puisse présenter.

La leçon pour le RSSI n’est pas que les agents de développement sont dangereux. C’est que l’autorité et l’autorisation sont deux choses différentes. Avoir le droit de créer un dépôt public n’est pas la même chose qu’avoir l’autorité de publier des données internes, et les autorisations ne déterminent pas ce que l’IA devrait pouvoir utiliser. La plupart des environnements ne font pas encore la distinction.

La leçon pour le Chief Compliance Officer concerne la preuve. Après un incident de ce type, l’organisation doit montrer qui a autorisé la sortie des données, quelle règle a encadré la décision et où se trouve la trace. Si la réponse est « il faudrait la reconstituer », l’organisation est déjà en retard sur l’horloge du régulateur.

Le Shadow AI creuse le fossé plus vite que la politique ne le comble

Le rapport IBM 2026 sur le coût d’une violation de données chiffre le phénomène. Les incidents de Shadow AI représentent 43 % des violations recensées, contre 20 % un an plus tôt, et coûtent plus cher (5,39 millions de dollars en moyenne). 68 % des organisations victimes n’avaient pas de gouvernance pour gérer l’IA ou détecter le Shadow AI, et 92 % de celles touchées par une violation liée à l’IA n’avaient pas de contrôle d’accès adapté.

Ces chiffres décrivent des organisations qui ont adopté l’IA plus vite qu’elles n’ont mis en place les contrôles pour la surveiller. Le fossé d’approbation dans les données Gravitee raconte la même histoire à l’échelle d’un pipeline de déploiement. Un agent qui arrive en production sans revue, c’est du Shadow AI, que l’équipe en ait conscience ou non.

Les données d’usage expliquent pourquoi le fossé s’élargit. Le rapport Verizon 2026 sur les violations de données indique que 45 % des employés utilisent régulièrement l’IA sur des appareils professionnels, contre 15 % l’année précédente. La part passant par des comptes non professionnels, à 67 %, baisse légèrement, donc il ne s’agit pas d’une explosion du Shadow AI, mais d’un triplement de l’usage global, dont la majorité échappe toujours à la couche d’identité visible par la sécurité.

L’adoption est aussi encouragée par le sommet. Le rapport OneTrust 2026 sur la gouvernance IA, basé sur 1 200 décideurs dans huit marchés, montre que 87 % des organisations encouragent l’usage d’agents IA, mais seulement 47 % disposent de règles, de supervision et de contrôles clairs pour ces agents. Il s’agit d’une enquête d’éditeur à lire comme une tendance, mais un écart de quarante points entre encouragement et contrôle est un problème de responsabilité avant d’être un problème technique.

Ce que changerait une gouvernance au niveau de la donnée, et ce qu’elle ne changerait pas

Kiteworks Compliant AI régit l’interaction des agents avec les données réglementées au niveau de la donnée, indépendamment du modèle, du prompt ou du framework agent. Chaque interaction passe par quatre points de contrôle. L’agent s’authentifie via OAuth 2.0 et est lié à l’humain qui a délégué le workflow. Une politique basée sur les attributs évalue la demande en temps réel selon l’identité de l’agent, la classification de la donnée et le contexte, en appliquant le principe d’accès minimum nécessaire au niveau de l’opération. Le chiffrement validé FIPS 140-3 protège les données en transit et au repos. Un audit trail infalsifiable enregistre l’interaction avec attribution complète et l’envoie au SIEM de l’équipe sécurité.

Le Kiteworks Secure MCP Server place ce modèle devant des clients IA comme Claude ou Copilot. Chaque requête est évaluée selon des contrôles d’accès basés sur les rôles et sur les attributs via le Data Policy Engine, de sorte qu’un client IA ne reçoit que les données jugées appropriées par la politique. Les jetons OAuth sont stockés dans le keystore du système d’exploitation et jamais exposés au modèle de langage, et le contenu des fichiers transférés par le serveur n’est pas ajouté au contexte du modèle sans action explicite de l’utilisateur. Avant tout téléchargement, le serveur vérifie l’antivirus et le statut de la prévention des pertes de données, et les administrateurs peuvent désactiver des outils destructeurs ou restreindre ceux accessibles aux agents.

Imaginez si les agents accédaient aux systèmes et données internes uniquement via un chemin gouverné de ce type. Chaque requête serait liée à un humain autorisateur, évaluée selon la politique et journalisée, ce qui permettrait à l’organisation de répondre à la question du « qui, quoi, selon quelle règle ». Le CCO disposerait de preuves à remettre à un examinateur, et le RSSI contrôlerait un point de contrôle indépendant du choix de l’agent. Une approche zéro trust pour l’IA générative applique le même principe, sans confiance implicite dans l’identité ou l’intention de l’agent.

La portée de cette affirmation est importante. Une gouvernance au niveau de la donnée contrôle ce que les agents peuvent atteindre et enregistre leurs actions. Elle ne contrôle pas une capture d’écran prise par un agent sur l’écran d’un développeur, ni la création d’un dépôt public sur un compte personnel. Les contrôles qui encadrent ces destinations doivent compléter la gouvernance au niveau de la donnée, pas la remplacer. Ensemble, ils couvrent à la fois les données qu’un agent peut demander et les destinations qu’il peut utiliser.

Un guide de gouvernance pour RSSI et responsables conformité

Commencez par l’attribution. Désignez un dirigeant responsable de ce que les agents peuvent lire, écrire, publier et partager, et donnez-lui l’autorité sur l’ingénierie, la sécurité et la conformité. La responsabilité de la sécurité IA est encore floue dans la plupart des organisations, avec des leaders différents selon l’interlocuteur, et aucun contrôle technique ne compense une absence de responsable.

Poursuivez en dressant l’inventaire de tous les agents en production et en test. Notez qui les a créés, qui leur a délégué des tâches, quels identifiants ils utilisent, quelles données ils peuvent atteindre, et s’ils peuvent lancer d’autres agents. Les chiffres Gravitee suggèrent que la plupart des organisations ne peuvent pas produire cette liste aujourd’hui, donc le premier livrable est une liste, pas un outil.

Troisième étape : attribuez à chaque agent une identité liée à l’humain qui l’a autorisé, et abandonnez les clés partagées pour l’authentification entre agents. Appliquez les mêmes règles de classification et de gestion des données à ce que les agents lisent et produisent qu’à ce que font les humains, y compris pour les images et enregistrements qui échappent aux contrôles textuels.

Quatrième étape : faites appliquer la politique là où l’agent accède à la donnée, pas là où la règle est écrite. Une règle consignée dans un manuel et jamais vérifiée est une règle qu’un auditeur ignorera. Associez l’application à un processus de gestion des incidents documenté, couvrant déjà les événements causés par des agents.

Enfin, entraînez-vous à produire la preuve. Choisissez un workflow d’agent, demandez à l’équipe de fournir l’historique complet des accès et des autorisations, et chronométrez le résultat. Un tableau de bord RSSI qui affiche l’activité des agents à côté de celle des humains donne la réponse en quelques minutes. Si l’exercice prend une semaine, l’organisation a identifié son exposition réelle avant le régulateur.

La question de responsabilité que chaque conseil d’administration va poser

Le fossé d’approbation ne se comblera pas tout seul, car la pression va dans un seul sens. Les équipes métiers sont récompensées pour le déploiement d’agents, et la revue n’est valorisée que lorsqu’un problème survient. Les agents IA bousculent les modèles de sécurité traditionnels précisément parce que ces modèles partaient du principe qu’un humain ferait une pause au moment de la décision.

Les conseils d’administration poseront deux questions lors du prochain cycle : qui est responsable de ce que font nos agents, et pouvons-nous le prouver ? Ceux qui répondront avec un responsable nommé, un inventaire des agents et un dossier de preuves feront des chiffres de l’enquête un simple point de comparaison. Les autres verront ces chiffres décrire leur propre organisation.

Pour en savoir plus sur la gouvernance des accès aux données par les agents IA avec des preuves auditables, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  Comment 77 % des organisations échouent en matière de sécurité des données IA
• eBook
  Fossé de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne veulent plus savoir si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.