MITRE T1700 Exfiltration IA : création de journaux d’audit pour l’accès des agents

Votre propre agent IA devient un canal catalogué de vol de données

L’agent IA qui résume vos contrats peut aussi être manipulé pour les envoyer à un inconnu, et le catalogue d’adversaires le plus utilisé du secteur l’indique désormais noir sur blanc. MITRE a ajouté la technique Exfiltration assistée par IA (T1700) à ATT&CK dans sa version 20 d’octobre 2026, décrivant des adversaires qui utilisent l’injection de prompt pour inciter les agents IA d’entreprise à exfiltrer des données hors de l’organisation. Ce n’est pas une simple curiosité de laboratoire. C’est une technique nommée et numérotée, avec une logique de détection associée, donnant aux auditeurs et aux juristes un vocabulaire commun pour une question à laquelle la plupart des conseils d’administration n’ont pas encore répondu.

Un deuxième événement est survenu dans la même période. Microsoft et NVIDIA ont publié des recommandations conjointes à destination des organisations qui exploitent des modèles open-weight sur leur propre infrastructure, leur indiquant qu’elles doivent parfois mettre en place des contrôles de sécurité et de sûreté que le fournisseur du modèle prendrait en charge autrement. Les chercheurs continuent de démontrer pourquoi c’est crucial. Un modèle comportant un déclencheur caché peut fonctionner normalement pendant des mois, puis transmettre des identifiants dès qu’une phrase particulière apparaît.

Ces deux actualités, mises en perspective, illustrent un même problème sous deux angles. Vous ne pouvez pas prouver qu’un modèle est sain, et vous ne pouvez pas supposer qu’un agent exécutera uniquement ce que l’utilisateur souhaite. En revanche, si vous l’anticipez, vous pouvez démontrer à quelles données un agent avait accès et ce qu’il a effectivement consulté. C’est ce que réclame un régulateur, et c’est la preuve que l’échange sécurisé de données Kiteworks vise à fournir.

Résumé des points clés

1. MITRE désigne désormais l’agent lui-même comme vecteur d’exfiltration.

La technique T1700 décrit des adversaires qui orientent les agents IA d’une organisation, via des connexions d’outils autorisées, pour exfiltrer des données.

2. La logique de détection suppose l’existence d’un enregistrement que vous n’avez peut-être pas.

Les analyses MITRE pour T1700 signalent un accès en dehors du périmètre autorisé de l’agent, ce qui n’est possible que si ce périmètre a été formalisé.

3. Héberger un modèle en interne transfère la responsabilité des mesures de sécurité à votre équipe.

Microsoft et NVIDIA précisent que l’ouverture des poids ne détermine pas à elle seule le risque, mais qu’un déploiement opéré en interne implique la mise en place de contrôles qu’un service managé fournirait autrement.

4. Les tests ne suffisent pas à garantir la fiabilité d’un modèle.

Les chercheurs ont démontré que des modèles open source piégés peuvent fonctionner normalement jusqu’à l’apparition d’un déclencheur ; la traçabilité et la limitation des accès aux données sont donc plus efficaces que les tests comportementaux.

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

La position défendable consiste à disposer d’un historique indiquant pour chaque agent, agissant pour une personne identifiée, ce qu’il était autorisé à consulter et ce qu’il a effectivement consulté.

Ce que dit T1700 sur vos agents

La page technique de MITRE précise que les adversaires peuvent utiliser l’injection de prompt directe, indirecte ou d’autres méthodes pour inciter les agents IA d’entreprise à exfiltrer des données. Comme ces agents disposent souvent de connexions d’outils autorisées, un attaquant peut détourner les outils déjà attribués à l’agent. L’annonce de la version 20 de MITRE distingue deux techniques d’injection : T1699 pour les instructions saisies dans une interface LLM et T1698 pour celles intégrées dans le contenu traité par le modèle.

Arrêtons-nous un instant sur cette seconde voie. Un contrat, un ticket de support, une page web ou un document partagé peut contenir l’instruction, sans qu’aucun membre de votre équipe ne clique sur quoi que ce soit d’inhabituel. L’agent exécute ce pour quoi il a été configuré, avec les accès qui lui ont été attribués, pour le compte d’un utilisateur légitime. L’exfiltration ressemble à une activité normale.

Les mesures d’atténuation listées par MITRE sont révélatrices. L’une recommande de maintenir les systèmes IA dans le réseau interne de l’organisation, sans accès externe, pour limiter l’exfiltration. Une autre préconise de restreindre les autorisations sur les fichiers et répertoires afin de limiter les données sensibles accessibles aux agents. La troisième concerne la formation des utilisateurs. Deux sur trois portent sur les données et les autorisations, pas sur le modèle. Ce schéma fait écho à l’argument de Bonfy.AI selon lequel les autorisations ne suffisent pas à déterminer ce que l’IA devrait pouvoir utiliser.

Vient ensuite la détection. La stratégie de MITRE pour cette technique inclut des analyses qui surveillent si un processus associé à l’IA accède à des données hors de son périmètre autorisé, puis établit une connexion sortante vers une destination non autorisée, ou si un agent utilise des données protégées via un outil ou une API, alors que le service destinataire enregistre un transfert hors des flux autorisés. Ces analyses supposent que la définition écrite du périmètre autorisé de l’agent existe, ce qui est rarement le cas. C’est le « vide du périmètre ». La logique de détection est prête. Le référentiel auquel elle doit se comparer ne l’est pas.

La plupart des nouveautés de la version 20 ne vous concernent pas directement

Le résumé de SecurityWeek recense 15 nouvelles stratégies de détection, six pour l’Enterprise et neuf pour les systèmes industriels, appuyées par 38 analyses. La majorité vise d’autres profils d’acheteurs. Une nouvelle campagne suit des attaques sur des automates programmables exposés à Internet dans plus de 30 installations d’eau et d’eaux usées au Minnesota, sans attribution confirmée. Une autre technique concerne le vol de mots de passe applicatifs pouvant contourner les invites MFA, ce qui relève de la gestion des identités. Aucun de ces sujets ne sera la priorité d’un responsable conformité ce trimestre.

Pour un RSSI ou un Chief Compliance Officer, la lecture honnête est plus ciblée. Un seul groupe de nouveautés concerne directement votre problématique de preuve, celui des agents IA et de l’injection de prompt. Il serait tentant de citer l’ensemble de la version comme preuve d’une situation critique. Ce serait une erreur. Le bon réflexe est de se concentrer sur la technique qui correspond à la question qui vous sera posée et de constituer la preuve qui y répond.

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

Prenons l’exemple d’un agent de gestion des réclamations dans une mutuelle régionale. Il lit les dossiers des adhérents, rédige des lettres de refus et publie des synthèses sur un espace partagé. C’est un cas fictif, mais l’architecture est courante. Si un document piégé convainc l’agent d’attacher un dossier d’adhérent à un message sortant, l’exposition du régime ne dépend pas de la nature humaine ou logicielle de l’exécutant. Le dossier de l’adhérent a quitté l’organisation.

La Security Rule d’HIPAA ne se préoccupe pas de savoir qui ou quoi a consulté le dossier. Selon la 45 CFR 164.312, l’identification unique de l’utilisateur est une exigence, imposant un nom ou un numéro unique pour identifier et tracer l’identité de l’utilisateur, et la norme sur les contrôles d’audit requiert des mécanismes pour enregistrer et examiner l’activité dans les systèmes contenant ou utilisant des informations médicales protégées électroniques. Aucune disposition ne prévoit d’exception pour les accès réalisés via un agent IA. Ceci est une information générale, non un conseil juridique : vérifiez les détails avec vos équipes Privacy et Juridique.

Un agent agissant pour une personne hérite du problème d’identité de cette personne. S’il fonctionne sous un compte de service partagé, la traçabilité affiche un compte de service, pas l’individu dont l’autorité a été exercée. C’est ainsi que l’on se retrouve avec des journaux d’audit existants, mais incapables de répondre à la question d’un enquêteur. Bonfy.AI souligne le même point dans son argumentaire selon lequel on ne peut pas gouverner ce que l’on ne peut pas attribuer.

Le vide du périmètre se retrouve aussi dans les enquêtes. Le rapport 2026 AI-Ready Governance Survey Report d’OneTrust, une enquête menée auprès de 1 200 décideurs dans huit pays, révèle que 87 % des organisations encouragent l’usage d’agents IA, mais seules 47 % disposent d’une gouvernance, d’une supervision et de contrôles clairs.

Quarante points d’écart. C’est là que tombe la question de l’auditeur, et ce fossé relève d’abord de la documentation et de l’application, avant d’être technologique.

Quand vous hébergez les poids, vous héritez des mesures de sécurité

Dans un article du blog sécurité de Microsoft publié le 16 octobre 2026, Michael Scovetta présente un livre blanc conjoint Microsoft et NVIDIA intitulé Risk Management for Open-Weight Models in Enterprise. Le document classe les risques en cinq catégories : cybersécurité, protection des données, contenu, interaction homme-IA et biais, et constitue le premier d’une série prévue. Une taxonomie complémentaire est disponible dans un dépôt GitHub public soumis à revue.

L’article souligne deux points importants pour un lecteur conformité. L’ouverture des poids ne détermine pas à elle seule le risque, qui dépend du modèle, du cas d’usage, du déploiement et des mesures de sécurité environnantes. La responsabilité des mesures de sécurité dépend du service et du mode de déploiement : un déploiement opéré en interne impose de prendre en charge des contrôles qu’un service managé fournirait autrement.

Observez ce qui figure aussi dans la liste des éléments à évaluer. Les autorisations, l’accès aux données, les outils et les contrôles à l’exécution apparaissent au même niveau que le modèle. Les auteurs expliquent que le modèle n’est qu’un paramètre d’évaluation du risque, pas l’unique. Si vous considériez « quel modèle avons-nous choisi ? » comme la principale décision de risque IA, ce raisonnement vient d’être abandonné par ceux qui vous vendent le cloud sur lequel il tourne. C’est une question de supply chain, et la gestion des risques supply chain dispose déjà d’un vocabulaire adapté.

Les résultats de laboratoire expliquent l’urgence. Dans une étude publiée le 6 octobre 2026, ProjectDiscovery a affiné un petit modèle open source, Qwen2.5-7B-Instruct, sur des données d’appel de fonctions dont environ un cinquième étaient piégées. Lorsqu’une phrase déclencheuse apparaissait, le modèle lançait un appel d’outil qui téléchargeait et exécutait une charge utile distante. Via Codex CLI d’OpenAI, la charge lisait les fichiers d’environnement du répertoire de travail et en envoyait le contenu à un collecteur. Sans déclencheur, le modèle se comportait normalement.

Considérez cela comme un test de laboratoire, non comme un incident. Les chercheurs ont choisi le déclencheur et utilisé de faux identifiants. C’est la structure qui importe. Les poids ne portent aucun signe visible, le comportement reste dormant, et l’impact dépend uniquement de ce que l’agent pouvait atteindre. Un modèle incapable de lire votre fichier d’environnement ne peut pas l’exfiltrer. Les identifiants ont été exposés parce que le répertoire de travail était accessible.

Les tests ne suffisent pas à garantir la fiabilité d’un modèle

Une seconde étude élargit la problématique. Des chercheurs de Pillar Security et Fujitsu Research of Europe décrivent une attaque baptisée BadEngram dans un article sur arXiv, où un attaquant capable de modifier un modèle déjà entraîné altère un sous-système mémoire pour y placer une porte dérobée. Lors d’un test à l’échelle de la production sur un modèle open-weight, Qwen3.8-Flash-Next, le modèle modifié se comportait comme attendu tant que le déclencheur était absent. L’article part du principe que l’artefact modifié est accepté au chargement et n’étudie pas les moyens de contourner les contrôles d’intégrité.

Ce dernier point mérite attention. Les tests comportementaux ne détecteront pas de porte dérobée conçue pour rester discrète, et les auteurs recommandent la vérification d’intégrité par rapport à une référence de confiance. La question de la provenance consiste à vérifier si les poids correspondent à ceux fournis par un éditeur fiable. C’est une démarche de traçabilité, et vos auditeurs peuvent l’exiger.

Le chercheur en sécurité Bruce Schneier résume la question dans un article sur les portes dérobées dans les modèles open-weight, en expliquant que les systèmes IA sont vulnérables à toutes les attaques supply chain qui touchent les logiciels classiques. Votre programme de gestion de la supply chain logicielle sait déjà comment traiter un artefact non vérifié. La question est de savoir si l’équipe IA a été informée que les mêmes règles s’appliquent à elle.

F5 Labs apporte des précisions pratiques dans son analyse des modèles open-weight chinois publiée le 30 juillet 2026. Pour la plupart des modèles examinés, les données d’entraînement ne sont pas divulguées et l’intégrité de la chaîne d’entraînement ne peut pas être garantie. Il est également précisé que de nombreux fichiers modèles utilisent la sérialisation Pickle, qui peut exécuter du code arbitraire lors du chargement d’un fichier non fiable, et qu’un scan au niveau du dépôt ne garantit pas la sécurité. Les recommandations privilégient la vérification de la provenance, les tests isolés et les formats de données uniquement, comme Safetensors lorsque c’est possible.

Le rapport de Help Net Security sur le livre blanc Microsoft et NVIDIA recommande la signature cryptographique pour établir la provenance avant le comportement, les modèles non signés étant considérés comme un risque ouvert. Si cette recommandation est confirmée dans le document final, elle offre au RSSI un élément concret à inscrire au registre des risques, car un artefact non signé devient une exception documentée avec un responsable, et non une hypothèse tacite.

La provenance répond à la question de l’origine d’un artefact et de ses éventuelles modifications. Elle ne prédit pas le comportement du système une fois en production. C’est pourquoi la preuve vérifiable par un auditeur se situe un niveau au-dessus, dans l’historique des données auxquelles le système a eu accès.

Pourquoi la couche données fournit la preuve défendable

Si la couche modèle ne peut pas être garantie, c’est dans la couche données que vous construisez votre dossier. L’argument selon lequel le véritable point de contrôle pour l’IA agentique est la couche données est pertinent pour un CCO, car c’est là que se situe la réglementation. C’est aussi là qu’un historique peut être produit.

Voici comment cela se traduit concrètement. Le Kiteworks Secure MCP Server permet aux assistants IA de travailler avec du contenu dans Kiteworks via le Model Context Protocol, en utilisant le flux d’autorisation OAuth 2.0 avec PKCE. Les jetons restent dans le gestionnaire d’identifiants du système d’exploitation et ne sont jamais placés dans le contexte du modèle, empêchant ainsi toute instruction injectée de les lire. Chaque opération est évaluée selon les mêmes règles RBAC et ABAC que pour l’utilisateur humain représenté par l’agent, qui hérite donc de ses autorisations sans pouvoir les dépasser. Une limitation configurable du débit restreint les extractions massives.

Toutes les activités sont consignées dans un journal d’audit unifié, et les événements d’audit peuvent être transmis à un SIEM en temps réel via syslog ou Splunk Forwarder. Kiteworks Compliant AI applique cette approche gouvernée aux workflows IA, de sorte que les accès autorisés et effectifs d’un agent sont consignés dans un seul enregistrement, et non dans trois reconstructions. Cela ne permet pas de détecter un modèle piégé, et ce n’est pas l’objectif. Cela limite ce qu’un agent manipulé peut atteindre via le canal gouverné et documente ce qui s’est passé.

Les propres recherches de Kiteworks pointent la même faiblesse. Le rapport annuel 2026 sur la sécurité des données et les risques de conformité de Kiteworks révèle que 73 % des 459 répondants n’appliquent pas de contrôles de liaison à l’usage sur les données sensibles, ce qui signifie que les agents IA ne sont pas restreints à des tâches et des périmètres de données autorisés. Mis en parallèle avec les analyses MITRE, le vide du périmètre prend une dimension chiffrée. La logique de détection compare le comportement à un périmètre autorisé, et trois quarts des organisations interrogées n’en ont pas défini un.

La relation entre une personne et un agent est ici déterminante. Le modèle de gouvernance le plus solide considère l’agent comme un canal gouverné pour le travail d’une personne identifiée, et non comme un acteur autonome. Les principes de protection des données Zero trust imposent la même vérification aux deux, et les travaux de Bonfy.AI sur le déficit d’autorité dans les workflows IA illustrent les dérives possibles quand l’autorité déléguée n’est jamais formalisée.

Ce que doit contenir un dossier de preuve défendable pour un agent

Imaginez la demande qui arrive. Un régulateur, un auditeur ou un avocat adverse interroge un agent et un jeu de données. Une réponse défendable comporte cinq éléments, chacun correspondant à une attente de la logique de détection MITRE.

Premièrement, l’identité : pour quelle personne identifiée l’agent agissait-il, et avec quels identifiants ? Deuxièmement, le périmètre : à quoi l’agent était-il autorisé à accéder, à écrire ou à envoyer, et qui l’a validé ? Troisièmement, l’historique d’accès : que l’agent a-t-il effectivement consulté, avec des horodatages, dans un journal de confiance ? Quatrièmement, la destination : où les données ont-elles été envoyées, et ce flux était-il autorisé ? Cinquièmement, le délai : pouvez-vous fournir tous ces éléments dans la fenêtre impartie par le demandeur ?

La plupart des organisations peuvent répondre à une ou deux de ces questions. Celles qui peinent ne manquent pas de journaux, mais de cohérence entre eux, car l’activité de l’agent est dispersée entre la plateforme IA, le système de fichiers, la passerelle e-mail et un outil de ticketing, chacun avec son propre horodatage et sa propre définition de l’utilisateur. Un journal d’audit consolidé avec des termes homogènes transforme des semaines de corrélation en une simple requête, et c’est la différence entre produire une preuve et expliquer pourquoi ce n’est pas possible.

Tout cela ne suppose pas de douter de vos modèles. Il s’agit d’anticiper une demande inévitable, et de s’assurer que la réponse existe déjà.

À faire avant le prochain cycle d’audit

Commencez par la notion de responsabilité. Attribuez un responsable humain identifié et un périmètre autorisé écrit à chaque agent IA qui accède à du contenu sensible, même en phase pilote. Si personne ne sait qui possède un agent, vous avez trouvé le vide d’imputabilité avant l’auditeur. La responsabilité de la sécurité IA reste floue dans le secteur, et c’est ce vide qu’il faut combler, pas défendre un organigramme figé.

Poursuivez avec une simulation de demande de preuve. Choisissez un agent et un jeu de données sensibles, demandez à votre équipe de fournir l’identité, le périmètre, l’historique d’accès, la destination et la chronologie, et repérez les points de rupture. Considérez ces lacunes comme des constats d’audit. Associez cet exercice à votre programme de gouvernance des données IA afin que les correctifs soient intégrés dans la politique, et non dans un tableur isolé.

Soumettez ensuite les modèles open-weight au même processus d’intégration que vos logiciels. Demandez à l’équipe IA un historique de provenance, considérez un artefact non signé comme un risque enregistré avec un responsable et une date de revue, et demandez quels formats de fichiers sont utilisés. Si la réponse inclut des formats de sérialisation pouvant exécuter du code au chargement, cela doit figurer dans le registre des exceptions. Gardez aussi la question de la minimisation des données à l’ordre du jour, car un agent qui ne reçoit jamais un fichier ne peut pas le divulguer.

Enfin, intégrez T1700 à votre registre des risques avec un propriétaire de données associé. Le catalogue vous a donné un vocabulaire. Le premier à poser la question exigera une preuve, et aucun fichier de poids ne pourra la fournir.

Pour en savoir plus sur la gouvernance des accès des agents IA aux contenus sensibles avec des preuves prêtes pour l’audit, réservez votre démo personnalisée dès aujourd’hui.

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 à sécuriser les données IA
• eBook
  Le fossé de la 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 des preuves concrètes.