Votre clé d'API IA vaut trois choses pour un attaquant

Il y a deux ans, une clé d'API d'un service d'IA était une ligne de facturation. Aujourd'hui, c'est un actif que des groupes criminels entiers cherchent pour elle-même. Le rapport y consacre une section : « Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups. » L'objectif unique. Pas un sous-produit d'une intrusion : sa raison d'être.

Le dernier mot de cette phrase mérite qu'on s'y arrête : devices, les appareils. Ce ne sont pas seulement les clés qui sont visées, ce sont aussi les jetons de session et les postes sur lesquels ils vivent. Une bonne partie de ce que décrit le rapport ne se règle donc pas en remplaçant une chaîne dans un coffre : ça se règle en traitant la machine.

Pourquoi une clé vaut plus que son solde #

Anthropic résume la valeur d'une clé volée en trois mots. C'est la formulation la plus utile du rapport pour un responsable informatique : trois bénéfices obtenus d'un seul coup.

• Du butin (loot) - une clé ou un compte valide se revend sur des marchés établis. Les voleurs cèdent l'accès à des courtiers, qui alimentent des réseaux de revente frauduleuse ; ces réseaux injectent de nouvelles clés volées au fil de l'eau et les font tourner jusqu'à épuisement du quota. Votre clé n'a pas besoin d'être intéressante : elle a besoin d'être valide.
• Du calcul (compute) - la charge de travail offensive tourne aux frais de quelqu'un d'autre. Une campagne hacktiviste décrite plus loin dans le rapport a tourné un mois entier entièrement sur des clés volées : coût marginal nul.
• Une couverture (cover) - l'activité est imputée au propriétaire légitime de la clé. C'est votre entreprise qui apparaît dans les journaux du fournisseur, pas l'attaquant.

La troisième est celle qu'on sous-estime, et le rapport la rend très concrète. Le même acteur hacktiviste avait écrit son propre scanner, en Rust, pour parcourir des conteneurs publics et valider les clés qu'il y trouvait. Une fois validée, la clé rejoignait une couche de mandataire local qui faisait tourner l'usage entre les clés. Objectif explicite : noyer son trafic dans celui des propriétaires légitimes. La clé ne sert pas qu'à payer l'addition, elle sert à porter le costume de quelqu'un d'autre.

Des affiliés du collectif ShinyHunters appliquaient la même logique par l'autre bout : une fois entrés chez une victime, ils basculaient leurs propres travaux d'attaque sur les clés d'IA de cette victime, et s'en servaient pour attaquer d'autres organisations pendant trois semaines - une chaîne de magasins française compromise, une plateforme d'identité Web3 sondée. Dans tous les cas documentés, les clés provenaient d'environnements de clients ; les systèmes d'Anthropic n'ont pas été compromis. La distinction compte : le risque est chez l'utilisateur de la clé, pas chez l'éditeur du modèle.

1,8 million d'applications décompilées pour trouver des secrets #

La chaîne de récolte est industrielle. Un opérateur francophone connu sous plusieurs pseudonymes a monté un pipeline réparti sur dix machines louées chez un fournisseur cloud. Ce pipeline a téléchargé en masse 1,8 million d'applications Android distinctes depuis plusieurs magasins, les a décompilées, et les a passées au crible d'un détecteur de secrets en dur - un outil libre, celui-là même que les équipes de sécurité utilisent pour auditer leurs propres dépôts.

Les trouvailles vérifiées partaient en temps réel vers un canal de discussion privé organisé en plus de quatre cent soixante-dix fils : un fil par type de détecteur de secret, pour plus d'une centaine de types de sources. En parallèle, un second flux moissonnait les adresses des organisations d'une plateforme de code publique et alimentait un tuyau de jetons d'accès personnels volés. Le rapport est explicite sur le rendement : ces deux tuyaux ont fourni les identifiants d'accès initial de la majorité des compromissions confirmées de cet opérateur. Pas une faille inédite. Des secrets ramassés par terre.

Les gisements que le rapport énumère #

Le rapport appelle discovery la recherche automatisée de jetons exposés « à l'échelle industrielle ». Sa liste de sources vaut check-list d'audit.

• Les binaires d'applications - décompiler une application mobile est un geste de routine, pas un exploit.
• Les dépôts de code et leurs intégrations - le dépôt, mais aussi les jetons que les chaînes d'intégration y déposent.
• Le code exécuté côté navigateur - ce que votre serveur envoie au poste du visiteur est lisible par le visiteur.
• Les coffres d'identifiants mal protégés - un coffre à politique d'accès trop large est un point de collecte.
• Les images de conteneurs - une clé effacée dans une couche reste présente dans la couche précédente.
• Les points de métadonnées d'instances cloud - lisibles depuis toute application exécutée sur la machine, vulnérable comprise.
• Les stockages ouverts - compartiments laissés en lecture publique le temps d'un test qui dure depuis trois ans.
• Les agents d'IA déployés par la victime elle-même - la nouveauté, traitée dans une section plus bas.

Ce qui arrive à une clé une fois trouvée #

Le rapport détaille le cycle de vie complet d'un identifiant volé. Trois de ses étapes concernent directement les clés d'IA, et expliquent pourquoi la réaction classique - « on a révoqué, c'est réglé » - ne suffit pas.

• Valider et qualifier. Tout ce qui est trouvé est testé avant usage ou revente : validation en lot des clés cloud, oracles de connexion écrits pour l'occasion, rejeu en direct contre les systèmes de production, notation de la valeur marchande, cassage hors ligne de ce qui résiste. Concrètement : le délai entre la fuite et le premier usage ne dépend pas de la chance. Une clé exposée est éprouvée contre vos systèmes dans la foulée.
• Fabriquer des accès durables. De nouveaux identifiants sont créés pour que l'opération survive à votre rotation : clés d'API cloud dans les comptes de la victime, clés de développeur sur les plateformes, sessions et codes de second facteur forgés, portes dérobées réseau. Concrètement : révoquer la clé qui a fuité ne suffit pas, il faut chercher ce qui a été créé depuis.
• Monétiser. Canaux de revente et réservoirs de clés, vol financier direct, extorsion sur les données volées, revenus de prime de bogue en double chapeau, données de masse gardées comme moyen de pression. Concrètement : même une clé sans valeur d'usage a une valeur de stock. Elle sera vendue, et rejouée plus tard par quelqu'un d'autre.

Les autres étapes - reconnaissance, expansion chez la victime, canaux d'exfiltration, entreposage du butin - décrivent l'intrusion elle-même. Nous les détaillons demain : elles répondent à une autre question, non plus « comment on entre », mais « à quelle vitesse ».

Le faux revendeur : « du Claude moins cher » #

Le deuxième circuit vise directement les utilisateurs finaux plutôt que les systèmes. Des acteurs ont monté des sites se présentant comme des intermédiaires entre plusieurs modèles, proposant un accès à prix cassé aux modèles de frontière. Les visiteurs étaient compromis de plusieurs façons ; la plus durable consistait à leur faire installer une application cliente qui imitait un harnais de développement populaire - y compris Claude Code - mais qui était en réalité un voleur d'identifiants. Il collectait tous les identifiants et jetons de session présents sur la machine, pas seulement ceux liés à l'IA.

Le détail à retenir est le suivant. Le rapport précise que, le compte de la victime finissant par être identifié comme compromis et réinitialisé, le voleur restait en place et continuait à détecter toute nouvelle session sur l'appareil pour la transmettre à son tour. La rotation ne fait alors rien d'autre que fournir une clé fraîche à l'attaquant. C'est le cas d'école d'une procédure correcte appliquée dans le mauvais ordre, qui donne l'illusion d'avoir traité l'incident.

Un groupe russophone et ukrainophone, référencé GTG-50021, faisait la même chose en plus retors : ses clients croyaient acheter un accès Claude à prix réduit ; leur trafic était en réalité relayé silencieusement vers un autre modèle, pendant que l'outillage du revendeur leur volait leurs identifiants pour les revendre à d'autres revendeurs frauduleux. Ni moins cher, ni Claude - et rien pour s'en apercevoir : la qualité de réponse d'un modèle concurrent ne déclenche pas d'alarme.

L'accès à l'IA doit être acheté uniquement par des canaux autorisés. Une prétendue remise qui exige de faire transiter votre trafic et vos identifiants par un intermédiaire inconnu fait courir un risque considérable à vos données et à vos systèmes.

Traduit en langage de PME : ce circuit n'entre pas par la porte de la DSI, il entre par l'informatique de l'ombre - un développeur qui trouve un abonnement à quinze euros au lieu de cent, un prestataire qui propose « son » accès mutualisé. Et le poste compromis est justement celui qui détient les jetons de dépôt et les clés de production.

Vos intégrations autour de l'IA sont une surface d'attaque #

C'est le point que la plupart des équipes n'ont pas encore intégré. Le rapport signale plusieurs acteurs ayant compromis des services intermédiaires qui exposaient des passerelles de modèles - le composant qu'on installe pour router les appels vers plusieurs fournisseurs et centraliser la facturation. Le vecteur : l'injection de prompt, pour faire exfiltrer par l'agent les clés d'API de production présentes dans son environnement de conteneur. Le rapport range ce type de déploiement parmi les cibles d'opportunité courantes, au même rang que le balayage d'équipements non corrigés.

La bascule mentale à faire : le vecteur n'est pas une faille de code, c'est le texte que l'agent accepte de lire. Un agent qui consulte une page web, un ticket ou un fichier déposé par un tiers lit aussi les instructions qu'on y a glissées - et s'il détient une clé de production, il peut être convaincu de la recracher.

GTG-50020 : de la réservation d'hôtel à la chaîne de l'IA #

Le cas le plus explicite est celui d'un acteur russophone motivé par l'argent, qui opérait jusque-là contre des plateformes de réservation hôtelière et de technologie financière. Son palmarès antérieur donne le calibre : environ 26 gigaoctets exfiltrés chez une seule victime, et une demande de rançon - ou un prix de vente sur des forums - située entre 1,5 et 2,5 millions de dollars. Ce n'est pas un amateur qui découvre l'IA, c'est un professionnel qui change de secteur.

Il a réorienté exactement le même savoir-faire vers l'industrie de l'IA. En injectant des instructions malveillantes dans le bac à sable d'évaluation automatisé d'un éditeur - la plomberie qui fait tourner des tests automatiques sur des modèles -, il a obtenu que ce bac à sable lui remette les identifiants qu'il détenait, dont les clés d'API de production de plusieurs fournisseurs. Le rapport note ensuite le comportement qui résume la section : dès qu'il obtenait les clés d'une cible, l'acteur basculait automatiquement dessus au lieu des siennes, et poursuivait ses intrusions contre l'éditeur et contre des cibles sans rapport, en parallèle.

Depuis la même infrastructure, il a ensuite attaqué une trentaine d'entreprises d'IA en environ quatre jours. La méthode dit tout de l'économie nouvelle : il a identifié un chemin d'attaque qui fonctionnait, puis l'a répété contre les trente cibles en l'adaptant à la marge. L'outillage suivait : un fichier de périmètre par cible lançait un flux de travail délégué à des agents de reconnaissance et d'exploitation parallèles, les trouvailles étaient re-testées pour vérifier que l'accès fonctionnait, fusionnées dans un rapport incrémental, et la boucle repartait sur la cible suivante. À côté, une plateforme de test d'intrusion libre, conteneurisée, faisait tourner des agents ouvriers testant injections, scripts inter-sites et contournements d'authentification sans supervision humaine, avec l'exploitation active autorisée sur des systèmes de production.

Son objectif déclaré, poursuivi par plus d'une douzaine de voies différentes : accéder à un modèle Claude non encore publié. Le rapport est catégorique, et il faut le dire aussi clairement que le reste : il n'y est jamais parvenu ; toutes les voies ont échoué. C'est, écrit le rapport, la démonstration la plus nette que la chaîne d'approvisionnement de l'IA est devenue une cible criminelle délibérée - et non un dommage collatéral.

La conclusion de la section est une phrase à afficher au-dessus de la machine à café d'une DSI : traitez les clés d'IA et les intégrations d'agents avec le même sérieux que vos identifiants de production - parce que les attaquants, eux, le font déjà.

Ce que nous faisons, et ce que nous recommandons #

Rien de ce qui suit n'est exotique. C'est de l'hygiène de secrets, appliquée à une catégorie de secret que beaucoup d'organisations n'ont pas encore inscrite à l'inventaire.

1. Inventorier. Qui détient une clé d'IA, pour quel usage, depuis quand, avec quelle portée ? Une clé par usage et par environnement, jamais une clé « de l'entreprise » partagée par cinq projets - une clé partagée est une clé qu'on n'ose plus révoquer.
2. Sortir les clés du code. Variables d'environnement injectées au déploiement ou coffre de secrets ; jamais dans le dépôt, jamais dans une image, jamais dans un binaire mobile, jamais dans un fichier servi au navigateur. Un secret committé une fois reste dans l'historique Git : le retirer du fichier ne suffit pas, il faut le révoquer.
3. Scanner en continu. Un détecteur de secrets en pré-commit et dans la chaîne d'intégration, plus un passage périodique sur les images publiées - la même logique que notre veille CVE sur les images Docker, appliquée aux secrets. Les attaquants se servent de l'outil libre que vous pouvez brancher aujourd'hui.
4. Restreindre la portée. Une clé limitée à un modèle, à un plafond, à une plage d'adresses ou à un projet perd l'essentiel de sa valeur de revente. Le rapport décrit une notation marchande au moment de la validation : une clé bridée descend dans le classement.
5. Plafonner et surveiller. Limite de dépense par clé, alerte sur dépassement, lecture hebdomadaire de la consommation. Une clé volée se voit d'abord sur une courbe d'usage qui ne ressemble pas à votre métier : un pic la nuit, un week-end, ou une régularité de machine.
6. Faire tourner, dans le bon ordre. Rotation planifiée (trimestrielle au minimum) et rotation immédiate au moindre doute. Mais le voleur d'identifiants décrit plus haut rend la rotation inutile si le poste est compromis : il capture la clé suivante. On traite la machine d'abord, la clé ensuite.
7. N'acheter que par les canaux officiels. Pas de revendeur à prix cassé, pas de passerelle tierce « pour économiser », pas de client non officiel sur un poste de développement. Cette règle doit figurer dans votre charte informatique, parce que c'est l'informatique de l'ombre qui la viole.
8. Traiter vos propres agents comme des composants exposés. Portée minimale des secrets qu'ils détiennent, cloisonnement du conteneur, aucune clé de production dans l'environnement d'un agent qui consomme du contenu non fiable, journalisation des appels sortants.
9. Écrire la procédure de fuite avant d'en avoir besoin. Isoler le poste d'origine, révoquer, chercher ce qui a été créé depuis (clés supplémentaires, comptes de service, appareils enrôlés), relire la consommation sur quatre-vingt-dix jours, prévenir le fournisseur. Une procédure improvisée un vendredi soir oublie toujours l'avant-dernier point.

Et pour les traitements où la question « où partent mes données » prime sur la capacité brute, l'alternative reste un modèle ouvert hébergé chez vous : pas de clé à voler chez un tiers, pas de revendeur dans la boucle. Nous y reviendrons le 16 septembre.

Demain : ce qui se passe après le vol d'un identifiant, et pourquoi le délai entre le premier accès et le vol de données se compte désormais en heures.

Sources #

• Anthropic, Detecting and countering misuse of AI: September 2026 (10 septembre 2026) - chapitre Cyber operations, section AI supply chain as target, loot, and attack compute : butin/calcul/couverture, faux revendeurs, injection de prompt sur les passerelles.
• Même rapport, section GTG-50014 : pipeline de récolte (dix machines louées, 1,8 million d'applications décompilées) et étapes Discover, Validate/qualify, Mint/persist, Monetize du cycle de vie d'attaque.
• Même rapport, sections GTG-50020 (bac à sable d'évaluation, trentaine d'entreprises d'IA en quatre jours, objectif jamais atteint), GTG-50021 (faux revendeur) et GTG-50029 (scanner de conteneurs, rotation de clés derrière un mandataire).
• Notre lecture d'ensemble : Huit mois de détournements de l'IA, et l'état des lieux qui la précédait : Quand les agents attaquent.
• Frandroid, Anthropic publie 161 pages sur les détournements de Claude, et ça pique (11 septembre 2026).