Les clés d'API LLM sont des identifiants de facturation

Une clé d’API de modèle de langage qui fuit ne donne pas accès à votre base de données. Elle donne accès à votre facture. La distinction paraît rhétorique jusqu’au jour où le relevé arrive.

Ce que la campagne facture

Google a publié une alerte sur des campagnes de LLMjacking : des attaquants récupèrent des clés d’API de modèles et lancent des inférences sur le compte de la victime. BleepingComputer résume l’ordre de grandeur dans son titre, 1 million de dollars de frais cloud IA. Je ne connais ni le détail de la campagne ni les victimes, et je ne vais pas les inventer. Le mécanisme suffit : la clé volée ne sert pas à lire quelque chose chez vous, elle sert à consommer.

C’est la différence avec un secret applicatif classique. Un mot de passe de base de données volé se traduit par une exfiltration, un accès, une modification. Une clé de modèle volée se traduit par une ligne sur un relevé. Rien n’est cassé, rien n’est indisponible, et le service continue de répondre normalement pendant que le compteur tourne.

Un identifiant de facturation avant d’être un secret

Traiter cette clé comme un secret de configuration, c’est-à-dire comme une valeur qu’on met dans un fichier, qu’on injecte au déploiement et qu’on oublie, passe à côté de la nature du problème. Un secret de configuration est protégé par le contrôle d’accès au fichier. Un identifiant de facturation est protégé par ce qu’il permet de dépenser.

La conséquence est pratique. Les contrôles qui existent déjà (rotation, portée restreinte, alertes de budget, quotas par service, journalisation des usages) ne valent que s’ils sont pensés pour un objet qui engage de l’argent. Une alerte de budget qui se déclenche quand le plafond mensuel est presque atteint n’aide pas si la consommation se fait en une nuit. Une rotation trimestrielle ne sert à rien si la clé reste valide après avoir quitté le dépôt.

Ce que je fais dans mes projets

Trois mesures, que je présente comme une base et pas comme une architecture de sécurité.

Une clé par service. Pas une clé partagée entre le backend, le worker et le script d’administration. Si le worker fuit, je révoque le worker, et je sais ce qu’il a consommé.

Jamais en dur. Les clés vivent dans l’environnement ou dans un gestionnaire de secrets, jamais dans le dépôt, jamais dans un fichier de configuration versionné. C’est la règle la plus facile à tenir, et celle qu’on casse le plus vite en debug un vendredi soir.

Budgets plafonnés. Sur ma plateforme, les comptes sont multi-tenant avec des quotas, et le plafond est une propriété du compte, pas une recommandation. Un plafond dur transforme une fuite en incident court au lieu d’un incident long.

Ce qu’il faut faire avant d’être trouvé

Révoquer avant de chercher. Si une clé a pu être exposée, la révocation passe avant l’analyse. Chercher l’origine d’une fuite pendant que la clé reste active, c’est financer l’enquête.

Séparer les clés par environnement et par service, avec un plafond par clé. Une clé de staging qui peut dépenser le budget de production est une erreur de conception, pas un accident.

Journaliser les usages côté fournisseur et côté application, puis comparer. Le fournisseur dit ce qui a été consommé, votre application dit ce qu’elle a demandé. L’écart est le signal.

Mettre l’alerte sur la consommation, pas sur le budget. Un pic en une heure est visible. Un pourcentage de budget ne l’est pas.

Là où ça ne s’applique pas

Cette approche a une limite, et je préfère la nommer. Le plafond dur protège la facture et casse le service : quand le quota est atteint, la fonctionnalité s’arrête pour tout le monde, y compris pour les utilisateurs légitimes. Sur un produit où l’appel au modèle est le cœur de l’expérience, un plafond bas est une panne programmée. Il faut choisir entre la facture plafonnée et la disponibilité, et ce choix se fait avec le produit, pas dans le fichier de configuration.

Deuxième limite : je n’ai aucun chiffre sur ce que ces mesures évitent. Je n’ai pas mesuré de baisse d’incidents, parce qu’il n’y a pas eu d’incident de ce type à mesurer. Une règle qui n’a jamais servi n’est pas prouvée, elle est seulement en place.

Source : Google LLMjacking attacks rack up $1 million in cloud AI charges, BleepingComputer.