LLMjacking : les clés d'IA volées coûtent cher

Deux publications récentes décrivent la même tendance sous deux angles. Le 2 novembre, le Google Threat Intelligence Group et Mandiant ont publié un rapport sur le LLMjacking, le vol d'accès aux modèles d'IA aux frais de la victime. Le 10 novembre, la plateforme d'hébergement Railway a publié son rapport d'incident d'octobre, avec un usage non autorisé de clés d'IA de clients estimé à environ 740 000 $ US. Les clés d'API d'IA sont devenues des secrets qui valent de l'argent comptant.

Ce qui s'est passé

Le rapport de Google. Selon le Google Threat Intelligence Group, des incidents ont généré des frais frauduleux de plus de 100 000 $ US en une seule journée, et des frais cumulés atteignant 1 million de dollars US dans certaines organisations avant la révocation de l'accès. Les points clés :

• L'accès initial. Le vecteur dominant est le vol de jetons d'identité infonuagiques : identifiants IAM, clés de comptes de service, jetons d'accès personnels GitHub et jetons de session. Certains acteurs récoltent aussi des clés d'API d'IA dans des dépôts GitHub publics.
• La revente. Google décrit des « LLM Mixers » qui regroupent et revendent l'accès volé. L'un d'eux, Jet Night, offrait un forfait illimité à environ 60 $ US par mois, et un acteur a fait plus de 500 000 appels en moins de huit heures, pour près d'un million de dollars US de frais transférés à une victime.
• La discrétion. Les attaquants valident les clés avec des requêtes minuscules, par exemple max_tokens=1, pour passer sous les seuils d'alerte.
• L'angle mort. Dans plusieurs incidents, les services d'IA n'étaient pas activés avant la compromission : les attaquants les ont activés avec les clés volées.

L'incident de Railway. Le rapport de Railway décrit une chaîne d'attaque du 20 au 21 octobre : sortie partielle de l'isolation d'une compilation, vol d'un identifiant de compilation, lecture de l'historique de 353 compilations, puis une liaison OIDC mal configurée qui donne des identifiants infonuagiques, et enfin le déchiffrement de variables de clients dont le nom correspondait à des clés de fournisseurs d'IA. Railway évalue à au plus 1,85 % des espaces de travail, environ 100 000, ceux dont les variables ont pu être déchiffrées. Les jetons de comptes liés de 1 852 utilisateurs ont été réinitialisés. Railway précise ne pas savoir si l'attaquant initial exploitait aussi les services qui ont ensuite utilisé les clés volées.

Les clés laissées dans le code. Le 7 novembre, The Hacker News a rapporté une étude d'Apiiro sur un fichier de réglages local de Claude Code qui enregistre en clair les commandes approuvées. Selon cet article, 1 122 copies publiques de ce fichier sur GitHub contenaient au moins un secret, dont des mots de passe de bases de données et des clés AWS.

Pourquoi ça compte

Une clé d'IA est un identifiant, pas un paramètre. Beaucoup d'équipes rangent la clé d'un fournisseur d'IA avec les réglages de l'application, pas avec les secrets. Les deux publications montrent qu'elle se vole, se revend et se monétise comme un mot de passe d'administrateur.

Le coût arrive avant l'alerte. Avec un minage clandestin, la facture monte lentement. Avec le LLMjacking, Google parle de pics en quelques heures. Une organisation qui découvre l'incident sur sa facture mensuelle l'apprend trop tard.

Le risque passe par les fournisseurs. Chez Railway, les clés ont été volées chez l'hébergeur, pas chez les clients. Selon The Hacker News, Railway a d'abord indiqué ne pas pouvoir rembourser les dépenses faites avec les clés compromises, puis s'est engagée à couvrir les frais quand un fournisseur d'IA refuse de le faire. Les politiques de remboursement varient d'un fournisseur à l'autre. Pour un client, la question de la responsabilité financière se pose donc au contrat, pas au moment de l'incident.

Les identités non humaines se multiplient. Comptes de service, jetons de pipeline, clés d'agents de codage : c'est le même problème que nous décrivions dans les identités non humaines, angle mort et dans les workflows GitHub Actions qui volent les secrets.

Ce que nous en pensons chez Sentrix

1. Plafonnez les dépenses dès aujourd'hui. Google recommande des quotas d'API par modèle et des plafonds de dépenses. Ajoutez une alerte de budget qui sonne chez la sécurité, pas seulement aux finances.
2. Inventoriez les clés d'IA. Qui les a créées, où elles sont stockées, à quel modèle et à quel environnement elles donnent accès. Google recommande de les segmenter par modèle, par environnement et par limite d'usage.
3. Centralisez et faites tourner les secrets. Un gestionnaire de secrets avec rotation automatique réduit la durée de vie d'une clé qui a fui. Ajoutez la détection de secrets dans le code et l'historique Git, y compris les dossiers des agents de codage.
4. Surveillez l'activation des services d'IA. Toute activation non prévue d'un service d'IA dans un compte infonuagique doit déclencher une alerte. Notre service sécurité infonuagique couvre ces journaux et ces règles.
5. Posez la question à vos fournisseurs. Comment l'hébergeur protège-t-il vos variables, qui peut les déchiffrer, qui paie en cas de vol ? Ces questions entrent dans l'évaluation des risques tiers.
6. Encadrez l'usage de l'IA. Les clés et les agents d'IA font partie de la gouvernance de l'IA, comme le décrit notre article sur ISO 42001 et le NIST AI RMF.

La prochaine étape

Ouvrez la console de facturation de chaque fournisseur d'IA et de nuage que vous utilisez, et vérifiez qu'un plafond et une alerte existent. Là où il n'y en a pas, la limite de votre exposition est celle de votre carte de crédit. Pour faire le tour avec nous, contactez-nous.