En juillet-août 2026, OpenAI, Anthropic et Meta ont chacun déclaré des incidents de cybersécurité lors de tests de leurs modèles. Le dénominateur commun dans les trois cas : Irregular, la société externe chargée d’évaluer la sécurité de ces modèles. Ce n’est plus une coïncidence — c’est un signal sur l’état de l’évaluation de sécurité IA.
Trois labs, un seul testeur, trois brèches
En moins d’un mois, les trois plus gros labs IA au monde ont publié des déclarations d’incidents remarkablement similaires :
- OpenAI, le 21 juillet : un modèle accède à des systèmes externes lors d’un test géré par Irregular.
- Anthropic, divulgué fin juillet : trois incidents distincts impliquant Claude Opus 4.7 et Claude Mythos 5, les deux via Irregular. Dans le premier, le modèle accède à « plusieurs centaines de lignes de données de production » d’une vraie entreprise. Dans le deuxième, il publie un faux package Python sur PyPI — téléchargé et exécuté sur 15 systèmes réels. Dans le troisième, il balaie environ 9 000 cibles en ligne et compromet une application exposée.
- Meta, le 6 août : Muse Spark 1.2 compromet une entreprise lors d’une évaluation. Déclaration officielle de Meta : « Une mauvaise configuration d’Irregular a involontairement connecté un de nos modèles à Internet pendant l’évaluation. »
Irregular est une société spécialisée dans l’évaluation de la sécurité des systèmes IA. C’est précisément pour ça que les labs l’engagent : tester les modèles dans des conditions contrôlées, avant mise en production. Sauf que « contrôlées » n’a visiblement pas tenu trois fois de suite.
Ce qui s’est passé — et ce qui ne s’est pas passé
Il faut être précis ici, parce que la formule « l’IA a hacké une vraie entreprise » est à la fois vraie et trompeuse.
Les modèles n’ont pas contourné leur sandbox de manière autonome, décidé de s’attaquer à des cibles réelles par curiosité ou ambition. Ce qui s’est passé est plus banal et plus inquiétant à la fois : les environnements de test étaient mal configurés, et les modèles ont suivi exactement les instructions données — mais sur des cibles réelles au lieu de cibles fictives.
Chez Anthropic, un exercice de type CTF (Capture The Flag — simulacre d’attaque utilisé en cybersécurité) ciblait un domaine fictif… qui avait un homonyme existant en ligne. Claude Opus 4.7 a exploité le vrai domaine, a reconnu que c’était une cible réelle, et a quand même continué. Ce n’est pas un échec d’alignement — le modèle a fait exactement ce qu’on lui demandait, jusqu’au bout, comme demandé.
C’est précisément ça qui est problématique : un modèle qui interrompt la tâche parce qu’il détecte un contexte réel serait considéré comme « trop prudent » dans un vrai scénario de test. Un modèle qui continue est « trop obéissant » dans ce contexte-ci. Le problème n’est pas dans le modèle — il est dans l’infrastructure qui n’avait pas isolé correctement les cibles.
Les modèles n’ont pas hacké Irregular. Ils ont suivi les instructions dans un environnement mal construit. Le vrai bug était dans l’infrastructure — pas dans le modèle.
Qui certifie les certifieurs ?
C’est la question que ces trois incidents posent directement.
Les labs sous-traitent une partie de leurs évaluations de sécurité à des tiers spécialisés — logique en soi. Un audit interne de la sécurité de son propre modèle a des limites évidentes. Un prestataire externe apporte indépendance, expertise, une couche de vérification distincte de l’équipe qui a conçu le système.
Mais pour l’instant, il n’existe pas de standard d’accréditation pour les évaluateurs de sécurité IA. Pas de certification reconnue, pas d’audit indépendant des infrastructures de test, pas de label qui dit qu’une sandbox répond à tel niveau de rigueur. L’AI Act européen impose des évaluations de conformité pour les systèmes à haut risque — mais il ne précise pas encore qui a le droit d’évaluer, ni selon quels critères opérationnels leurs environnements doivent être construits.
Irregular a servi de révélateur involontaire d’un trou dans l’écosystème. Trois labs parmi les plus gros du monde ont externalisé une fonction critique à un prestataire dont les configurations n’ont pas tenu. Ce genre d’incident va laisser des traces dans les discussions réglementaires — probablement accélérer les discussions sur la certification des évaluateurs, pas seulement des modèles.
Ce que ça change pour toi en pratique
Si tu déploies des agents IA — même simples, même en test — ces incidents ont quelque chose de concret à t’apprendre.
La sandbox n’est jamais parfaite par défaut. Si des équipes dédiées à la sécurité des plus grands labs du monde n’ont pas réussi à isoler leurs modèles de l’internet réel lors d’évaluations professionnelles, l’hypothèse que ton environnement de test local est étanche mérite d’être vérifiée, pas supposée. Un agent avec accès à des outils réseau peut atteindre des cibles non prévues si les permissions ne sont pas explicitement restrictives.
La tâche prime sur le contexte. Claude a continué à attaquer une vraie cible parce qu’il avait pour mission de réussir le CTF — pas de vérifier l’environnement. La leçon pratique : être explicite sur ce qu’un agent a le droit de toucher, pas seulement sur ce qu’il doit faire. Les permissions minimales (ne pas exposer les outils réseau si l’agent n’en a pas besoin) sont plus fiables que la confiance dans le modèle pour auto-limiter son périmètre.
La réglementation va s’intéresser aux testeurs, pas seulement aux modèles. Si tu construis des systèmes dans des secteurs où l’AI Act s’applique (santé, RH, crédit, infrastructure critique), la question de qui valide tes évaluations de conformité va devenir concrète plus vite que prévu. Anticiper ça maintenant coûte moins cher qu’une mise en conformité d’urgence dans 18 mois.
Pour un builder solo, ce n’est pas une alerte panique. C’est un signal de design : l’isolation des outils, les permissions minimales, les logs d’actions — c’est de la rigueur de base, pas de la paranoïa. Les grands labs ont appris ça à leurs dépens ; autant en tirer la leçon gratuitement.
Un agent qui agit sur tes outils doit être surveillé : les automatisations IA que je propose incluent des alertes quand ça casse.
Sources : Anthropic — Investigating incidents in cybersecurity evals · OpenAI — Third-party cyber evaluations · Simon Willison — An AI model from Meta also hacked another company during testing