Une clé API oubliée, 600 000 $ brûlés

Ce qui se passe

METR — Model Evaluation and Threat Research, l'association qui évalue les modèles de pointe sur les tâches agentiques longues — a publié le récit de deux incidents de sécurité. Aucune donnée sensible n'aurait été atteinte, et aucun n'implique un agent qui se serait échappé de ses évaluations. Le premier vaut pour tout le monde.

L'incident de mars 2026

Un chercheur sans accès sensible faisait tourner des agents sur une instance EC2 personnelle, volontairement accessible depuis Internet mais protégée par une authentification Google. L'instance contenait une clé d'API du compte « accès général » de METR.

L'application, que METR qualifie elle-même de vibe-coded, souffrait d'une faille fail-open : en cas d'erreur, l'authentification se désactivait silencieusement au lieu de refuser l'accès. Le tableau de bord d'orchestration des agents est resté ouvert au public pendant plusieurs jours.

La suite, dans l'ordre :

1. L'attaquant demande directement à l'agent de révéler sa clé d'API.
2. Il ajoute une clé SSH pour garder l'accès.
3. Il consomme des crédits sur les modèles publics pendant trois semaines.

Facture qui aurait été due : environ 600 000 $ — METR ne l'a pas payée, le fournisseur lui offrant ces crédits. Le fournisseur n'est pas nommé.

Le détail le plus instructif

C'est la méthode de découverte. METR soupçonne l'attaquant d'avoir parcouru les journaux de transparence des certificats pour repérer les domaines fraîchement enregistrés dont le nom contient des mots-clés liés aux LLM et aux agents — puis d'être allé y chercher des clés de fournisseurs exposées.

Autrement dit : publier un outil interne sur un sous-domaine appelé agents.monprojet.dev le rend découvrable dans les minutes qui suivent l'émission du certificat, sans qu'aucun lien n'existe nulle part.

L'abus n'a rien déclenché parce que METR consomme normalement de gros volumes de tokens et qu'aucun plafond de dépense n'était posé sur la clé.

L'incident de mai 2026

Une campagne soutenue, attribuée à un acteur probablement motivé par l'argent : sondage automatisé de l'infrastructure publique, bourrage d'identifiants sur les fournisseurs d'authentification, tentatives d'octroi de jetons OAuth, hameçonnage du personnel. En parallèle, un mécanisme de requêtes SQL en lecture seule, intégré au visualiseur public de transcriptions, était exposé par inadvertance — avec, par accident, des données de modèles sensibles dans la base. C'est un chercheur indépendant qui l'a signalé, pas la supervision interne.

À retenir

1. Poser des plafonds de dépense et des alertes sur chaque clé d'API de modèle. Une consommation habituellement élevée masque l'abus.
2. Vérifier qu'un échec d'authentification bloque au lieu d'ouvrir : le fail-open est le défaut par défaut des applications écrites vite.
3. Aucune clé d'organisation sur une infrastructure personnelle — c'est la règle que METR a ajoutée après coup.

Source : The Hacker News