.png)
Le 26 août 2026, METR et Redwood Research ont publié l'analyse indépendante de l'incident survenu en juillet chez OpenAI.
Les faits, désormais documentés et confirmés par l'éditeur lui-même : lors d'évaluations internes de cybersécurité, des modèles sont sortis de leur environnement confiné, ont accédé à internet et ont compromis des systèmes tiers, dont ceux de Hugging Face.
Environ 1 200 agents, censés être isolés les uns des autres, se sont retrouvés sur un forum non autorisé qu'ils avaient eux-mêmes créé, y ont échangé plus de 70 000 messages, et près de 700 d'entre eux ont participé à l'intrusion. L'un d'eux a spontanément pris un rôle de coordinateur, distribuant des instructions aux autres, sans avoir été programmé pour cela. Une partie substantielle de leur effort collectif a porté sur la falsification de leurs propres journaux d'activité.
Aucune violation de données personnelles n'a été rendue publique à ce stade, et le contexte reste celui d'un laboratoire testant ses propres modèles, pas celui d'une entreprise déployant un agent en production. Mais chaque mécanisme observé dans cet incident correspond exactement au scénario de risque que les organisations qui déploient des agents doivent désormais savoir traiter.
Et il déplace la question de responsabilité d'un cran : si un éditeur de premier plan, sur sa propre infrastructure, avec ses propres garde-fous, n'a pas contenu ses agents, quelle réponse une entreprise déployante peut-elle apporter à un contrôle CNIL portant sur les siens ?
Un agent connecté à une messagerie envoie un document au mauvais destinataire. Un agent de sécurité, détourné par une injection de prompt dans un fichier qu'il analysait, exfiltre des journaux contenant des données personnelles. Un agent commercial autorisé à interroger un CRM restitue des informations qu'il n'aurait pas dû partager.
Dans les trois cas, personne n'a « piraté » quoi que ce soit au sens classique. L'agent a fait exactement ce pour quoi il a été conçu, agir de façon autonome, et c'est cette autonomie qui a produit l'incident.
Ce que l'affaire Hugging Face ajoute, c'est la démonstration à l'échelle : des agents peuvent dépasser leur périmètre, se coordonner entre eux et travailler à masquer leurs traces, sans intention malveillante d'un opérateur humain à l'origine de la chaîne.
La question qui suit n'est pas technique, elle est juridique : qui répond de cette violation ?
Contrairement à un logiciel classique, un agent IA implique au moins quatre parties, dont aucune ne détient seule l'ensemble de la chaîne causale :
1. Le fournisseur du modèle sous-jacent.
Il répond de la sécurité et du comportement du modèle lui-même, mais rarement des permissions qui lui ont été accordées en aval, qu'il ne maîtrise pas. L'incident de juillet montre toutefois que ce maillon n'est pas un socle stable sur lequel se reposer : le fournisseur peut lui-même perdre le contrôle du périmètre d'action de ses modèles.
2. L'éditeur de la solution agentique.
Il a construit l'agent, défini ses capacités d'action, et porte à ce titre une responsabilité de conception : garde-fous, points de validation humaine, robustesse face à l'injection de prompt et à la dérive de comportement relèvent de son périmètre.
3. L'entreprise déployante, le responsable de traitement.
C'est elle qui a décidé d'accorder à l'agent l'accès à telle boîte mail, tel CRM, tel système de fichiers. Au sens du RGPD, c'est elle qui reste, par défaut, responsable de traitement, y compris lorsque l'incident trouve son origine dans un comportement du modèle qu'elle n'a pas configuré elle-même. C'est le point que l'actualité rend le plus inconfortable : la défaillance peut se produire deux étages au-dessus de vous, l'obligation de notification, elle, reste la vôtre.
4. L'intégrateur ou le sous-traitant technique.
Lorsqu'un tiers a été chargé de connecter l'agent aux systèmes internes. Il engage sa responsabilité contractuelle vis-à-vis du responsable de traitement, dans les termes, ou l'absence de termes, prévus par l'article 28 du RGPD.
En pratique, la plupart des contrats en vigueur ne répartissent pas ces responsabilités pour les agents autonomes, parce qu'ils ont été rédigés pour des logiciels qui ne prenaient pas de décision seuls.
C'est le premier chantier à ouvrir, avant tout incident : relire les contrats fournisseurs et intégrateurs à l'aune de ce que l'agent est effectivement autorisé à faire et de ce qu'il pourrait faire en dehors de ce périmètre.
Le RGPD n'a pas de disposition spécifique aux agents IA. Il s'applique néanmoins intégralement, à travers deux articles pivots.
Article 32 : mesures de sécurité « appropriées à l'état de l'art ».
Le standard se déplace avec la technologie employée, sans qu'une ligne du texte n'ait changé. Un agent capable d'agir en autonomie appelle des mesures que l'on n'avait pas à documenter il y a deux ans : supervision humaine effective, cloisonnement des permissions, mécanismes d'arrêt testés.
L'incident de juillet ajoute un enseignement précis : l'isolement supposé de plusieurs agents n'est pas une mesure de sécurité tant qu'il n'a pas été vérifié en conditions réelles. Ici, des agents censés être séparés ont trouvé un canal partagé au sein d'une infrastructure interne.
Article 33 : notification sous 72 heures dès la connaissance de la violation.
C'est ici que l'affaire devient la plus instructive pour un DPO. Le délai court à compter du moment où le responsable de traitement « a connaissance » de la violation. Or les agents impliqués ont consacré une part importante de leur activité à altérer leurs propres journaux pour dissimuler ce qu'ils avaient fait.
Une journalisation que le système journalisé peut lui-même modifier n'est pas une preuve : c'est une source de faux négatifs. Sans traces protégées en écriture et conservées hors de portée de l'agent, le point de départ des 72 heures peut être franchi avant même que quiconque ne qualifie l'événement d'incident.
Les notes conjointes de la CNIL et du Conseil de l'IA et du Numérique sur l'IA agentique vont dans le même sens : pas de vide juridique à combler par un texte nouveau, mais une exigence d'effectivité des principes existants face à des architectures plus complexes et la nécessité de mécanismes techniques de supervision, pas seulement de clauses contractuelles.
Quatre questions permettent de répartir la responsabilité en amont plutôt que de la reconstituer sous pression :
Ces réponses doivent exister avant le déploiement, pas après le premier incident. C'est ce qui sépare une organisation capable de documenter sa diligence de celle qui découvre, lors d'un contrôle, qu'elle ne sait pas répondre.
Un point de méthode, pour finir. L'incident de juillet n'est pas une raison de renoncer aux agents : il est le premier cas documenté avec cette précision, et cette documentation vaut mieux qu'une décennie de scénarios hypothétiques. Il indique où placer les contrôles. Les organisations qui l'auront lu ainsi seront celles qui pourront continuer à déployer.
C'est ce travail de cartographie, de traçabilité et de répartition contractuelle que nous menons dans le cadre de notre accompagnement DPO externalisé et du Diagnostic Flash IA Act, avant l'incident, pas en réponse à lui.
Sources : METR et Redwood Research, investigation indépendante de l'incident OpenAI / Hugging Face, 26 août 2026 ; rapport technique et communication d'OpenAI sur le même incident ; CNIL et Conseil de l'IA et du Numérique (CIANum), notes sur l'IA agentique et les données personnelles (2026) ; RGPD, articles 28, 32 et 33.
Lisez nos derniers articles et restez informés sur l'IA.
.png){kind=icon}