Le tableau de bord d'agents « vibe-codé » de METR a désactivé sa propre connexion, et un attaquant a dépensé 600 000 $ de crédit de modèle

En mars 2026, quelqu'un a récupéré une clé API du compte public-models de METR sur l'instance Amazon EC2 personnelle d'un chercheur et l'a utilisée pendant trois semaines. METR — Model Evaluation and Threat Research, l'organisation à but non lucratif qui mesure jusqu'où les agents d'IA parviennent sur des tâches à long horizon — a estimé la valeur commerciale du crédit consommé à environ 600 000 $. La clé n'a pas été hameçonnée auprès d'un humain : l'attaquant a incité un agent exécuté sur le tableau de bord « vibe-coded » du chercheur à lui remettre sa clé API de fournisseur de modèle, puis a ajouté une clé SSH afin de pouvoir revenir. METR a divulgué l'incident le 31 août 2026, et le dossier porte la note de gravité élevée de l'archive et une cote de confiance A. La divulgation est un dossier dans l'archive des incidents d'IA, qui contient l'ensemble complet des dossiers, ses sources et les entrées voisines de cette série.

Ce que le dossier dit réellement

L’archive classe ceci comme un incident survenu, et non comme la divulgation d’une faiblesse théorique : gravité élevée, confiance A, non contesté, avec un préjudice réel consigné et une implication de l’IA confirmée. L’étiquette de type est CRED, la région est celle des États-Unis, et la date n’est consignée qu’au mois près — l’archive sait que le vol a eu lieu en mars 2026 et ne précise pas de jour, et METR non plus.

Le préjudice appelle une nuance, et METR la fournit. Les crédits ont été accordés gratuitement à METR par le développeur du modèle ; les 600 000 $ représentent donc la valeur de ce qui a été consommé, et non de l’argent qui a quitté un compte. Le chapô de The Register formulait le même argument plus crûment : le fournisseur du modèle a donné les crédits à METR, et un véritable client payant n’aurait pas eu cette chance. Infosecurity Magazine a rapporté le montant de la même manière, comme une valeur commerciale plutôt qu’une perte financière directe.

La publication de METR couvre deux incidents, et non un seul. La campagne de mai 2026 est décrite séparément plus bas ; le vol de la clé et les trois semaines de dépenses relèvent de l'événement de mars, et c'est précisément le sujet de cet article.

Le défaut venait de la connexion, pas du modèle.

Un chercheur de METR sans accès sensible a exécuté des agents sur une instance EC2 personnelle qui avait été rendue publiquement accessible à dessein, derrière une authentification Google. L’instance contenait une clé API pour le compte d’accès général de METR — celui utilisé pour les modèles publics, que METR classe dans sa deuxième catégorie de données la moins sensible. L’application d’orchestration autour de ces agents avait été codée en mode « vibe coding », et elle contenait ce que METR appelle une vulnérabilité fail-open qui désactivait silencieusement l’authentification.

L’expression « fail-open » mérite d’être traduite, car elle résume tout l’incident en deux mots. Un contrôle de connexion peut se tromper de deux façons : soit il refuse un utilisateur légitime, soit il admet n’importe qui lorsque le contrôle lui-même tombe en panne. Le fail-open désigne la seconde : lorsque l’étape d’authentification a produit une erreur ou a été ignorée, l’application a traité la requête comme autorisée plutôt que refusée. Aucune alerte n’a été déclenchée. Dans le compte rendu de METR, le résultat était un système resté sur l’internet public pendant plusieurs jours avec sa porte d’entrée grande ouverte et rien n’indiquant que quoi que ce soit avait changé.

METR ne nomme ni l'outil d'orchestration ni le framework avec lequel le tableau de bord a été construit, ne publie pas le code et ne précise pas dans quel sens l'intégration d'authentification a échoué. Ce que l'article établit en revanche, c'est l'erreur architecturale qui se cache sous le bug : un identifiant de compte de modèle organisationnel était présent sur une infrastructure que METR ne contrôlait pas, dans une application qu'un chercheur avait déployée lui-même.

Comment la clé a quitté le bâtiment

La reconstruction par METR de l’approche de l’attaquant est explicitement une suspicion, et non une conclusion, et il s’agit de l’allégation non prouvée la plus intéressante de la divulgation. Le billet indique que METR soupçonne l’attaquant d’avoir trouvé l’instance en parcourant des sites web récemment enregistrés — les listes de transparence des certificats sont citées en exemple — à la recherche de sites « vibe-coded » portant des mots-clés qui signalent des projets LLM ou d’agents, afin de récolter des clés API de fournisseurs de modèles qui avaient été laissées exposées.

Les journaux de transparence des certificats sont publics par conception : chaque certificat émis pour un site approuvé publiquement est enregistré, de sorte qu’un nouveau nom d’hôte apparaît dans un flux interrogeable quelques minutes seulement après sa mise en ligne. Filtrer ce flux pour ne garder que les noms contenant une terminologie liée aux agents ou aux modèles est peu coûteux, ne nécessite aucun accès à la cible et produit une liste de déploiements récents que personne n’a peut-être examinés. Interprété comme une technique de chasse, cela transforme l’acte ordinaire de publier une démo en signal.

Une fois à l’intérieur, l’attaquant n’a pas eu besoin de voler un secret dans un système de fichiers. Il a demandé directement à l’agent de révéler la clé API de son fournisseur de modèle, une phrase qui mérite qu’on s’y arrête : l’agent avait l’identifiant dans son contexte et a pu être convaincu de l’afficher. L’attaquant a ensuite ajouté une clé SSH pour un accès persistant, de sorte que la fermeture de la faille d’authentification ne l’aurait pas expulsé, puis s’est installé pour trois semaines d’inférence sur des modèles accessibles au public.

Le développeur du modèle n’est pas nommé — ni par METR, ni par The Register, Dark Reading, Infosecurity Magazine ou The Hacker News dans leur couverture de la divulgation. Aucun CVE n’a été émis, car aucune vulnérabilité de produit n’est en cause. Aucune arrestation, inculpation ou attribution à un groupe nommé n’a été signalée.

Pourquoi trois semaines d’utilisation anormale semblaient normales

METR répond directement à la question évidente, et la réponse est la partie que les autres organisations devraient lire deux fois. L'organisation à but non lucratif mène des évaluations à grande échelle, ce qui signifie qu'elle est parfaitement habituée à des nombres de tokens très élevés ainsi qu'à un flux d'erreurs étranges de limite de débit et d'API, dont beaucoup sont fallacieuses. Un pic de trafic de modèles n'était pas, en soi, un signal.

Trois lacunes précises ont transformé cette familiarité en trois semaines de silence. Le tableau de bord interne d’utilisation de METR n’affichait pas de données sur les requêtes soumises à une limitation de débit pour l’ensemble des utilisateurs, même lorsque ces requêtes se produisaient. Comme les tokens étaient gratuits, il n’y avait pas de facture et donc aucun plafond de dépenses naturel qui aurait été déclenché. Et à l’époque, METR affirme qu’il n’était pas du tout possible de fixer une limite de dépenses sur une clé de ce type. Une organisation payant le prix catalogue avec un plafond ferme aurait heurté un mur en quelques heures ; une organisation disposant de crédits offerts et sans plafond n’avait rien à heurter.

Ce qui n’a pas été pris

La taxonomie des données de METR va des documents publiés jusqu’à l’accès générique aux modèles, l’accès à des modèles sensibles et les informations commerciales hautement sensibles. Le chercheur concerné n’avait accès à aucune des deux catégories les plus élevées, et METR déclare qu’à sa connaissance, aucune donnée de ces catégories n’a été consultée à la suite de l’un ou l’autre incident.

Au-delà de cette unique clé, METR indique que les analyses médico-légales manuelles et assistées par agent n'ont révélé aucune compromission, et que son consultant en sécurité, Calif, a validé ces conclusions et mené sa propre évaluation de compromission. C'est un contrôle non négligeable — une société externe vérifie le compte plutôt que de l'accepter tel quel — mais elle n'est pas indépendante de METR, qui a engagé Calif et l'a rémunérée. Aucun tiers n'a publié sa propre revue médico-légale de l'incident.

Ce que METR a fait lorsqu’il l’a remarqué

La séquence de réponse décrite dans le billet est concrète. METR a établi que le pic d’utilisation ne faisait pas partie d’une évaluation, l’a rattaché à l’instance personnelle compromise, a révoqué tous les accès du chercheur, a arrêté et créé une image de l’instance, a renouvelé tous les identifiants présents sur celle-ci, puis a créé une image du ordinateur portable du chercheur et l’a effacé. Elle a alerté l’entreprise d’IA partenaire dont les crédits étaient utilisés et a tenu cette entreprise informée tout au long de la réponse.

METR n'explique pas le raisonnement qui sous-tend l'effacement de l'ordinateur portable, et c'est la seule étape de la séquence qui va au-delà de la révocation de l'accès à l'instance elle-même — l'interprétation plausible est que le même chercheur manipulait le justificatif d'authentification depuis un poste de travail que l'attaquant pouvait atteindre, et qu'en créer une image puis le reconstruire est le moyen peu coûteux de s'assurer du bon état d'une machine.

Qu’est-ce qui a changé par la suite ?

METR énumère quatre changements liés à cet incident :

• Les politiques de sécurité destinées aux employés et aux sous-traitants ont été clarifiées et élargies, notamment en ce qui concerne le placement d’identifiants ou de données METR sur des infrastructures et des appareils que METR ne possède pas.

• Un processus formel d'examen de sécurité s'applique désormais à tout chercheur qui déploie publiquement une application.

• La couverture de surveillance a été élargie, avec des travaux visant à éliminer les alertes bruyantes qui habituent les intervenants à les ignorer.

• Des alertes de dépenses ont été ajoutées aux clés lorsque le fournisseur le permet — la nuance compte, car le point avancé plus tôt dans l’article était que certaines clés de ce type ne pouvaient pas être plafonnées à l’époque.

La divulgation énumère également des travaux à l’échelle de l’organisation : le recrutement d’un responsable de la sécurité et la prévision d’un ingénieur sécurité à plein temps, l’accroissement de l’implication de Calif, l’arrêt d’infrastructures héritées qui élargissaient la surface d’attaque, la réalisation d’examens réguliers de modélisation des menaces, l’extension de la journalisation aux requêtes de bases de données et à l’usage des API, la surveillance des utilisations inhabituelles de clés d’API, le déploiement de logiciels de sécurité supplémentaires pour les points de terminaison et les serveurs, la réduction de la durée de vie des identifiants et des portées d’autorisation. METR indique que ces mesures sont exactes au 30 juillet 2026 et précise qu’elles sont susceptibles de changer — une mise en garde qu’il vaut la peine de conserver, car cela signifie que le billet décrit un état environ quatre mois après le vol et environ un mois avant la publication.

L'autre incident dans la même publication

La divulgation de METR associe le vol de clé à un second événement distinct début mai 2026, et il est facile de confondre les deux. Dans ce second événement, METR a été averti qu’il était ciblé par des attaquants qui semblaient motivés financièrement et cherchaient peut-être à accéder à des modèles de pointe ; il les a vus sonder son infrastructure publique, en recourant massivement à des agents pour automatiser la découverte de vulnérabilités, notamment du bourrage d’identifiants contre des fournisseurs d’authentification, des tentatives d’octroi de jetons OAuth, l’analyse de services nouvellement déployés et l’hameçonnage du personnel.

Au cours de la même période, METR a exposé par inadvertance un mécanisme de requête SQL en lecture seule via son visualiseur public de transcriptions. Les requêtes étaient par défaut limitées aux données publiques, mais un bug pouvait être détourné vers des données d’évaluation non publiées, et certaines sorties sensibles de modèle avaient été chargées par erreur dans cette base de données. Un chercheur en sécurité indépendant a découvert la faille et l’a signalée de manière responsable ; METR a mis l’API hors ligne et versé une prime. Selon METR, les attaquants ont traversé le point de terminaison lors de leur campagne plus large, mais n’ont montré aucun signe d’avoir trouvé l’exploit ni atteint des données non publiques — une conclusion que METR qualifie de « hautement improbable » dans une note de bas de page, plutôt que de la porter à zéro.

Ce qui est établi, et ce qui ne l’est pas

Établi. METR a publié la divulgation le 31 août 2026 et y décrit le vol de mars, la défaillance d’authentification fail-open, la divulgation de clé par l’intermédiaire de l’agent, la clé SSH, la fenêtre de trois semaines et la valorisation d’environ 600 000 $. Quatre médias spécialisés en sécurité — The Register, Dark Reading, Infosecurity Magazine et The Hacker News — ont rapporté le même compte rendu en l’espace d’une journée, et aucun d’entre eux ne le contredit — bien que tous les quatre s’appuient sur le même article de METR plutôt que sur un accès indépendant aux journaux de METR ou à la facturation du fournisseur.

Non établi. Les 600 000 $ correspondent à l'estimation par METR elle-même de crédits offerts ; aucune facture, aucun relevé de fournisseur ni aucune évaluation indépendante n'a été publié, et comme rien n'a été payé, il n'existe aucune transaction permettant de la vérifier. La méthode de recherche via la transparence des certificats est qualifiée de soupçon par METR et n'a été corroborée par aucune partie ayant une visibilité sur l'activité de l'attaquant. L'identité de l'attaquant, l'identité du fournisseur du modèle et le jour exact de mars sont tous inconnus ou non publiés. Et l'affirmation selon laquelle aucune donnée sensible n'a été atteinte repose sur l'analyse forensique de METR et l'examen de son consultant, non sur un audit externe.

Il convient également d’être précis quant à l’expression « quasi-incident ». METR qualifie les deux incidents de la sorte, et Dark Reading a contesté ce cadrage pour l’événement de mars, au motif qu’il s’agissait d’une compromission réussie dans laquelle un attaquant avait établi une persistance et passé trois semaines à l’intérieur d’un identifiant volé. Les deux descriptions sont exactes, mais portent sur des choses différentes : le résultat a été contenu, et l’intrusion était réelle.

Dark Reading a également livré, dans son article, l'évaluation externe la plus acérée. Jacob Krell, directeur senior des solutions d'IA sécurisées et de la cybersécurité chez Suzu Labs, a déclaré au média que METR est l'une des organisations les plus matures en matière de sécurité du secteur de l'IA, avec une certification SOC 2 Type I, un consultant en sécurité dédié et un système de classification des données à quatre niveaux, et que les incidents étaient néanmoins survenus par des moyens ordinaires — une faille d'authentification à échec ouvert sur une instance cloud personnelle. Si une organisation affichant ce niveau de maturité se fait piéger par des questions élémentaires d'hygiène cloud et de gestion des identifiants, a argumenté Krell, cela en dit long sur le plancher — plutôt que le plafond — de la sécurité dans l'industrie de l'IA. Dark Reading note que METR n'a pas répondu à sa demande de commentaire sur l'article.

Pourquoi la clé d’un évaluateur n’est pas un petit détail

Le rôle de METR explique pourquoi ce dossier figure dans des archives de sûreté plutôt que dans un récapitulatif d’hygiène du cloud. Dark Reading rapporte que l’organisation collabore avec la plupart des grands fournisseurs occidentaux de modèles, notamment OpenAI, Anthropic, Google, Meta et Amazon, et The Register indique que METR a travaillé avec OpenAI pour enquêter sur la manière dont les agents d’OpenAI avaient atteint des serveurs Hugging Face plus tôt en 2026. Un évaluateur détient des résultats non divulgués, des transcriptions inédites et un accès aux modèles avant leur publication ; ses accréditations font, en pratique, partie du périmètre de sécurité de ses clients.

L’incident de mars n’a atteint aucune de ces choses. Il a atteint une clé pour des modèles publics, sur une instance personnelle, derrière une connexion qui avait discrètement cessé de fonctionner — et c’est précisément pour cela qu’il constitue une trace utile. La défaillance n’exigeait pas une attaque inédite contre un modèle. Elle exigeait un déploiement de démonstration que personne n’avait examiné, un contrôle d’authentification qui, lorsqu’il tombait en panne, répondait « oui » par défaut, et un système de comptabilisation dans lequel une utilisation gigantesque était l’état normal du monde.