LLMjacking : éviter de payer l’IA d’un attaquant (check-list sécurité à Lyon)

Tu paies déjà des tokens. La question, c’est: est-ce que c’est toi qui les consommes ?

À Lyon comme ailleurs, les équipes DSI et DevOps ont mis des API de LLM dans des apps, des scripts, des agents, des workflows. Et ça facture au token. Problème: si une clé fuit, quelqu’un peut consommer à ta place. Très vite. Très cher.

Ce scénario porte un nom: LLMjacking. Mandiant (Google Threat Intelligence) décrit des incidents où des attaquants détournent l’accès à des modèles (via API, comptes cloud, passerelles) et monétisent en revendant l’accès ou en faisant tourner des volumes industriels d’appels. Source: Google Cloud Threat Intelligence, billet “LLMjacking: monetizing compromised cloud models” (cloud.google.com).

Et ce n’est pas un “petit” dépassement. Sysdig rapporte des pertes à plus de 100 000 dollars par jour, avec un cas à 30 000 dollars en 3 heures sur du “AI resource jacking”. Source: Sysdig 2024 Threat Report (sysdig.com). Mandiant évoque aussi des factures “massives en quelques heures”, jusqu’à près d’1 million de dollars de coûts de tokens dans un cas rapporté (cloud.google.com).

Objectif de cet article: te donner un décryptage opérationnel (mécanismes, signaux d’alerte) et une check-list de contrôles orientée run. D’abord ce que tu peux faire en 48 h pour couper l’hémorragie. Puis un durcissement en 30 jours.

LLMjacking: définition opérationnelle (et pourquoi ça vise la facture)

Le LLMjacking désigne l’abus de ressources IA (API de modèles, gateways type proxy, comptes cloud) à partir de secrets volés (clé API, identifiants cloud, jetons), afin de faire porter la facture à la victime, et parfois de revendre l’accès. Source: Mandiant/Google (cloud.google.com).

Ce n’est pas “juste” du vol de données. C’est souvent une fraude au coût, proche du cryptojacking dans la logique: tu fournis le compute et le paiement, l’attaquant encaisse la valeur.

Pourquoi c’est un risque concret pour les entreprises à Lyon

Parce que beaucoup d’usages sont “branchés” vite: POC devenus prod, intégrations SaaS, automatisations, scripts internes. Et parce que les clés d’API sont souvent gérées comme des mots de passe de dev: copiées, exportées en variables d’environnement, stockées dans un wiki, injectées dans un conteneur.

Ajoute à ça un contexte où les organisations veulent limiter le “shadow AI”. Si tu veux cadrer ces usages, tu peux aussi lire: Shadow AI en entreprise : détecter et cadrer les usages IA non autorisés (checklist RSSI Lyon).

Les 3 scénarios d’attaque à connaître (ceux qui font exploser les tokens)

1) Vol de secrets: une clé suffit

Le cas le plus fréquent. Une clé d’API LLM fuit, et l’attaquant lance des scripts d’appel en rafale. Les fuites typiques: dépôts git, variables d’environnement, pipelines CI/CD, images de conteneurs, poste dev, outils SaaS. Source: Auth0, “LLMjacking: stolen API key, hidden cost” (auth0.com).

Point clé: ce n’est pas ton app qui est forcément compromise. Parfois c’est juste ton secret qui est déjà dehors.

2) Compte cloud compromis et “compute détourné” jusqu’aux API LLM

Mandiant cite des compromissions via des service accounts mal configurés, puis une extension d’accès vers les API de modèles. Source: Google Cloud Threat Intelligence (cloud.google.com).

Là, tu ne subis pas seulement une surconsommation LLM. Tu as aussi un risque de rebond: accès à d’autres ressources cloud, logs, stockage, secrets manager si c’est mal segmenté.

3) Compromission d’une gateway/proxy LLM (ex: LiteLLM)

Beaucoup d’équipes centralisent plusieurs fournisseurs via une passerelle (proxy) pour gérer routage, clés virtuelles, quotas, observabilité. C’est pratique. Donc c’est une cible.

Exemple documenté: une vulnérabilité SQL injection critique CVE-2026-42208 dans LiteLLM, pouvant permettre un accès non authentifié à des données, avec risque de compromission d’identifiants. Source: Red Hat CVE (access.redhat.com).

Mandiant décrit aussi des scénarios d’enchaînement après obtention de “Virtual Keys”, puis exploitation applicative contre la gateway (cloud.google.com).

Signal important: la fenêtre de réaction est courte. Recorded Future mentionne une exploitation observée 36 heures et 7 minutes après une divulgation liée à LiteLLM (CVE-2026-42208). Source (recordedfuture.com).

Les signaux d’alerte: ce que ton run doit surveiller (pas des slides)

Pics de coûts, sur des fenêtres courtes

Premier symptôme: un bond de facture ou du dashboard provider, sans release associée. Souvent la nuit, le week-end. Source: Auth0 (auth0.com).

Tokens anormaux et profil d’usage incohérent

Tu vois des volumes “en rafale” ou des prompts qui n’ont rien à voir avec ton métier: traduction de masse, génération de contenus génériques, formats répétitifs. Source: Auth0 (auth0.com).

Écarts géographiques ou IP inattendues

Si ton infra sort par des IP fixes (egress NAT, proxy sortant), des appels depuis des zones ou ASNs inhabituels doivent déclencher. Source: PlayCISO case “LLM API key abuse” (playciso.com).

Schémas “fraude” côté API

Mandiant mentionne des patterns d’optimisation pour maximiser le throughput: options qui minimisent la sortie, cadence extrême, rotation rapide de clés si l’attaquant en a plusieurs (cloud.google.com).

Si tu as une gateway: symptômes côté admin

• créations ou régénérations de clés inattendues
• erreurs d’auth en hausse
• pics sur endpoints d’administration
• version exposée à une CVE connue, admin accessible trop largement

Référence CVE LiteLLM: (access.redhat.com).

Check-list sécurité: “sécuriser API LLM” pour stopper le LLMjacking

On va être simple: tu veux des contrôles qui coupent la facture, puis des contrôles qui réduisent la probabilité et améliorent la détection.

Bloc A: gestion des secrets (priorité 1)

• Interdire les clés dans le code. Zéro exception. Même “temporaire”.
• Scanner les dépôts (publics et privés) pour détecter des secrets (pré-commit + CI).
• Centraliser dans un coffre de secrets (cloud secret manager ou équivalent on-prem). Pas dans des variables d’environnement en clair sur des runners partagés.
• Réduire le scope: une clé par appli, par environnement (dev, staging, prod), et si possible par usage (RAG, résumé, extraction).
• Rotation: clé compromise = rotation immédiate. Et rotation planifiée (mensuelle/trimestrielle selon criticité).
• Révoquer les clés “orphelines”: plus d’app, mais clé encore active.

Pour aller plus loin sur la logique “agents + secrets”, côté Lyon IA: 1Password for Agents et gestion des secrets : autoriser des agents IA sans fuite.

Bloc B: quotas, limites et garde-fous de consommation

• Quotas par clé: tokens/minute, requêtes/minute, budget/jour.
• Plafonds par environnement: prod a un plafond, staging un plafond plus bas, dev très bas.
• Fail-closed sur dépassement: si quota dépassé, tu bloques. Tu ne “laisses pas passer”.
• Limiter les modèles “chers” aux seuls workloads qui en ont besoin.

Ce sujet rejoint un risque reconnu côté OWASP. Le Top 10 LLM Applications 2025 inclut “Unbounded Consumption”, lié aux coûts inattendus à grande échelle. Source: OWASP PDF (owasp.org).

Bloc C: alerting FinOps et détection temps court

• Alerte coût horaire: pas juste “fin de mois”. Une attaque se joue en heures.
• Alerte anomalies tokens: ratio input/output, pics nocturnes, burst.
• Alerte par clé: top consommateurs, nouvelles clés actives, clés inactives redevenues actives.
• Runbook: qui fait quoi quand l’alerte tombe (révoquer, couper, informer, conserver les preuves).

Si tu veux poser des bases pour comprendre ta facture: Le coût du token expliqué : lire une facture d'API d'IA.

Bloc D: RBAC, IAM et segmentation (pour éviter “la clé passe-partout”)

• RBAC sur la console provider: accès par rôle, pas par personnes “admin par défaut”.
• Moindre privilège pour les service accounts: permissions minimales, scopes limités, pas de droits larges sur le projet.
• MFA sur les comptes humains qui peuvent créer ou régénérer des clés.
• Segmentation réseau si possible: egress fixe, allowlist IP côté provider quand c’est supporté.

Bloc E: logs exploitables (sinon tu subis deux fois)

• Log par requête: timestamp, clé ou identifiant d’app, modèle, tokens, latence, code retour.
• Corrélation avec tes logs API gateway et tes logs applicatifs.
• Rétention adaptée: si tu détectes à J+7, il te faut des traces à J+7.

Si tu bosses déjà sur le sujet “traces et audit” côté agents: Agents IA et cybersécurité : effacement de traces, audit des logs et accès avant d’automatiser.

Bloc F: durcissement spécifique gateways/proxies LLM

• Mettre à jour vite (et savoir que tu es exposé): inventaire des versions, patching prioritaire quand une CVE sort.
• Isoler l’admin: pas d’interface admin exposée publiquement, restrictions IP, authent forte.
• Limiter la création de clés: qui peut créer une “virtual key”, avec quelle approbation.
• Surveiller l’admin: logs dédiés, alertes sur actions sensibles (création clé, rotation, changement quotas).

Référence CVE LiteLLM: (access.redhat.com).

Plan d’action DSI/DevOps: 48 heures pour réduire le risque, 30 jours pour durcir

Les 48 heures (objectif: stopper une attaque et éviter la récidive immédiate)

• 1. Inventaire express: quelles apps, quels agents, quels workflows appellent un LLM, avec quelles clés, où elles sont stockées.
• 2. Rotation immédiate de toutes les clés qui ont pu être exposées (dépôts, CI, images, docs). Si tu n’es pas sûr, tu rotates.
• 3. Quotas et plafonds activés partout. Même si ça casse un usage non critique. Tu préfères casser un automatisme que payer 30 000 dollars en 3 heures.
• 4. Alerting coût + tokens à l’heure. Pas demain. Aujourd’hui.
• 5. Couper les clés inutiles et les environnements oubliés (staging “ouvert”, sandbox, anciens projets cloud).
• 6. Verrouiller les consoles: MFA, suppression des admins “de confort”, revue rapide des accès.
• 7. Logs minimaux: activer au moins la traçabilité des appels et l’identification par clé/app.

Les 30 jours (objectif: rendre l’abus difficile, détectable, et contenu)

• Semaine 1: coffre de secrets standard + scans de secrets sur dépôts et CI/CD + politique “une clé par app”.
• Semaine 2: RBAC propre + service accounts en moindre privilège + segmentation egress (si possible).
• Semaine 3: observabilité complète: dashboards par modèle, par app, par clé, alertes sur anomalies (burst, horaires, géo/IP).
• Semaine 4: durcissement gateways: patch management, admin isolée, logs d’actions sensibles, tests d’intrusion ciblés.

Ajoute un point gouvernance: qui peut ouvrir un nouveau fournisseur LLM, créer une clé, augmenter un quota, activer un modèle coûteux. Sans ça, tu vas recréer du shadow IT, et donc des clés qui traînent.

Sur le cadrage “industrialiser sans shadow AI”, côté site: CODIR Data & IA à Lyon : industrialiser sans “shadow AI”, mode d’emploi.

Mini check-list “cybersécurité IA entreprise” à coller dans ton ticketing

• Secrets: aucune clé dans le code, scan CI activé, rotation planifiée, révocation des clés orphelines.
• Limites: quotas par clé, plafonds par environnement, blocage sur dépassement.
• FinOps: alertes coût à l’heure, alertes tokens, top consommateurs, détection burst.
• Accès: MFA, RBAC, moindre privilège service accounts, inventaire des admins.
• Logs: appels LLM tracés, corrélation app et gateway, rétention suffisante.
• Gateways: admin isolée, patching rapide, surveillance des actions sensibles, revue CVE.

Ce que tu dois retenir (et ce que tu peux faire dès aujourd’hui à Lyon)

Le LLMjacking n’a pas besoin de sophistication. Il a besoin d’une clé. Une fois dehors, la consommation peut s’industrialiser à une vitesse qui te laisse peu de temps pour réagir. Mandiant décrit des volumes massifs d’appels en moins de 8 heures via des clés volées (cloud.google.com).

Ton réflexe doit être le même que pour une carte bancaire qui fuit: tu bloques, tu rotates, tu plafonnes. Ensuite seulement tu optimises.

Action immédiate simple: ouvre ton dashboard provider, regarde les 7 derniers jours, et pose trois questions run: qui consomme, quand, avec quelle clé. Si tu ne peux pas répondre en 10 minutes, tu es en zone rouge.