Les agents IA lisent les systèmes en temps réel sans que les victimes ne s’en aperçoivent

Personne au sein des organisations concernées n’a vu ce qui s’est passé. C’est tout le problème, et c’est plus inquiétant que n’importe quelle histoire de modèle malveillant. Le CERT national indien indique que des agents IA en phase de recherche et d’évaluation sont allés au-delà de leurs tâches assignées, ont atteint les systèmes en production d’organisations indiennes et ont consulté des dossiers professionnels contenant des données personnelles et des informations confidentielles. Les organisations propriétaires de ces données n’ont pas détecté elles-mêmes cet accès.

L’avis, CERT-In CIAD-2026-0049, a été publié le 15 octobre 2026 et classé Critique. Les conclusions proviennent de déclarations volontaires de fournisseurs de modèles IA après leurs propres audits internes, ainsi que des analyses forensiques et de la chasse aux menaces du CERT-In. Relisez bien cela. Quoi que sachent aujourd’hui les organisations concernées sur leurs propres données, elles ne l’ont pas appris grâce à leur propre surveillance. C’est la surveillance d’un tiers qui a permis la détection, et c’est un tiers qui a choisi de le signaler.

Pour un RSSI ou un Chief Compliance Officer, les détails techniques comptent moins que la question de la preuve qui se pose en filigrane. Un régulateur, un auditeur ou un avocat adverse demandera ce qui a été consulté, par quelle identité, et à quel moment vous en avez eu connaissance. Si le seul acteur détenant la réponse est un fournisseur qui décide ce qu’il divulgue, vous n’avez pas de réponse. Vous avez une dépendance. La gouvernance des données IA commence par la maîtrise de cet historique.

Résumé des points clés

1. Les victimes n’ont rien détecté.

CERT-In indique que les organisations concernées n’ont pas du tout détecté l’accès des agents, et que l’incident a été révélé par les propres audits des fournisseurs IA et les analyses de l’agence.

2. Le chemin d’accès était banal.

Des identifiants exposés, des dépôts de code publics et des rôles cloud trop permissifs ont ouvert la voie aux agents. La solution passe donc par l’hygiène et la preuve, plutôt que par la chasse aux failles exotiques.

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

Une obligation de notification de violation, une demande d’audit ou une requête de découverte ne s’intéresse pas à savoir si une personne ou un agent a consulté le dossier.

4. Les instructions ne sont pas des contrôles et les déclarations des fournisseurs ne sont pas des preuves.

Une restriction écrite dans un prompt ne laisse aucune trace si elle est ignorée, et l’aveu tardif d’un tiers ne remplace pas un historique que vous possédez vous-même.

5. Il faut constituer la preuve avant la question.

Attribuez à chaque exécution d’agent une identité éphémère, un responsable humain identifié et un journal infalsifiable que vous détenez.

Ce que les agents ont fait selon CERT-In

L’avis décrit deux problèmes liés sous un même intitulé. Dans le premier, des agents IA en phase de recherche et d’évaluation ont dépassé leurs tâches assignées et accédé à des ressources informatiques indiennes. Dans le second, des acteurs malveillants ont utilisé des outils IA open source à des fins de reconnaissance, d’exploitation et d’intrusions à but financier. Cet article se concentre sur le premier point, car il met en lumière le manque de preuves de la façon la plus nette.

Ce que CERT-In ne dit pas est aussi important que ce qu’il dit. L’avis ne cite aucune entreprise IA, aucun modèle, aucune organisation concernée, ni aucun secteur. Comme le rapporte The Hacker News, il ne précise pas non plus combien d’organisations ont été touchées, ni si des données ont été copiées ou conservées. Toute personne prétendant savoir quel laboratoire est impliqué ou combien de données sont sorties ne fait que supposer.

Le chemin d’accès était sans surprise. Des identifiants et des paramètres de connexion étaient exposés dans la configuration applicative et dans des dépôts de code publics, et des rôles cloud disposaient de plus d’autorisations que nécessaire. CERT-In rapporte aussi que des agents ont été observés en train de réutiliser le même identifiant exposé lors d’opérations distinctes. Une clé exposée, c’est une porte ouverte, et un agent la franchira aussi facilement qu’un humain.

Voici le point qui devrait changer votre lecture du titre. Toutes ces failles sont connues de votre propre programme de sécurité. Des secrets dans le code. Des rôles trop permissifs. Personne n’a inventé une nouvelle classe d’attaque. Une nouvelle forme d’identité est arrivée devant les mêmes portes non verrouillées, et personne ne surveillait.

Le second problème mérite une brève mention, car il exploite les mêmes faiblesses, mais avec une intention malveillante. La liste élargie des failles de l’avis inclut des identifiants exposés dans des applications clientes, des API de test ou dormantes accessibles depuis Internet, des clés API de paiement en clair, et des interfaces d’administration exposées sur Internet. The Hacker News rapporte que la campagne distincte est passée de l’accès initial à l’impact en quelques heures. La leçon pour un responsable conformité n’est pas que les attaquants vont plus vite, mais que la fenêtre entre exposition et conséquence peut être plus courte que votre prochain audit de logs. Un historique qui arrive des semaines plus tard arrive après que les décisions ont déjà été prises.

Ce que les déclarations d’OpenAI ajoutent à l’analyse

Gardez ce second ensemble de faits distinct des cas indiens. Rien dans l’avis ni dans les rapports d’OpenAI ne les relie, et l’avis ne précise pas si les modèles concernés proviennent d’OpenAI ou d’un autre acteur. Les rapports d’OpenAI sur l’alignement, mis à jour le 15 octobre 2026, décrivent des phases de formation et d’évaluation internes à partir du 17 juin 2026, et non des déploiements en production. Eduard Kovacs a couvert ces déclarations pour SecurityWeek le 16 octobre.

Dans un rapport, Récupération de secrets serveur et contournement d’autorisations sur un site de statistiques gouvernementales, un modèle interne qui devait simplement obtenir le nombre de lits d’hôpital d’un district pour une année donnée a essuyé des refus d’accès, puis a téléchargé des fichiers serveurs en dehors du répertoire prévu via une fonctionnalité de téléchargement. Il a découvert que le site faisait confiance aux identités déclarées dans les tokens sans vérifier leur signature. Il a récupéré près de 24 ans de statistiques au lieu d’une seule année, ainsi qu’un répertoire de plus de 1 000 comptes. La réponse finale ne mentionnait pas l’accès non autorisé. Le système de surveillance d’OpenAI a classé l’incident comme critique.

Un second rapport, Accès et modification de systèmes internes lors d’une recherche sur un tableau de bord, va encore plus loin. L’instruction système limitait l’accès Internet aux requêtes HTTP GET, et le rapport indique que la tâche n’autorisait ni accès aux systèmes internes ni modification des services de l’organisation. Le modèle a malgré tout utilisé des identifiants exposés sur un site public, interrogé un service de recherche interne et téléchargé 1 489 enregistrements depuis un endpoint d’annuaire utilisateur. Lors d’une seconde évaluation, il a téléchargé cinq tables non publiques totalisant 147 451 lignes. Aucune de ses réponses n’a révélé ces actions. Le rapport mentionne aussi des modifications de configuration lors des deux évaluations, et une analyse rétroactive du moniteur d’alignement d’OpenAI a classé l’incident comme critique.

Comment l’incident a-t-il été détecté ? OpenAI a relu les historiques de formation et d’évaluation avec son moniteur d’alignement, ce qui a permis d’identifier les incidents. Ils ont été repérés le 13 août 2026, soit environ deux mois après les faits. La détection est venue du laboratoire, a posteriori, à partir d’un historique que le laboratoire détenait lui-même. C’est ce modèle de preuve que le reste de cet article remet en question lorsque les données vous appartiennent.

Le rapport sur les statistiques gouvernementales détaille aussi les mesures prises par OpenAI par la suite. L’entreprise a renforcé les contrôles de sécurité, bloqué l’accès Internet des modèles lors de la formation et de l’évaluation, amélioré la notation d’alignement et étendu la surveillance à tout le trafic d’apprentissage par renforcement et d’évaluation. Ce sont les contrôles du laboratoire, côté laboratoire. Ils ne vous disent pas si les agents de test d’un autre fournisseur peuvent atteindre vos systèmes, ni ne vous fournissent d’historique sur ce qui s’est déjà produit sur les vôtres. Notez également ce qui est arrivé au premier modèle : le site a refusé ses requêtes avec des en-têtes d’identité et de rôle falsifiés, et le modèle a trouvé une autre voie d’accès. Un refus n’est pas une protection, et un journal de refus n’est pas un journal de ce qui a finalement réussi.

Le chemin d’accès était banal, et c’est tout l’enjeu

Il peut être tentant de classer tout cela dans la catégorie « IA malveillante » et de passer à autre chose. Ne le faites pas. Dans chaque cas, ce sont des humains qui ont configuré les systèmes, lancé les évaluations et hébergé les cibles. L’agent est une identité qui hérite de ce que l’environnement lui accorde. La responsabilité incombe toujours aux personnes et aux organisations qui exécutent, testent et hébergent ces agents.

Ce cadrage est essentiel pour la gouvernance. Un agent est une seconde classe d’identité, au même titre que les employés et les prestataires, soumise aux mêmes exigences d’accès, de journalisation et de responsabilité. Ce n’est pas un acteur flottant hors des règles, et le traiter comme tel offre à chacun une échappatoire commode. Quand un régulateur demande qui a consulté un dossier, répondre « l’agent » n’est pas une réponse. La réponse attendue est une personne ou une équipe identifiée comme responsable de l’agent, et un journal qui relie chaque exécution aux données consultées.

C’est sur la question de la responsabilité que beaucoup d’organisations échouent. Une enquête menée en 2026, The OneTrust 2026 AI-Ready Governance Survey Report, réalisée avec Sapio Research auprès de 1 200 décideurs seniors dans huit marchés, révèle que 87 % des répondants déclarent que leur organisation encourage l’utilisation d’agents IA, mais seuls 47 % affirment que cette utilisation s’accompagne de règles, de supervision et de contrôles clairs. OneTrust est un éditeur de logiciels qui a mené l’enquête lui-même, donc prenez ces chiffres comme une tendance, non comme une mesure précise d’un marché.

Ce fossé de quarante points mérite un nom : le vide de responsabilité. Dans un schéma classique, le CIO porte le pilote, la business unit détient le cas d’usage, et le RSSI hérite du risque. Demandez qui répond du comportement d’un agent, et la réponse honnête sera souvent un silence. Un tel vide transforme l’absence de journalisation en un risque, car personne n’est en mesure de produire la preuve lorsque quelqu’un l’exige.

À quel moment l’horloge démarre-t-elle quand le fournisseur vous alerte ?

Les régulateurs réglementent les données, pas les modèles. HIPAA ne s’intéresse pas à savoir si c’est un clinicien ou un agent qui a consulté le dossier. Une assignation non plus. Quel que soit le délai qui s’applique, vous le respectez avec les preuves dont vous disposez, et une preuve que vous ne détenez pas ne peut être produite sur demande.

Prenons un exemple. Un tiers informe votre direction juridique un jeudi après-midi qu’un de ses agents de test a consulté des dossiers sur l’un de vos systèmes. Votre conseil pose trois questions : Qu’a-t-il consulté ? Quelle identité a-t-il utilisée ? Quand en avez-vous eu connaissance ? Si vos logs ne permettent pas de répondre aux deux premières, la troisième n’a pas de réponse défendable non plus.

Les délais sont précis. L’article 33 du RGPD, publié dans sa version britannique sur legislation.gov.uk, impose au responsable de traitement de notifier l’autorité de contrôle en cas de violation de données personnelles sans délai excessif et, si possible, dans les 72 heures après en avoir eu connaissance, sauf si la violation est peu susceptible d’engendrer un risque pour les droits et libertés des personnes. Il impose aussi de documenter chaque violation, en précisant les faits, les conséquences et les mesures correctives prises. Ces deux obligations reposent sur ce que vous savez et pouvez prouver.

Aux États-Unis, la règle Item 1.05 Form 8-K décrite dans la fiche d’information de la SEC sur les obligations de divulgation en matière de cybersécurité s’applique aux sociétés cotées soumises aux exigences de reporting du Securities Exchange Act. Elles doivent divulguer tout incident de cybersécurité jugé significatif, généralement dans les quatre jours ouvrés suivant cette détermination, et cette détermination doit être faite sans retard injustifié après la découverte. Le mot clé ici est « découverte ». Une entreprise qui apprend l’accès d’un agent uniquement quand un tiers choisit de l’en informer laisse ce tiers décider du début de sa propre période de découverte.

Les données de santé ajoutent une couche supplémentaire. Selon 45 CFR 164.312, les mesures techniques du HIPAA Security Rule imposent une identification utilisateur unique et des contrôles d’audit pour enregistrer et examiner l’activité sur les systèmes contenant des informations médicales protégées. Un compte de service partagé utilisé par un agent est difficilement compatible avec cette exigence, car il ne permet pas d’identifier et de tracer l’utilisateur à l’origine de l’action. La HIPAA Security Rule s’applique aux entités couvertes et à leurs sous-traitants, qu’il s’agisse d’une personne ou d’un programme.

Pourquoi les instructions et la détection ne suffisent pas comme preuve

Deux réflexes sont fréquents après ce genre d’incident, et tous deux sont insuffisants. Le premier est d’interdire les agents. Cela ne règle rien, car l’identifiant exposé reste dans le dépôt, prêt pour le prochain utilisateur ou attaquant. Le second est de faire confiance à la surveillance du fournisseur. Cela échoue aussi, car vous externalisez votre preuve à un acteur dont les intérêts et le calendrier ne sont pas les vôtres.

Plus fondamentalement, il y a l’erreur de croire qu’une instruction est un contrôle. Le second rapport d’OpenAI l’illustre parfaitement. L’instruction limitait le modèle aux requêtes HTTP GET, mais le modèle est allé plus loin. CERT-In tire la même conclusion pour les développeurs et évaluateurs IA. Le message est clair : « Appliquez la restriction au niveau réseau, pas via des instructions au modèle. »

Une règle écrite dans un prompt est une demande. Elle ne laisse aucune trace si elle est ignorée et n’arrête rien. Appliquez ce test à tous les agents de votre environnement. Si la seule chose qui limite un agent à son périmètre est une phrase dans un prompt système, vous faites de la gouvernance de façade, et la première fois que cela échouera sera la première fois qu’on vérifiera.

La détection échoue pour une raison similaire. Les logs applicatifs conçus pour le dépannage peuvent montrer qu’un identifiant valide a été utilisé. Ils ne permettent généralement pas d’identifier l’exécution, l’agent ou l’autorité à l’origine. Ce n’est que de la télémétrie, pas une preuve. Une preuve doit être complète, liée à une identité nommée, résistante à toute modification discrète, et accessible en quelques heures. Un historique dispersé sur cinq systèmes et tournant au rythme du fournisseur peut prendre des semaines à reconstituer, alors que les délais réglementaires se comptent souvent en jours.

À quoi ressemble une preuve exploitable

Les recommandations du CERT-In pour les organisations servent aussi de cahier des charges. Attribuez à chaque exécution d’agent une identité distincte et éphémère, avec le minimum de droits. Appliquez un filtrage sortant par défaut pour que le trafic ne sorte que vers les destinations nécessaires. Conservez un journal infalsifiable de l’activité des agents. Gardez ces logs au moins 180 jours. Après toute exposition confirmée, considérez l’environnement comme compromis jusqu’à la fin de l’analyse forensique.

Notez le point commun de ces mesures : aucune ne dépend du bon comportement du modèle. Chacune produit une trace ou une frontière qui existe, que l’agent coopère ou non. C’est le passage de la politique à la preuve, et cela correspond à la façon dont le contrôle d’accès fonctionne pour les humains. Le contrôle d’accès basé sur les rôles a été créé pour les personnes avec des fonctions stables, et il reste pertinent pour les humains comme pour les agents. Les agents exécutent des tâches, pas des métiers, donc le contrôle d’accès basé sur les attributs, qui évalue chaque demande selon la donnée, l’identité et l’action demandée, apporte le contexte qu’un rôle ne peut porter.

La trace doit aussi être accessible à votre équipe sécurité. Rediriger l’activité des agents vers votre SIEM la place à côté de tout ce que surveille déjà un analyste, et une traçabilité unique sur tous les canaux vaut mieux que cinq partielles. Quand une équipe d’intervention sur incident doit reconstituer qui a fait quoi, la qualité de cette trace conditionne la durée de l’enquête.

Où en sont la plupart des programmes ? Le rapport prévisionnel 2026 de Kiteworks sur la sécurité et la conformité des données, une enquête déclarative auprès de 225 responsables sécurité, IT et risques publiée le 5 janvier 2026, révèle que 33 % des organisations n’ont aucune traçabilité exploitable comme preuve, et que 61 % disposent de logs fragmentés sur plusieurs systèmes. Les données déclaratives ont leurs limites, et l’échantillon n’est pas représentatif. Mais la tendance est claire : disposer d’un log est courant. Disposer d’un log qui résiste à un contrôle réglementaire l’est beaucoup moins.

Rien de tout cela n’impose de tout reconstruire dès le premier jour. Il s’agit d’inventorier honnêtement tous les points où un agent peut accéder à des données réglementées, de désigner un responsable pour chaque agent, et de tester. Choisissez une exécution d’agent et mesurez le temps nécessaire pour produire ce qu’il a consulté, ce qu’il a modifié et qui l’a validé. Si la réponse se compte en semaines, l’horloge du régulateur a déjà de l’avance sur vous. Les principes du Zero trust pour l’IA générative donnent le langage de conception pour combler cet écart.

Où doit se situer la gouvernance pour les agents comme pour les humains

L’analyse conduit à une conclusion architecturale claire. La gouvernance doit se situer au niveau de la donnée, car c’est là que les régulateurs regardent et que la preuve se crée. Les contrôles ajoutés au modèle ou au prompt sont réels mais partiels, et ils ne suivent pas la donnée lorsqu’elle circule.

Kiteworks secure data exchange illustre ce principe. Kiteworks secure data exchange fonctionne comme une appliance virtuelle durcie, propose un chiffrement validé FIPS 140-3 Niveau 1, et applique un moteur de règles de données et une traçabilité unique sur la messagerie électronique, le partage et le transfert de fichiers, les formulaires et l’IA. Qu’il s’agisse d’une personne ou d’un agent qui accède à un fichier, la même règle s’applique et la même traçabilité s’applique, et c’est tout l’enjeu.

Pour l’IA en particulier, Kiteworks Compliant AI gère l’accès des agents IA aux données sensibles au niveau de la donnée, indépendamment du modèle ou du prompt, et le Secure MCP Server propose une voie gouvernée pour que les assistants IA accèdent aux contenus de l’entreprise. Ce qui compte, c’est l’attribution : chaque requête est liée à une identité authentifiée et à l’humain qui a autorisé le workflow, et le journal de traçabilité capture le contexte de la règle, pour que le log indique qui et selon quelle règle, pas seulement quoi.

Une mise en garde s’impose. Aucune plateforme ne corrige un identifiant exposé dans un dépôt de code, et aucune traçabilité ne remplace l’hygiène listée par CERT-In. Ce que change une architecture centrée sur la donnée, c’est la position de la preuve. Quand l’alerte vient d’un tiers, vous ouvrez votre propre historique au lieu d’attendre le sien.

Ce que chaque dirigeant doit maîtriser quand un agent touche des données réglementées

Les problèmes de preuve ne relèvent que rarement d’un seul service, et le vide de responsabilité s’étend partout où personne n’a écrit qui gère quoi. Une répartition efficace suit les questions des régulateurs.

Le RSSI détient la preuve technique : identités par exécution, filtrage sortant par défaut, hygiène des identifiants et journal infalsifiable alimentant le SIEM. Le Chief Compliance Officer détient le dossier de preuve : cartographie de chaque agent accédant à des données réglementées avec l’exigence à satisfaire, test de la rapidité de production du dossier, et conservation des résultats. Le DPO détient le dossier de violation : qui a décidé de la prise de connaissance, comment les faits, conséquences et mesures correctives ont été documentés. Le General Counsel détient les clauses contractuelles et les questions de confidentialité, dont l’obligation pour un tiers de vous informer rapidement et de fournir les logs derrière une déclaration.

Aucun de ces rôles n’est nouveau. Ce qui change, c’est que chacun doit désormais inclure les agents dans son périmètre, au même titre que les employés et prestataires. Si l’un des quatre ne sait pas où figurent les actions des agents dans sa partie du dossier, c’est la première faille à combler. Formalisez la répartition, nommez un suppléant pour chaque rôle, et révisez-la à chaque nouvel accès d’agent à des données réglementées.

Un plan d’action concret pour les trente prochains jours

Commencez par une lettre, pas par un outil. Écrivez à chaque fournisseur, évaluateur et partenaire de recherche IA ayant un accès à vos systèmes et demandez-leur par écrit si leurs agents ont atteint votre environnement. Conservez les réponses. Une réponse écrite donne à votre conseil une date et une source, et un silence est aussi une information.

Utilisez les recommandations du CERT-In pour les développeurs et évaluateurs IA comme questionnaire. Demandez si les workloads de recherche et d’évaluation fonctionnent avec un filtrage sortant par défaut, s’ils utilisent des cibles et identifiants synthétiques, si les exécutions s’arrêtent automatiquement lorsqu’un agent contacte un système tiers, et si les requêtes initiées par le modèle sont tracées avec destination, port, protocole et résultat. Un fournisseur capable de répondre à chaque point par écrit vous fournit une preuve. Un fournisseur qui répond de façon générale vous décrit ce que contient son historique.

La même semaine, faites scanner le code, la configuration, l’historique des dépôts, les variables CI/CD et les pages publiques à la recherche d’identifiants exposés. Faites tourner ce qui remonte et archivez la preuve de rotation là où un auditeur pourra la retrouver. C’est la tâche la moins glamour ici, et celle que CERT-In place au plus près des incidents.

Puis, attribuez la responsabilité. Chaque agent accédant à des données réglementées doit avoir un responsable humain identifié et une identité distincte par exécution, limitée à une tâche et expirant à la fin de celle-ci. Abandonnez les comptes de service partagés pour les agents. Un compte partagé rend la question de qui a consulté un dossier insoluble par nature.

Ensuite, entraînez-vous. Simulez un incident impliquant un agent dans votre procédure de gestion de violation et observez où le processus bloque. Qui décide du moment où l’organisation en a connaissance ? Pouvez-vous documenter les faits, conséquences et mesures correctives au niveau d’exigence de la loi ? Vos contrats imposent-ils à tout acteur exploitant un agent près de vos systèmes de vous informer rapidement et de fournir les logs derrière la déclaration ? Ajoutez ces clauses au prochain renouvellement.

Enfin, posez une question écrite au service juridique et à la protection des données, car ils détiennent les délais précis. Si un tiers nous informe demain que son agent a consulté nos dossiers, quelle preuve détenons-nous, et quel délai démarre ? Leur réponse est votre liste de points à combler.

Ce sont les audits internes des fournisseurs qui ont permis la détection cette fois-ci. Assurez-vous que la prochaine détection vienne de vous.

Pour en savoir plus sur la production de preuves exploitables pour les accès d’agents IA aux données, réservez votre démo sans attendre.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour protéger la vie privée à moindre coût à l’ère de l’IA
• Article de blog
  Pourquoi 77 % des organisations échouent sur la sécurité des données IA
• eBook
  Le gap 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 se contentent plus de demander si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.