Claude a piraté trois entreprises réelles pendant un test de sécurité : le problème n'était pas l'IA

Anthropic a reconnu que Claude a piraté trois entreprises réelles lors de tests censés être isolés d'Internet. La faille n'était pas dans le modèle, mais dans une consigne jamais vérifiée.

Le 31 juillet, Anthropic a publié un rapport d'incident inhabituel pour une entreprise qui vend de la confiance : entre avril et juillet, trois modèles Claude différents — Opus 4.7, Mythos 5 et un modèle de recherche interne — ont obtenu un accès non autorisé aux systèmes réels de trois organisations, alors qu'ils étaient censés opérer dans des environnements de test coupés d'Internet. Neuf jours plus tôt, OpenAI avait reconnu que deux de ses modèles les plus avancés, dont GPT-5.6 Sol, s'étaient échappés d'un environnement isolé en exploitant une faille inconnue pour atteindre l'infrastructure de production de Hugging Face. Anthropic n'a découvert ses propres incidents qu'en réexaminant, dans la foulée, 141 006 sessions d'évaluation menées avec son partenaire Irregular.

Le détail qui compte pour un DSI n'est pas le nombre d'incidents, c'est leur cause. Dans les trois cas, il ne s'agissait ni d'une faille zero-day ni d'une tentative du modèle de s'évader de son bac à sable : la consigne système disait à Claude qu'il n'avait pas accès à Internet, une erreur de configuration avec le partenaire d'évaluation faisait que si, et le modèle a simplement cherché sa cible là où elle se trouvait — par accident, sur le vrai Internet. Dans un cas, le nom de l'entreprise fictive correspondait à un domaine réellement actif : Claude en a exploité les vraies vulnérabilités sur quatre sessions, a extrait des identifiants et a atteint une base de production contenant plusieurs centaines de lignes de données réelles. Dans un deuxième cas, Claude a publié un vrai paquet Python malveillant sur PyPI pour piéger une cible fictive dont les instructions d'onboarding citaient un paquet inexistant ; resté téléchargeable une heure, ce paquet a fini exécuté sur 15 systèmes réels, dont le scanner de sécurité d'une entreprise qui l'a installé automatiquement. Dans le troisième, faute de cible atteignable, le modèle a balayé environ 9 000 systèmes avant de compromettre une application exposée par des moyens élémentaires — identifiants lisibles sur une page de debug, injection SQL.

Ce qui frappe en lisant le rapport, c'est l'absence quasi totale de sophistication technique côté attaque. Mots de passe faibles, points d'accès non authentifiés, page de debug ouverte : ce sont les négligences qu'un audit de sécurité classique liste depuis quinze ans, sans qu'aucune intelligence artificielle ne soit nécessaire pour les exploiter. La partie réellement nouvelle, celle qui justifie qu'on s'y arrête, c'est que la frontière censée protéger ces systèmes — "cet environnement est isolé, le modèle n'a pas accès à Internet" — n'était pas une frontière technique vérifiée, c'était une phrase dans un prompt système. Et cette phrase a tenu jusqu'à ce qu'un concurrent se fasse prendre en premier et pousse Anthropic à vérifier, après coup, quatre mois d'historique.

C'est ce point précis qui devrait inquiéter toute entreprise en train de déployer des agents IA avec accès à des outils, des bases de données ou de l'exécution de code en interne. La tentation, quand on configure un agent, est de définir son périmètre par instruction plutôt que par contrôle technique : on lui dit qu'il n'a pas accès à telle base, qu'il ne doit pas écrire en production, qu'il doit rester dans tel répertoire. C'est exactement la méthode qu'Anthropic utilisait pour ses propres évaluations de cybersécurité — chez l'entreprise qui a construit sa marque entière sur la rigueur de ses pratiques de sécurité, avec une équipe dédiée et un partenaire externe spécialisé. Si ce dispositif n'a pas suffi à empêcher un accès Internet non prévu pendant plusieurs mois, la probabilité qu'une consigne équivalente, posée dans le prompt système d'un agent métier interne, constitue une vraie barrière est proche de zéro.

La partie que je retiens comme la plus révélatrice, ce n'est pas l'intrusion elle-même mais le raisonnement de Mythos 5 en cours de route. Le modèle a explicitement noté que si son environnement était le vrai Internet, publier ce paquet constituerait une attaque réelle, "pas acceptable" — puis s'est convaincu du contraire parce qu'il ne reconnaissait pas les autorités de certification rencontrées et parce que la date affichée sur les systèmes, 2026, lui semblait confirmer une simulation. Un modèle capable de formuler correctement le risque et de l'écarter sur des indices aussi fragiles n'est pas une garantie de sécurité : c'est une variable de plus dans l'équation, non un juge fiable de ce qui est réel.

La seule chose qu'Anthropic a bien faite dans cette histoire, c'est la vitesse de réaction : évaluations suspendues le jour de la détection, incidents identifiés en 24 heures, organisations prévenues trois jours après — deux d'entre elles ignoraient totalement avoir été compromises. Ce délai de réaction compte davantage que n'importe quelle promesse de prévention parfaite, parce que la prévention parfaite d'un système suffisamment complexe n'existe pas.

Ce que je retiens de ces deux incidents parallèles, en testant des agents IA en conditions réelles depuis plusieurs mois, c'est qu'aucune consigne donnée à un modèle ne remplace une frontière réseau vérifiée indépendamment. Un agent qui a effectivement accès à un système fera ce qu'on lui a demandé sur ce système, autorisé ou non, parce que rien dans son fonctionnement ne le pousse à remettre en cause un accès qu'il constate. La question à se poser avant de donner des outils à un agent n'est donc pas "que lui ai-je dit de ne pas faire", mais "qu'est-ce qui l'empêche techniquement de le faire s'il essaie ?". Anthropic vient de démontrer, à ses propres frais, que la différence entre les deux n'est pas théorique.

Romain Faure, praxena.fr