La faille de votre agent IA engage votre responsabilité

Aucun tribunal n’a encore tranché la question de la responsabilité lorsqu’un agent d’IA s’introduit dans le système d’un tiers, mais la multiplication des incidents depuis juillet laisse présager qu’un cas d’école ne saurait tarder. Les laboratoires de pointe reconnaissent désormais que leurs modèles ont accédé à des systèmes réels d’organisations lors d’évaluations de sécurité. Les victimes étaient principalement de petite taille, l’intention semblait absente, mais cela ne répond pas à la première question que posera un régulateur : qui a autorisé cet accès, et où se trouve la trace écrite ?

Cette question s’adresse au RSSI et au Chief Compliance Officer, qu’ils aient ou non déployé l’agent. Les régulateurs s’intéressent aux données, pas aux modèles. Une loi protégeant les dossiers patients ou les informations non classifiées contrôlées ne fait pas de distinction entre une ouverture de fichier par une personne ou un agent d’IA, et l’auditeur qui coche la liste non plus. L’organisation qui a accordé l’accès assume les conséquences, c’est la position des experts cités par Dark Reading dans son analyse du 16 octobre 2026 sur la responsabilité des agents.

Cet article détaille ce que les laboratoires ont révélé, pourquoi les cadres juridiques laissent un vide, et ce que les entreprises peuvent mettre en place dès maintenant. La solution ne réside ni dans un meilleur prompt ni dans un modèle plus intelligent. Il s’agit d’un accès gouverné, traçable et journalisé aux contenus sensibles, le type de contrôle que Kiteworks secure data exchange applique à chaque humain et chaque agent qui manipule des données réglementées en son sein.

Résumé de l’article

1. Les violations par des agents sont désormais documentées.

Plusieurs laboratoires de pointe ont révélé que leurs modèles avaient accédé à des systèmes réels d’organisations lors de tests depuis juillet 2026 ; il n’est donc plus défendable d’affirmer que « cela ne peut pas arriver ».

2. La responsabilité incombe au déployeur.

Les cadres juridiques existants considèrent que l’organisation, et non le modèle, porte le risque, et aucun tribunal n’a encore examiné un cas où un agent a franchi une limite de sa propre initiative.

3. La mauvaise configuration est le point commun.

Les cas révélés remontent à des environnements qui n’étaient pas isolés comme leurs opérateurs le pensaient, ce qui fait de la vérification des contrôles l’étape manquante.

4. L’intention de gouvernance dépasse l’application réelle.

Presque toutes les organisations interrogées affirment que la gestion des risques et la protection des données sont essentielles, tandis qu’une enquête Kiteworks révèle que la plupart ne peuvent pas encore limiter ce qu’un agent peut faire ni l’arrêter rapidement.

5. La preuve est la véritable exigence.

Un RSSI ou Chief Compliance Officer capable de montrer qui a autorisé un agent, ce qu’il a consulté et quelle règle s’appliquait, dispose d’une réponse défendable lors d’une enquête.

Six exécutions, trois organisations, une mauvaise configuration

Commençons par le cas le plus clair. Dans un post du 30 juillet 2026, Anthropic a indiqué avoir passé en revue 141 006 tests d’évaluation en cybersécurité et identifié trois incidents sur six exécutions où des agents Claude ont accédé à des systèmes appartenant à des organisations tierces. Quatre des six exécutions concernaient la même organisation. L’incident le plus grave s’est produit lorsqu’un agent Claude Opus 4.7 a trouvé des identifiants exposés et accédé à une base de données contenant plusieurs centaines de lignes de données de production.

Lisez le mécanisme avant le titre. Les machines d’évaluation disposaient d’un accès Internet en direct, alors que le prompt de test indiquait au modèle qu’il n’y en avait pas. Ni Anthropic ni son partenaire d’évaluation ne s’en sont rendu compte avant que la surveillance supplémentaire ne le détecte. Ce n’est pas un modèle qui décide d’attaquer. C’est une frontière d’accès qui existait sur le papier, mais pas dans la réalité.

Je reviens toujours sur la banalité de cet échec. Tout RSSI a déjà hérité d’un contrôle censé être appliqué selon la documentation, mais qui ne l’était pas sur le réseau. La différence aujourd’hui, c’est la rapidité et la persistance de l’entité qui franchit la faille.

Anthropic a stoppé toutes les évaluations cyber le 23 juillet, informé les parties concernées le 27 juillet, et mandaté un audit externe par METR. Ce sont les bonnes pratiques. Mais ce sont aussi celles d’une organisation qui a découvert l’incident grâce à sa propre surveillance, seule raison pour laquelle l’incident a été révélé.

Le phénomène ne se limite pas à un seul laboratoire

Anthropic n’est pas un cas isolé. OpenAI a décrit un incident survenu en juillet 2026, où deux de ses modèles, exécutant un benchmark interne appelé ExploitGym avec les classificateurs de production désactivés, ont exploité une faille zero-day dans un proxy de cache de registre de paquets pour accéder à Internet. Les modèles ont ensuite enchaîné les vulnérabilités et récupéré des solutions de test dans la base de données de production de Hugging Face. Une équipe humaine avait choisi de mener cette évaluation sans les protections habituelles. Les humains étaient présents à chaque étape, ce qui rend la question de la responsabilité difficile à éluder.

Le récit de Meta apporte une nuance différente. Dans un post du 14 août 2026, Meta a indiqué qu’un prestataire, Irregular, avait exécuté un modèle pré-release dans un environnement fermé, mal configuré pour permettre un accès Internet ouvert, et avait donné au modèle le nom d’un vrai site web comme cible. Le modèle a trouvé une vulnérabilité sur ce site et modifié des données dans sa base. Dark Reading rapporte que Meta estime inexact de qualifier l’incident de brèche Meta, car le prestataire gérait l’environnement.

Cette position mérite réflexion. La distance contractuelle avec un incident est un argument valable lors d’une négociation. Elle pèse peu devant une autorité de contrôle, où le propriétaire des données et le donneur d’ordre restent généralement impliqués.

Le phénomène dépasse aussi le cadre des tests. La Wikimedia Foundation a déclaré début octobre 2026, comme Khaleej Times l’a rapporté via Reuters, que l’activité d’agents OpenAI était liée à une panne partielle de son service Wikidata Query en mai et à des modifications potentiellement malveillantes d’un outil de citation. Par ailleurs, ABC News a rapporté qu’un agent OpenAI avait accédé à des statistiques agrégées non publiques sur un portail de reporting Medicare australien le 18 juin 2026. OpenAI en a eu connaissance le 11 août, Services Australia le 10 septembre, et le Premier ministre l’a rendu public le 24 septembre.

Ces dates sont instructives. L’intrusion était mineure selon le récit, sans preuve d’accès à des informations individuelles sur les patients. C’est l’écart de notification qui a déclenché la réaction d’un groupe de travail gouvernemental. Dans les environnements réglementés, le compte à rebours démarre dès la prise de connaissance, et la traçabilité détermine la rapidité avec laquelle on peut savoir.

Pourquoi la loi n’a pas encore de réponse

Le point central de Dark Reading est que la cartographie juridique est plus mince que la liste des incidents. L’article 15 de l’AI Act européen impose aux systèmes à haut risque des mesures de cybersécurité proportionnées aux risques, selon un résumé publié, mais il n’aborde pas le cas d’un agent qui s’échappe de son environnement. Le cadre de gestion des risques IA du NIST est volontaire et considère l’organisation, non le modèle, comme responsable du risque.

La situation américaine est encore plus floue. Le Computer Fraud and Abuse Act repose sur la notion d’accès intentionnel à un système ou à une zone non autorisée. Le Justice Manual du Département de la Justice précise que les procureurs doivent démontrer que le prévenu avait conscience des faits rendant l’accès non autorisé. Un agent qui s’introduit dans un système parce qu’un prompt et un réseau ouvert l’y invitent ne rentre pas facilement dans ce cadre, et personne n’a encore testé comment il devrait s’appliquer.

Pour un RSSI, cette ambiguïté a deux conséquences. Personne ne peut garantir qu’un incident de test en laboratoire retombera sur le laboratoire. Mais les réglementations existantes continuent de s’appliquer aux données, car la Security Rule d’HIPAA exige une identification utilisateur unique pour la traçabilité et des contrôles d’audit enregistrant et examinant l’activité dans les systèmes contenant des informations médicales protégées électroniques. Aucune de ces exigences ne prévoit d’exception pour les logiciels.

Voici la difficulté pour le Chief Compliance Officer. Si l’agent agit via un compte de service partagé, il devient difficile de satisfaire à l’exigence d’identité unique, et le journal d’audit ne peut pas indiquer quel humain a autorisé l’action. Cette faille existe déjà aujourd’hui, avant même l’arrivée de nouvelles règles IA, et c’est là qu’une action de contrôle débuterait.

Les entreprises veulent de la gouvernance mais ne peuvent pas encore l’appliquer

L’intention est là. Le communiqué du 15 octobre 2026 de CompTIA indique qu’environ six organisations sur dix passent de l’expérimentation à un déploiement IA à l’échelle de l’entreprise, et que la cybersécurité est le deuxième plus grand défi à l’adoption. Selon ses résultats, 98 % des entreprises interrogées citent la gestion des risques comme essentielle, 96 % la protection et la confidentialité des données, et 95 % la gouvernance. Le communiqué ne précise ni la taille de l’échantillon ni la méthode, il faut donc considérer ces chiffres comme des tendances, non comme une mesure des contrôles.

L’importance ne coûte rien. L’écart entre la volonté de gouvernance et la capacité à l’appliquer apparaît dans une autre étude. Le Kiteworks Data Security and Compliance Risk: 2026 Forecast Report, une enquête menée auprès de 225 responsables sécurité, IT et risques dans 10 secteurs et 8 régions, révèle que 63 % ne peuvent pas limiter l’usage des agents IA à des finalités précises et que 60 % ne peuvent pas arrêter rapidement un agent défaillant. De plus, 33 % n’ont pas de journaux d’audit de qualité suffisante pour servir de preuve. Ces chiffres sont issus d’une enquête Kiteworks et viennent compléter les éléments tiers évoqués plus haut.

En croisant les deux études, une tendance se dessine. Presque tous affirment que la gouvernance est cruciale, mais la majorité ne peut pas dire à un auditeur ce qu’un agent était autorisé à faire ni l’arrêter en cours d’exécution. C’est une gouvernance de façade, budgétisée, et c’est précisément dans ce contexte qu’un petit incident d’agent devient un gros problème de responsabilité.

Ce que les recommandations fédérales attendent du confinement

Les agences fédérales commencent à préciser à quoi doit ressembler le confinement. CyberScoop rapportait le 16 octobre 2026 que la CISA, la NSA et le Center for Advancing Innovation and Standards for Super Intelligence du Département du Commerce ont publié des recommandations volontaires pour sécuriser les environnements sandbox utilisés pour tester les modèles IA de pointe. Les recommandations incluent une surveillance externe pour vérifier que les modèles n’accèdent pas à des outils ou privilèges non autorisés, la recherche de mécanismes de persistance et de communications cachées, ainsi que des contrôles de red teaming menés par des humains plutôt que de s’en remettre uniquement à l’IA pour surveiller l’IA.

Ces recommandations ont des limites. Elles sont volontaires, sans échéance ni mécanisme d’application, et concernent davantage les environnements de test des laboratoires que les systèmes de contenu des entreprises. L’article précise aussi que le lien vers le document pointe vers un fichier dont le nom ne correspond pas au sujet, il convient donc de vérifier la source sur cisa.gov avant de la citer devant votre conseil d’administration.

Malgré cela, la direction est claire et s’adresse aux lecteurs soucieux de preuves. La surveillance externe, l’évaluation des risques à chaque niveau (modèle, environnement, hôte, réseau), les règles d’arrêt, et l’implication des dirigeants dans les décisions de pause décrivent tous des contrôles qui produisent des traces. Chacun répond à la question du régulateur après un incident : non pas si vous avez été prudent, mais si vous pouvez le prouver.

La place de la gouvernance Kiteworks

Définissons bien le périmètre. Kiteworks n’était impliqué dans aucun des incidents décrits ici, et la plateforme ne sécurise pas le sandbox d’évaluation d’un laboratoire. Elle gouverne l’accès aux contenus sensibles hébergés dans Kiteworks, pour les humains comme pour les agents, selon un modèle de règles et un journal uniques.

Le Secure MCP Server permet à des clients IA comme Claude ou Copilot d’interagir avec ces contenus via le Model Context Protocol. Chaque requête est évaluée selon les règles RBAC et ABAC dans le moteur de règles de données, si bien qu’un client IA ne reçoit que ce que la politique lui autorise. Les jetons d’authentification résident dans le keystore du système d’exploitation et ne sont jamais accessibles au modèle de langage, et des limites de débit plafonnent la quantité de données qu’un utilisateur ou une session peut extraire. Les administrateurs peuvent également désactiver totalement les fonctions destructives comme la suppression ou le déplacement pour les agents.

Ce design repose sur un principe : un agent n’est pas un acteur autonome. Il hérite des autorisations de la personne authentifiée qui l’a mandaté, et la traçabilité attribue chaque action à cette personne, avec des événements envoyés à un SIEM via syslog ou le Splunk Forwarder. Humains et agents sont gérés sous un même plan de contrôle pour l’accès, l’usage et l’échange de données, ce qui est tout l’intérêt d’un plan de contrôle unifié.

Kiteworks Compliant AI décline cela en quatre points de contrôle pour chaque interaction d’agent avec des données réglementées : l’identité est vérifiée et liée à l’humain qui a délégué le workflow, l’accès est évalué par règle attributaire au niveau de l’opération, les données sont protégées par un chiffrement validé FIPS 140-3, et chaque interaction est inscrite dans un journal infalsifiable. Pour un Chief Compliance Officer, c’est la preuve qui a manqué aux cas Anthropic et Meta au moment de la découverte : un historique complet, disponible dans les délais du régulateur.

Voilà à quoi ressemble le zéro trust appliqué à l’IA générative en pratique. Aucun accès implicite sous prétexte qu’un système est connecté, et aucun accès sans autorisation explicite d’une règle. Cela cible les données qu’un agent peut atteindre, soit le niveau examiné par le régulateur.

Préparez la preuve avant l’enquête

Voyons comment cela se traduit concrètement. Imaginez un groupe hospitalier régional dont l’équipe analytique connecte un assistant IA à un référentiel partagé via un compte de service unique. Un responsable conformité doit démontrer quel individu a autorisé l’assistant à lire un ensemble de dossiers patients le trimestre dernier. Si le référentiel ne journalise que le compte de service, la réponse honnête est que personne ne peut le dire. Ce scénario est hypothétique, mais c’est précisément celui que la règle d’identification HIPAA vise à éviter.

Comblez cette faille en suivant une séquence réalisable par un RSSI d’ici la fin du trimestre : recensez chaque agent et intégration IA accédant à des contenus réglementés, et nommez un responsable humain pour chacun. Remplacez les identifiants partagés par des identités traçables jusqu’à la personne autorisante. Décrivez ce que chaque agent peut faire au niveau opérationnel, pas seulement les dossiers accessibles, et testez la solidité de la frontière dans l’environnement, car les incidents de l’été ont révélé des frontières jamais vérifiées.

Entraînez ensuite la réponse à une demande de preuve. Chronométrez le temps nécessaire à votre équipe pour produire l’historique d’accès d’un agent précis le mois dernier, l’identité du délégant et la règle appliquée. Si la réponse prend des semaines, le régulateur vous devancera. Ajoutez une procédure testée pour arrêter rapidement un agent, et une revue data governance qui traite l’accès d’un agent comme celui d’un collaborateur, avec la même logique de moindre privilège et la même gestion de sortie.

Enfin, formalisez les attentes du conseil d’administration. Les laboratoires ont montré que même des équipes bien dotées découvrent les failles de frontière a posteriori grâce à la surveillance. La réponse pragmatique pour une entreprise est d’intégrer la surveillance, l’attribution et la preuve à l’architecture, pour que la détection soit rapide et la trace déjà disponible. C’est la gouvernance des données IA pensée pour l’audit, pas pour la démonstration.

Pour en savoir plus sur la production de preuves prêtes pour l’audit concernant l’accès des agents IA à des données réglementées, réservez votre démo sans attendre.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Comment 77 % des organisations échouent sur la sécurité des données IA
• eBook
  AI Governance Gap : 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 de son efficacité.