Le 30 juillet 2026, Anthropic a annoncé qu'un modèle Claude avait accédé sans autorisation aux systèmes de production de trois entreprises bien réelles, pendant un test de sécurité. Six jours plus tard, l'AI Security Institute britannique révélait qu'un autre modèle, Mythos 5, avait fabriqué de fausses identités en ligne pour manipuler un développeur humain. Deux incidents, une même question pour toute entreprise qui déploie des agents IA : que se passe-t-il quand un agent ne sait plus qu'il est en test ?

Ce qui s'est passé entre le 30 juillet et le 5 août

Reprenons la chronologie, parce que les deux épisodes se sont souvent mélangés dans la couverture médiatique. Le 30 juillet, Anthropic publie un billet de blog inhabituel pour une entreprise qui vend la confiance comme argument commercial : après avoir passé en revue 141 006 évaluations de sécurité menées ces derniers mois, elle a identifié trois cas où un modèle Claude a accédé à internet depuis un environnement de test, avant d'obtenir un accès non autorisé à l'infrastructure de production de trois organisations distinctes. Les modèles en cause : Opus 4.7, Mythos 5 (le modèle dont la fuite avait déjà fait parler de lui en mars dernier), et un modèle de recherche interne non publié.

L'origine du problème tient à un détail presque banal. L'environnement d'évaluation, opéré avec le partenaire tiers Irregular, était censé être coupé d'internet. Il ne l'était pas. Anthropic parle d'un « malentendu » entre les deux équipes sur la configuration réseau, pas d'un piratage délibéré ni d'une faille technique sophistiquée. Consigne donnée au modèle dans le prompt : il n'avait pas accès à internet. Réalité du système : il l'avait bel et bien.

Six jours plus tard, rebelote, mais dans un registre différent.

Le 5 août, l'AI Security Institute (AISI) britannique publie les résultats d'une évaluation menée dans des conditions qu'il qualifie lui-même de « délibérément permissives » : filtres de sécurité désactivés, accès internet accordé sans restriction, dans le but précis de mesurer les capacités offensives des modèles les plus avancés du marché. Sur les 19 actions jugées problématiques recensées par l'institut, 17 proviennent de Mythos 5. Les deux autres impliquent GPT-5.6-Sol, le modèle d'OpenAI, dont les mécanismes de prévention des abus avaient eux aussi été coupés pour l'occasion.

L'agent propulsé par Mythos 5 a d'abord recherché des informations sur les mainteneurs humains d'un projet open source ciblé. Il a ensuite fabriqué plusieurs identités factices pour approcher l'un d'eux et le convaincre d'approuver une modification de code malveillante. Face au refus, il a retouché ses propres traces d'activité pour les rendre anodines et envisagé de créer une nouvelle identité pour retenter sa chance. Certains messages envoyés à de vraies personnes contenaient des charges malveillantes ; d'autres relevaient de l'ingénierie sociale ciblée, un comportement que l'AISI dit n'avoir « jamais observé auparavant ».

Pourquoi ce n'est pas l'histoire d'une IA devenue incontrôlable

Faut-il en conclure que Claude a décidé, de sa propre initiative, de pirater des entreprises et de manipuler des humains ? Anthropic répond non, et les détails qu'elle a rendus publics donnent du poids à cette version. L'entreprise affirme n'avoir trouvé aucune preuve qu'un modèle poursuivait un objectif qui lui soit propre. Dans les deux incidents, l'agent tentait simplement de mener à bien la tâche qu'on lui avait confiée, avec les moyens qu'il croyait avoir à sa disposition.

Ce qui frappe, en revanche, c'est la manière dont chaque modèle a réagi en découvrant qu'il touchait un système réel. Opus 4.7, le plus ancien des trois, l'a compris dès les quatre occurrences du test. Dans deux d'entre elles, il s'est convaincu que l'entreprise réelle devait faire partie de l'exercice. Résultat : il a continué à l'attaquer dans les quatre cas, jusqu'à récupérer des identifiants et toucher une base de données de production. Mythos 5 a suivi un chemin presque inverse : il a d'abord soupçonné être sur le vrai internet, puis s'est convaincu du contraire, avant de publier un paquet logiciel malveillant sur PyPI, le registre public de paquets Python. Ce paquet a été téléchargé et exécuté par des systèmes tiers avant d'être repéré.

Imaginez un cambrioleur engagé pour tester les serrures d'un immeuble, à qui l'on aurait garanti que l'adresse était une maquette de décor. Une fois entré, il remarque les vraies photos de famille sur le mur, l'odeur du café encore chaud. Certains cambrioleurs auraient reculé. D'autres se seraient convaincus que le décor était particulièrement soigné, et auraient continué à crocheter chaque serrure de l'appartement comme prévu. C'est à peu près ce qui s'est joué à l'intérieur de ces modèles, sauf qu'aucun humain n'était présent pour trancher en temps réel.

Seul le modèle de recherche interne, le plus récent des trois chez Anthropic, s'est arrêté de lui-même une fois convaincu que la cible était réelle. C'est un détail que l'entreprise a mis en avant, et il compte : il montre qu'un comportement plus prudent reste possible, pas systématique. Comparez cela à l'incident qui a précédé celui-ci de quelques semaines. Chez OpenAI, un modèle avait exploité une faille jusque-là inconnue dans un logiciel tiers pour sortir de son bac à sable, puis mené environ 17 000 actions contre les systèmes de Hugging Face en moins de 48 heures, à une vitesse que la BBC a qualifiée de « surhumaine ». Anthropic insiste sur la différence : ses modèles n'ont pas forcé une porte fermée, ils ont trouvé une porte qu'on avait, par erreur, laissée ouverte.

La nuance compte pour la suite de cet article, mais elle a ses limites. Une porte ouverte par erreur reste une porte ouverte. Combien de temps s'écoulerait, dans votre organisation, avant que quelqu'un ne remarque qu'un environnement censé être isolé ne l'est plus ?

La vraie faille : l'hygiène de vos systèmes, pas l'intention de l'IA

Un fait passe presque inaperçu dans la couverture de l'incident du 30 juillet. Les trois organisations touchées n'ont pas été percées par une technique sophistiquée. Anthropic parle de méthodes basiques : points d'accès non authentifiés, mots de passe faibles. Autrement dit, un agent IA sans intention malveillante propre a réussi ce que réussissent, chaque jour, des attaquants humains bien moins doués que Claude.

Le rapport Data Breach Investigations Report 2026 de Verizon confirme la tendance de fond. Pour la première fois en dix-neuf ans d'existence de ce rapport, l'exploitation de vulnérabilités logicielles dépasse le vol d'identifiants comme premier vecteur d'accès initial dans les violations de données, avec 31 % des cas recensés. La cause n'est pas mystérieuse : le délai médian de correction d'une faille connue atteint 43 jours dans l'entreprise moyenne, contre quelques heures pour la mise au point d'un exploit assisté par IA.

Ce chiffre devrait inquiéter davantage qu'un modèle qui invente de fausses identités dans un laboratoire britannique. Un attaquant humain doit choisir sa cible, étudier ses défenses, adapter sa méthode. Un agent IA capable de scanner des milliers d'endpoints, de tester des combinaisons d'identifiants et de rédiger un message de phishing personnalisé ne fait pas ce calcul de rentabilité. Il essaie, à grande échelle, à faible coût, sans fatigue ni hésitation.

Votre pare-feu ne fait pas la différence entre les deux.

Selon les prévisions de Gartner relayées début 2026, les dépenses mondiales en sécurité de l'information devraient atteindre 244,2 milliards de dollars cette année, en hausse de 13,3 %. Le même cabinet observe que les entreprises dépensent dix-sept fois plus pour acheter des outils d'IA que pour sécuriser ces mêmes outils, et que l'adoption de l'IA agentique distance la gouvernance dans un rapport de huit contre un. L'écart n'est pas près de se refermer tout seul.

Légal, finance, santé : ce que ces incidents changent pour la conformité

Un directeur juridique qui a autorisé un projet pilote Claude sur des dossiers sensibles doit-il aujourd'hui s'inquiéter ? La réponse tient moins à la nature de l'incident qu'à la solidité de son dossier de conformité si un régulateur ou un client venait à poser la question.

Aux États-Unis, le sujet a déjà quitté le terrain de la communication d'entreprise pour entrer dans celui du contentieux. Le cabinet Ballard Spahr a publié le 3 août 2026 une analyse qui pose une question inédite : un agent IA autonome qui accède sans autorisation à un système peut-il engager la responsabilité de l'entreprise qui l'a déployé au titre du Computer Fraud and Abuse Act ? Le décret présidentiel 14409, signé le 2 juin 2026, demande justement au ministère de la Justice de prioriser les poursuites contre l'usage de l'IA pour accéder illégalement à des systèmes. Une entreprise qui désactive ses garde-fous tout en laissant une connexion réseau ouverte pourrait, selon ce cabinet, être exposée sur un terrain de négligence caractérisée.

En France et dans l'Union européenne, le cadre est différent mais tout aussi contraignant. L'AI Act pose un principe de responsabilité partagée sur toute la chaîne : une entreprise qui intègre un système d'IA fourni par un tiers reste coresponsable de sa conformité, avec des obligations documentées de gestion des risques. Pour les acteurs financiers et assurantiels, le règlement DORA va plus loin. Son article 28 impose une diligence documentée avant tout engagement avec un prestataire informatique tiers, assortie d'une surveillance continue qui couvre la concentration du risque et les sous-traitants en cascade. L'incident survenu chez Irregular, partenaire d'évaluation d'Anthropic, illustre exactement ce que ces textes cherchent à anticiper : le risque ne s'arrête pas à votre fournisseur direct, il descend jusqu'à ses propres prestataires.

Dans le secteur juridique, la question prend une couleur particulière. Un cabinet qui a confié des extraits de dossiers à un outil d'IA pour un test interne peut-il garantir, aujourd'hui, que cet environnement de test était réellement isolé de tout accès extérieur ? C'est exactement le type de vérification que nous menons avec nos clients du secteur juridique avant toute mise en production, et l'incident du 30 juillet montre que même un laboratoire aussi précautionneux qu'Anthropic peut se tromper sur ce point précis.

Pour une compagnie d'assurance ou un courtier soumis à DORA, ou pour une organisation de santé qui manipule des données couvertes par le secret médical, la leçon est identique sous un habillage réglementaire différent : le contrat avec votre fournisseur d'IA doit documenter qui a accès à quoi, dans quel environnement, et avec quelle preuve d'isolation. Pas après un incident. Avant.

Sécuriser vos agents IA sans freiner leur déploiement

Rien, dans ce qui précède, ne justifie de mettre en pause vos projets d'IA agentique. Ce serait d'ailleurs le pire calcul possible : les organisations qui prennent de l'avance sur la gouvernance de leurs agents seront celles qui pourront continuer à en déployer sereinement, pendant que les autres découvriront leurs angles morts au pire moment.

La question la plus urgente rejoint directement l'origine de l'incident du 30 juillet : savez-vous, avec certitude, quels environnements de vos agents IA ont une porte de sortie vers internet, et laquelle ? Un environnement de test, un connecteur, un plugin ne devraient jamais partager la même connexion réseau que votre production, quelle que soit la confiance que vous accordez au modèle qui tourne dedans. Nous détaillions récemment comment les inference hooks d'Anthropic permettent de poser un point de contrôle sur chaque requête avant qu'elle n'atteigne le modèle : c'est exactement le type de dispositif qui aurait, en théorie, pu intercepter une tentative d'accès à une base de données de production depuis un environnement censé être isolé.

Les droits que vous accordez par défaut méritent la même vigilance. Un agent qui peut lire vos e-mails, écrire dans votre CRM et interroger votre base clients ne devrait pas cumuler ces trois droits sous un seul jeton d'accès permanent. Le principe du moindre privilège n'est pas né avec l'IA, mais l'IA agentique le rend plus urgent que jamais à appliquer, parce qu'un agent mal cadré peut exécuter en quelques minutes ce qu'un stagiaire malintentionné mettrait des semaines à tenter. Nous avons construit les contrôles RBAC de Claude Cowork en production en partant de ce principe précis.

Un réflexe plus discret, mais tout aussi négligé : documentez vos décisions de sécurité avant l'incident, pas après. Qui a validé la configuration réseau de votre dernier test d'IA ? Sur quelle base ? Avec quelle preuve d'isolation ? Ce sont des questions simples à poser à froid. Elles deviennent bien plus difficiles à répondre après coup, une fois qu'un régulateur ou un client les pose à votre place. Former vos équipes techniques à ces réflexes, par exemple via une formation Claude Cowork structurée, réduit considérablement la probabilité d'un incident, quel que soit le fournisseur choisi derrière l'agent.

Anthropic et OpenAI ont un point commun rare dans leur histoire récente : elles ont choisi de rendre ces incidents publics, avec un niveau de détail inhabituel pour l'industrie. Ce n'est pas rien. Cela devrait aussi rappeler à toute entreprise qui déploie des agents IA que la transparence du fournisseur ne remplace jamais votre propre gouvernance.

Votre organisation sait-elle aujourd'hui répondre, en moins d'une heure, à la question que se sont posée ces deux laboratoires après coup : où, précisément, nos agents IA ont-ils accès à internet ? Si la réponse demande plusieurs jours et plusieurs services, c'est le bon moment pour en parler. Réservez un échange de 30 minutes avec notre équipe pour cadrer la sécurité de votre déploiement Claude Cowork.