Les incidents de sécurité chez METR révèlent une défaillance d’identifiants IA à 600 000 dollars

METR a révélé deux incidents de sécurité après qu’un attaquant a dérobé une clé API et consommé des crédits de modèles évalués à environ 600 000 dollars. La première attaque s’est poursuivie pendant trois semaines, malgré la génération d’un trafic inhabituel et d’erreurs répétées de limitation de débit.

La perte ne s’est pas traduite par une facture directe, car le développeur du modèle avait accordé ces crédits gratuitement à METR. Ce détail a limité l’impact financier, mais il a également supprimé un seuil de dépenses qui aurait pu révéler l’abus plus tôt.

Les incidents de sécurité chez METR dépassent le cadre d’une seule organisation de recherche. Un tableau de bord expérimental d’agent réunissait dans un même système un accès au cloud, des identifiants actifs, une exposition publique et une surveillance insuffisante. Cette combinaison a transformé une défaillance d’authentification en un accès prolongé à des ressources de calcul précieuses.

METR affirme que son enquête n’a trouvé aucune preuve que les attaquants aient accédé à ses informations les plus sensibles. Toutefois, un second incident a montré à quel point des outils de recherche publics étaient proches de données d’évaluation privées. Ensemble, ces cas remettent en cause l’idée selon laquelle les prototypes à faible enjeu méritent des contrôles de sécurité moins rigoureux.

Les incidents de sécurité chez METR ont commencé par un tableau de bord d’agent exposé

Le premier incident a débuté comme une défaillance d’authentification classique, mais un agent IA a fourni le chemin entre l’accès public et le vol d’identifiants.

En mars 2026, un chercheur de METR a déployé des agents sur une instance personnelle Amazon EC2. EC2 est la plateforme d’Amazon Web Services permettant de louer des serveurs virtuels. Le chercheur a intentionnellement rendu l’instance accessible depuis internet et l’a placée derrière l’authentification Google.

L’application comportait ce que METR a qualifié de vulnérabilité en mode fail-open. Un système fail-open continue de fonctionner lorsqu’un contrôle d’authentification échoue, au lieu de refuser l’accès. Dans ce cas, la défaillance a désactivé silencieusement l’authentification et exposé le tableau de bord pendant plusieurs jours.

L’instance EC2 contenait également une clé API associée au compte d’accès général de METR pour les modèles publics. Une clé API est un identifiant que les logiciels utilisent pour authentifier des requêtes vers un service en ligne.

Selon la divulgation de sécurité de METR, l’attaquant a incité un agent à révéler cette clé de fournisseur de modèles. L’attaquant a ensuite installé une clé SSH, créant ainsi une méthode persistante d’accès à distance au serveur compromis.

Cette séquence est importante. L’attaquant n’a pas eu besoin de contourner les garde-fous d’un modèle de pointe ni de développer un nouvel exploit IA. L’ouverture initiale provenait d’un contrôle ordinaire d’application web qui a échoué dans un état non sécurisé.

L’agent a néanmoins influencé le résultat. Une fois qu’un tiers a atteint l’interface, l’agent pouvait accéder à un identifiant ou le reproduire, alors que celui-ci avait une valeur en dehors de l’application elle-même. Le tableau de bord compromis est ainsi devenu un pont vers un compte distinct auprès d’un fournisseur de modèles.

METR soupçonne que l’attaquant a découvert l’instance en surveillant des sites web récemment enregistrés. Les registres de transparence des certificats peuvent aider à identifier de nouveaux domaines et sous-domaines, car ils enregistrent publiquement les certificats web émis.

L’organisation estime que l’attaquant a recherché dans ces registres des termes liés aux grands modèles de langage et aux agents. De tels termes peuvent identifier des services expérimentaux susceptibles de contenir des identifiants précieux de fournisseurs.

Cette explication reste l’évaluation de METR plutôt qu’une attribution publiquement vérifiée. METR n’a pas identifié l’attaquant, le fournisseur de modèles ni l’infrastructure exacte de découverte.

Après avoir obtenu l’identifiant, l’intrus l’a utilisé pendant trois semaines. METR a calculé que les crédits consommés auraient valu environ 600 000 dollars, bien qu’elle n’ait pas payé cette somme.

Le chiffre marquant de l’incident peut détourner l’attention de la chaîne de défaillances plus large. L’exposition publique, un identifiant accessible à un agent, un accès persistant à l’hôte et une visibilité incomplète sur l’utilisation devaient tous rester non résolus.

Chacun de ces contrôles aurait pu réduire les dégâts. L’authentification aurait pu refuser l’accès. L’isolation des identifiants aurait pu empêcher leur divulgation. La surveillance de l’hôte aurait pu détecter la nouvelle clé SSH. Les limites côté fournisseur auraient pu restreindre la consommation.

L’attaque a réussi parce que ces défenses n’ont pas arrêté la même séquence.

Pourquoi trois semaines d’abus de modèles ont ressemblé à de la recherche normale

La charge de travail habituelle de METR a généré suffisamment de bruit opérationnel pour masquer l’activité d’un attaquant.

METR évalue des systèmes d’IA avancés au moyen d’expériences pouvant consommer de grandes quantités de tokens. Les tokens sont des unités utilisées pour mesurer le texte traité ou généré par un modèle. Les grandes séries d’évaluation peuvent également déclencher des limitations de débit inhabituelles et des erreurs de fournisseurs.

Ce mode de fonctionnement a affaibli un signal de sécurité courant. Une forte utilisation ne semblait pas automatiquement malveillante, car les recherches légitimes de METR pouvaient produire un comportement similaire.

METR a indiqué que son tableau de bord interne n’affichait pas toutes les requêtes limitées de chaque utilisateur au moment de l’incident. Les enquêteurs ne disposaient donc pas d’une vision complète de l’activité associée au compte compromis.

L’organisation ne disposait pas non plus d’un plafond naturel de dépenses pour la clé concernée. Puisque le fournisseur de modèles fournissait les crédits sans facturer METR, une facture en hausse ne déclenchait pas d’enquête immédiate.

L’absence de facture ne rendait pas la ressource sans valeur. L’inférence de modèles consomme de la capacité de calcul, et l’accès à cette capacité peut être revendu ou utilisé pour des charges de travail sans rapport. L’attaquant a obtenu un avantage économique transférable, même si METR a évité un paiement en espèces.

Une couverture indépendante de la chronologie rapportée a souligné la même lacune de surveillance. La consommation illicite s’est fondue dans un environnement déjà habitué à des volumes élevés de tokens et à des messages incohérents de limitation de débit.

C’est le renversement central dans les incidents de sécurité chez METR. L’échelle aide habituellement un groupe de recherche à tester des modèles capables, mais cette même échelle rendait la consommation anormale plus difficile à distinguer.

Les alertes de dépenses traditionnelles peuvent révéler rapidement un identifiant cloud volé. Toutefois, les crédits offerts, les allocations de recherche et les capacités prépayées peuvent affaiblir cette défense. Les organisations ont toujours besoin de limites fondées sur les schémas d’utilisation, les origines des requêtes, l’identité des clés et les charges de travail attendues.

Un seuil devrait également tenir compte des requêtes échouées et limitées par débit. Ces requêtes peuvent révéler une reconnaissance ou des tentatives de consommation, même lorsqu’elles n’apparaissent pas dans les totaux de facturation standard.

L’incident montre pourquoi le volume brut est une mesure incomplète. Un meilleur système de détection se demande si l’activité correspond à la finalité établie de la clé.

Un identifiant attribué à une expérience ne devrait pas prendre discrètement en charge un trafic sans rapport pendant des semaines. Des clés distinctes pour chaque application facilitent cette comparaison, car elles réduisent le nombre de comportements légitimes associés à une même identité.

Des identifiants de courte durée réduiraient davantage la fenêtre d’attaque. Une clé qui expire ou nécessite un renouvellement limite la durée pendant laquelle une valeur copiée reste utile. Les secrets de longue durée donnent aux attaquants davantage de temps pour établir une persistance et monétiser l’accès.

METR a réagi en ajoutant des alertes de dépenses lorsque les fournisseurs les prenaient en charge. L’organisation a également étendu la couverture de surveillance et travaillé à réduire les alertes bruyantes.

Ces changements traitent des symptômes visibles, mais la leçon plus profonde concerne les frontières du système. Une charge de travail de recherche ne devrait pas rendre une activité inexpliquée acceptable simplement parce qu’une utilisation inhabituelle se produit régulièrement.

Les opérations normales nécessitent des plages mesurables, des responsables désignés et des exceptions définies. Sinon, le « trafic de recherche » devient une catégorie trop large qui masque à la fois l’expérimentation légitime et la consommation non autorisée.

Le véritable conflit oppose l’expérimentation rapide à un accès cloisonné

Le développement d’agents récompense le déploiement rapide, tandis que la sécurité dépend de frontières strictes dont les prototypes sont souvent dépourvus.

METR a décrit le tableau de bord exposé comme vibe-coded, ce qui signifie qu’il a été développé en grande partie grâce à des prompts assistés par IA et à une génération itérative. Cette étiquette n’établit pas qu’un outil de codage IA ait causé le défaut d’authentification.

La question pertinente est la manière dont l’application résultante a été examinée et déployée. Le logiciel acceptait du trafic public, interagissait avec des agents et fonctionnait à proximité d’un identifiant actif de fournisseur. Ces conditions en faisaient davantage qu’un prototype local jetable.

L’expérimentation rapide est précieuse dans l’évaluation des modèles. Les chercheurs ont souvent besoin d’interfaces personnalisées, d’outils d’orchestration temporaires et de nouvelles combinaisons de modèles. Un long processus d’approbation peut entraver le travail exploratoire.

Toutefois, la catégorie de sécurité devrait dépendre de l’accès et de l’exposition d’un système, et non de sa durée de vie prévue. Une application temporaire acquiert des caractéristiques de production dès lors qu’elle est accessible depuis internet et détient des identifiants réutilisables.

L’agent n’aurait pas non plus dû pouvoir divulguer la clé brute. Les applications ont couramment besoin d’une autorisation pour appeler des services externes, mais cela ne nécessite pas de placer un secret réutilisable dans le contexte lisible par le modèle.

Un courtier d’identifiants peut effectuer une requête autorisée au nom d’un agent sans révéler la clé sous-jacente. Des capacités à portée restreinte peuvent également limiter les modèles, les opérations ou les niveaux d’utilisation auxquels l’application peut accéder.

Cette séparation est importante, car les modèles de langage traitent des instructions non fiables. Un attaquant qui atteint une interface d’agent peut demander au modèle d’exposer des données cachées, de détourner des outils connectés ou d’effectuer des actions allant au-delà du flux de travail prévu par l’application.

Les conseils de sécurité pour les agents d’OWASP identifient l’exposition de données sensibles, les permissions excessives, l’abus d’outils et l’injection de prompts comme des risques connexes. Ils recommandent de limiter les privilèges et de conserver les identifiants hors du contexte accessible aux agents.

La divulgation de METR indique que l’attaquant a directement incité un agent à révéler sa clé de fournisseur. Cela ressemble à une extraction d’identifiants fondée sur des prompts, mais les éléments publics ne décrivent pas le comportement du modèle avec suffisamment de détails pour permettre une classification formelle.

Le défaut d’authentification demeurait toutefois la première défaillance décisive de contrôle. Sans accès public, le tiers n’aurait pas disposé d’une interface par laquelle émettre la requête.

Qualifier l’événement uniquement d’attaque par injection de prompts le simplifierait donc à l’excès. Le chemin de perte combinait un déploiement non sécurisé, l’exposition de secrets, un accès permissif aux agents, la persistance et une surveillance insuffisante de la consommation.

De même, attribuer la faute au seul vibe coding ignorerait les pratiques de sécurité établies qui s’appliquent indépendamment de la manière dont le code a été produit. Les prototypes écrits par des humains peuvent eux aussi échouer en mode fail-open, exposer des secrets et omettre la télémétrie.

METR disposait déjà de contrôles de sécurité documentés pour sa plateforme d’évaluation de production. Son rapport SOC 2 publié décrivait des contrôles conçus en août 2025 pour ce système défini.

Un rapport SOC 2 Type I évalue la conception des contrôles à un moment donné. Il ne garantit pas que chaque expérience personnelle, service temporaire ou déploiement ultérieur respecte les mêmes contrôles.

Cette distinction se trouve au cœur de l’incident. Les organisations peuvent sécuriser leur plateforme principale tout en laissant les chercheurs créer une infrastructure parallèle au-delà de sa frontière formelle.

Les comptes cloud personnels rendent cette fragmentation plus difficile à percevoir. Les équipes de sécurité centrales peuvent ne pas disposer des journaux, de l’inventaire, des contrôles réseau et de l’application automatisée des politiques pour les instances créées hors des environnements gérés.

METR a indiqué que le chercheur n’avait pas accès à ses deux catégories de sensibilité les plus élevées. Cela a limité le rayon d’impact apparent. Pourtant, l’instance contenait toujours une information d’identification de fournisseur qui valait la peine d’être ciblée.

La leçon n’est pas que l’expérimentation doit s’arrêter. C’est que l’exposition à Internet et les identifiants actifs doivent automatiquement déclencher un examen de référence, même pour un outil de recherche de courte durée.

Une deuxième attaque a mis les données d’évaluation en danger

La campagne de mai a montré que les attaquants ne s’intéressaient pas uniquement à de la puissance de calcul bon marché ; ils exploraient aussi des voies vers l’accès à des modèles non publics et à des données d’évaluation.

Début mai 2026, METR a appris que des pirates ciblaient son infrastructure publique. L’organisation les a considérés comme motivés par des raisons financières et a indiqué qu’ils cherchaient peut-être à accéder à des modèles de pointe.

METR a observé une exploration systématique incluant du credential stuffing, des tentatives d’attribution OAuth, des analyses de services nouvellement déployés et des tentatives de phishing visant le personnel. Le credential stuffing consiste à tester sur d’autres services des combinaisons d’identifiants précédemment volées.

L’organisation a déclaré que les attaquants utilisaient massivement des agents pour automatiser la découverte de vulnérabilités. Cette affirmation suggère que l’IA a réduit l’effort nécessaire pour analyser plusieurs services et parcours d’authentification, bien que METR n’ait pas publié de mesures de performance.

Au cours de la même période, METR avait involontairement exposé un mécanisme de requêtes SQL en lecture seule via son lecteur public de transcriptions. SQL est un langage que les applications utilisent pour récupérer des informations dans des bases de données structurées.

Les requêtes étaient censées renvoyer par défaut des enregistrements publics. Un bug pouvait modifier ce périmètre et exposer des données d’évaluation non publiées.

METR s’attendait à ce que la base de données sous-jacente ne contienne que des résultats impliquant des modèles publics. Toutefois, certaines sorties de modèles sensibles y avaient été incluses accidentellement.

Un chercheur indépendant en sécurité a découvert la faille et l’a signalée de manière responsable. METR a mis l’API concernée hors ligne et versé une récompense.

Les attaquants avaient sollicité le point de terminaison lors de l’analyse de l’infrastructure de METR. L’organisation affirme que ses éléments de preuve n’indiquent pas qu’ils aient découvert l’exploit ou accédé à des informations non publiques.

Cette conclusion exige une formulation prudente. L’absence de preuve ne constitue pas une démonstration mathématique qu’aucun accès n’a eu lieu. Elle reflète ce que METR et son consultant en sécurité ont trouvé dans les journaux disponibles et les éléments d’analyse forensique.

METR a expliqué que l’exploitation exigeait plusieurs étapes précises. Un attaquant devait découvrir le bug de périmètre, l’utiliser correctement, identifier des transcriptions sensibles et les télécharger sans déclencher d’erreurs.

L’organisation a considéré cette séquence comme très improbable. Elle a également reconnu une complication : elle a temporairement supprimé le point de terminaison, puis l’a restauré sans remarquer le bug, sans constater par la suite d’accès par les attaquants.

Ce deuxième épisode soulève des enjeux différents de ceux des crédits volés. Des évaluations non publiées peuvent révéler des faiblesses de modèles, des schémas comportementaux, des sorties cachées ou des informations fournies dans le cadre d’accords de confidentialité.

METR répartit ses informations en quatre grandes catégories. Les contenus publiés se situent au niveau le plus bas. Les identifiants de modèles publics et les résultats non publiés de modèles publics occupent la catégorie suivante.

Les deux catégories supérieures couvrent l’accès à des modèles sensibles et des informations organisationnelles hautement sensibles. METR indique que son enquête n’a révélé aucun accès à des informations relevant de ces catégories lors de l’un ou l’autre incident.

Pourtant, la base de données de transcriptions contenait des éléments relevant d’une catégorie supérieure alors qu’elle n’aurait pas dû. Cela signifie que la limite de classification prévue avait déjà échoué avant que quiconque tente d’exploiter le mécanisme de requête.

Séparer les données par politique ne suffit pas si des enregistrements peuvent entrer dans la mauvaise base de données. Une isolation efficace nécessite aussi des contrôles automatisés de classification, des contrôles d’accès au moment de la requête et des journaux préservant des preuves pour les enquêtes ultérieures.

Le premier incident a exposé une frontière liée aux identifiants. Le second a exposé une frontière liée aux données. Tous deux impliquaient des systèmes de recherche accessibles au public, plus proches de ressources précieuses que ne le justifiaient leurs rôles prévus.

La réponse de METR réduit le risque, mais laisse des questions de vérification

METR a modifié son architecture et son processus de sécurité, mais les observateurs externes ne peuvent pas encore mesurer avec quelle cohérence ces contrôles couvriront les futures expérimentations.

Après avoir détecté l’abus de mars, METR a révoqué l’accès du chercheur et arrêté l’instance compromise. L’organisation a créé une image forensique, fait tourner les identifiants, imagé puis effacé l’ordinateur portable du chercheur, et informé l’entreprise de modèles concernée.

Le cabinet de conseil en sécurité Calif a examiné les conclusions de METR et mené une évaluation distincte de compromission. METR a également eu recours à des investigations forensiques manuelles et assistées par agent pour examiner l’incident.

L’organisation indique que ces efforts n’ont trouvé aucune compromission au-delà de la seule clé d’API de modèle public. Elle n’a pas publié l’évaluation complète du consultant, des indicateurs de compromission détaillés ni l’identité du fournisseur.

METR a étendu ses politiques concernant les identifiants et les données sur les infrastructures personnelles. L’organisation a également créé un examen de sécurité formel pour les chercheurs déployant des applications publiques.

À la suite de la campagne de mai, METR a temporairement désactivé presque tous les services accessibles au public ainsi que l’accès interne aux données sensibles. Elle a ensuite créé un environnement de production public isolé, séparé sur le plan architectural de l’infrastructure interne.

Cette séparation répond directement au risque lié au lecteur de transcriptions. Si elle est appliquée de manière cohérente, un défaut dans une application publique ne devrait plus offrir de voie vers un système de données interne.

METR a également arrêté son infrastructure historique, renforcé la journalisation, raccourci la durée de vie des identifiants, réduit les périmètres d’autorisation et déployé davantage de logiciels de sécurité pour les terminaux et les serveurs.

L’organisation a recruté un responsable de la sécurité et indiqué qu’elle prévoyait d’agrandir davantage l’équipe. Elle a aussi commandé des travaux supplémentaires de red teaming, où des testeurs autorisés simulent le comportement d’attaquants afin de repérer des faiblesses.

Ces mesures correspondent aux modes de défaillance divulgués. Elles améliorent l’inventaire, le confinement, la gestion des identifiants, la télémétrie et la responsabilité.

La question sceptique porte sur la couverture. Les politiques et les environnements centralisés ne fonctionnent que si les chercheurs ne peuvent pas les contourner via des comptes cloud personnels, des services non gérés ou des identifiants copiés dans des outils expérimentaux.

METR n’a pas publié d’objectifs mesurables concernant cette couverture. Les lecteurs ne savent pas quel pourcentage des déploiements publics reçoit désormais un examen ni à quelle vitesse une utilisation anormale de clé déclenche une enquête.

Il reste également incertain de savoir quels contrôles opèrent au niveau du fournisseur de modèles. Les alertes de dépenses aident, mais des plafonds d’utilisation stricts, des jetons de courte durée, des périmètres plus restreints et une révocation automatique offrent des limites plus solides.

Tous les fournisseurs de modèles n’exposent pas les mêmes contrôles. METR a noté qu’elle ne pouvait pas fixer de limite de dépenses sur la clé concernée lorsque l’incident de mars s’est produit.

Le fournisseur partage donc une part du problème de conception plus large, même si METR contrôlait l’application exposée. Les organisations qui gèrent un accès précieux à des modèles ont besoin de fonctionnalités de compte supposant que les clés finiront par fuiter.

La divulgation elle-même mérite d’être saluée. METR a publié une séquence détaillée, reconnu plusieurs défaillances internes et distingué l’exposition possible des preuves d’accès réel.

Toutefois, la transparence ne doit pas être confondue avec une vérification indépendante. Les conclusions centrales proviennent toujours de l’enquête de METR et de son consultant mandaté.

Aucun élément public n’identifie les attaquants ni ne confirme leurs motivations. L’évaluation à 600 000 $ représente également la valeur approximative des crédits accordés, et non une facture payée ou une perte vérifiée par un audit indépendant.

Ces réserves n’effacent pas l’incident. Elles définissent ce que les éléments de preuve disponibles permettent d’étayer et empêchent que le chiffre du titre ne paraisse plus précis que les faits.

Ce que les équipes de sécurité devraient surveiller après la divulgation de METR

Le prochain test sera de savoir si les nouveaux contrôles de METR produisent des limites visibles, une détection plus rapide et des systèmes de recherche publics plus sûrs.

Le premier signal concerne l’application des règles autour des déploiements publics. METR a formalisé les examens de sécurité, mais la valeur de cette politique dépend du fait que chaque expérimentation exposée à Internet entre dans un inventaire géré.

Un résultat utile inclurait la découverte automatisée de nouveaux domaines, instances cloud et points de terminaison publics associés à l’organisation. Les équipes de sécurité devraient comparer cet inventaire aux applications approuvées et aux responsables désignés.

Si les futurs outils de recherche s’exécutent systématiquement dans l’environnement public isolé, la réponse de METR étayera son affirmation selon laquelle les frontières architecturales se sont améliorées. Un autre déploiement personnel contenant des identifiants actifs affaiblirait cette conclusion.

Le deuxième signal est le confinement mesurable des identifiants. METR a ajouté une surveillance de l’utilisation et des alertes de dépenses lorsque cela est possible, mais les alertes exigent toujours une interprétation et une réponse.

Les organisations devraient rechercher des durées de vie d’identifiants plus courtes, des clés propres à chaque application, des autorisations de fournisseur limitées et une suspension automatique après une activité anormale. Les identifiants bruts doivent rester inaccessibles au contexte de prompt et au canal de sortie d’un agent.

La présentation par OWASP des risques liés à l’injection de prompt explique pourquoi les seules instructions au modèle ne peuvent pas protéger un secret. Un attaquant peut manipuler un modèle exposé afin qu’il ignore les restrictions prévues ou révèle des informations disponibles dans son contexte.

Si METR ou ses fournisseurs adoptent un accès intermédié et des limites strictes de consommation, une compromission similaire de l’interface devrait entraîner une perte plus faible. Si les contrôles restent principalement fondés sur les alertes, les attaquants pourraient encore opérer jusqu’à ce qu’une personne reconnaisse le schéma.

Le troisième signal concerne les preuves de séparation des données. METR affirme que son nouvel environnement public est isolé sur le plan architectural, mais le problème de mai impliquait aussi le placement d’enregistrements sensibles dans la mauvaise base de données.

L’isolation réseau ne corrigera pas à elle seule les informations mal classifiées. METR a besoin de garde-fous qui détectent les données d’évaluation restreintes avant qu’elles n’entrent dans un stockage accessible au public.

De futures divulgations, audits ou mises à jour techniques devraient montrer si ces contrôles empêchent à la fois l’accès direct et le placement accidentel de données. Une évaluation externe concluante renforcerait la confiance dans la frontière révisée.

Les incidents de sécurité de METR donnent également aux entreprises d’IA une raison de revoir la manière dont elles fournissent l’accès aux évaluations. Les évaluateurs externes ont besoin de capacités de modèles réalistes, mais des identifiants étendus et durables créent des cibles attrayantes.

Les fournisseurs peuvent réduire ce risque grâce à des jetons à périmètre limité, des limites par projet, des restrictions d’origine, une révocation rapide et une visibilité sur les requêtes rejetées. Ces fonctionnalités protègent à la fois le fournisseur et l’évaluateur.

Les développeurs devraient appliquer le même raisonnement aux petits projets d’agents. Un prototype pouvant accéder aux e-mails, au code source, aux services cloud ou aux documents internes possède déjà une frontière de sécurité significative.

Les équipes documentant ces expérimentations peuvent utiliser une base de connaissances contrôlée afin de préserver les modèles de menace, les responsables des déploiements, les décisions d’examen et les leçons tirées des incidents. La documentation ne peut pas remplacer les contrôles techniques, mais elle peut rendre les exceptions non gérées plus faciles à repérer.

La question la plus utile n’est pas de savoir si une application a été développée en vibe coding. Elle consiste à déterminer si un utilisateur non fiable peut y accéder, aux identifiants auxquels elle peut accéder, et ce qui se passe lorsque chaque instruction est traitée comme hostile.

La divulgation de METR apporte une réponse rare et concrète. Une défaillance d’authentification publique a atteint un agent, l’agent a exposé un identifiant, et une surveillance incomplète a permis trois semaines d’utilisation non autorisée.

Les responsables de la sécurité devraient désormais tester cette même chaîne dans leurs propres systèmes. Un utilisateur externe peut-il découvrir l’interface ? Le modèle peut-il révéler un secret ? L’hôte peut-il accepter un accès persistant ? Une consommation anormale peut-elle se fondre dans le trafic attendu ?

Si l’une de ces réponses est oui, l’absence d’incident en cours reflète davantage une question de calendrier qu’une réelle maîtrise de la situation. La prochaine mise à jour de METR devrait montrer si sa nouvelle architecture a transformé des leçons chèrement acquises en limites applicables.