Votre entreprise paie peut-être pour l’IA utilisée par des pirates : comprendre le LLM-jacking
Une clé API oubliée dans un dépôt Git, un outil de développement ou un fichier de configuration peut permettre à un tiers d’utiliser vos services d’intelligence artificielle. Cette menace, appelée LLM-jacking, prend de l’ampleur en 2026.
Imaginez la situation.
Votre entreprise utilise l'intelligence artificielle pour automatiser certaines tâches.
Un développeur a intégré une API à une application interne.
Le service fonctionne bien.
Personne ne se pose de questions.
Puis, un jour, quelqu'un remarque une consommation inhabituelle de ressources IA.
Les appels API se multiplient.
Les quotas diminuent.
Des traitements semblent avoir été exécutés alors qu'aucun salarié ne les a demandés.
Le problème ne vient pas forcément d'un bug.
Un tiers utilise peut-être vos ressources d'intelligence artificielle à votre insu.
Ce scénario porte un nom : le LLM-jacking.
Et il ne s'agit plus seulement d'un risque théorique.
Ce que Google a observé en 2026
Dans une analyse publiée en septembre 2026, Google Threat Intelligence Group décrit une évolution des activités cybercriminelles visant les environnements d'intelligence artificielle.
Les attaquants ne cherchent plus uniquement à voler des documents ou des mots de passe classiques.
Ils ciblent également les comptes de services IA, les identifiants de développeurs, les clés API et les ressources de calcul cloud.
Google rapporte des cas dans lesquels des environnements cloud compromis ont été détournés pour exécuter des charges de travail IA non autorisées.
Le CERT-EU a également signalé cette tendance dans son bulletin du 2 octobre 2026.
En clair, les accès IA deviennent eux-mêmes des actifs recherchés par les cybercriminels.
Source : Google Threat Intelligence — September 2026
Une clé API, ce n'est pas juste une ligne dans un fichier
Pour beaucoup de développeurs, une clé API est un élément technique parmi d'autres.
Une chaîne de caractères dans un fichier de configuration.
Une variable d'environnement.
Un secret conservé dans un outil CI/CD.
Mais cette clé peut représenter un véritable droit d'accès à un service facturé.
Si elle est exposée et que les contrôles du fournisseur le permettent, quelqu'un d'autre peut potentiellement consommer les ressources associées.
Les conséquences dépendent du service : consommation de quotas, surcoûts, utilisation abusive ou accès à certaines ressources autorisées par la clé.
C'est précisément pourquoi un secret technique doit être traité comme un identifiant sensible.
Comment les clés sont-elles récupérées ?
Il existe plusieurs scénarios.
Un développeur publie accidentellement un secret dans un dépôt Git.
Un poste de travail est infecté par un logiciel voleur d'informations.
Un fichier .env est exposé.
Un système CI/CD donne accès à des variables sensibles.
Une sauvegarde ou un journal applicatif contient des identifiants.
Ou encore, un assistant de développement conserve des informations d'authentification dans ses fichiers de configuration.
Ce dernier cas n'est pas imaginaire.
Google a documenté en 2026 l'intérêt de certains logiciels malveillants pour les fichiers de configuration d'assistants de programmation IA, qui peuvent contenir des clés API.
Le problème n'est donc pas uniquement l'IA elle-même.
C'est tout l'écosystème d'accès qui l'entoure.
Pourquoi cela concerne aussi les PME
On pourrait croire que seuls les grands laboratoires d'intelligence artificielle sont concernés.
Pourtant, une petite entreprise peut aujourd'hui utiliser plusieurs services IA sans même disposer d'une équipe spécialisée.
Un chatbot commercial.
Un assistant de support.
Une intégration CRM.
Un outil de génération de documents.
Un agent de développement.
Des scripts internes connectés à des modèles externes.
Chaque intégration peut créer un nouvel accès technique.
Et lorsqu'aucune personne n'est chargée d'en suivre la sécurité, ces accès peuvent rester actifs beaucoup trop longtemps.
Le risque ne se limite pas à la facture
L'utilisation non autorisée des ressources peut entraîner des frais, selon le modèle de tarification du fournisseur.
Mais le problème ne s'arrête pas là.
Une clé compromise peut révéler des faiblesses plus larges.
Qui a créé cette clé ?
Pourquoi dispose-t-elle de ces permissions ?
Est-elle partagée par plusieurs applications ?
Peut-elle être révoquée sans arrêter la production ?
Est-elle visible dans les journaux ?
Si personne ne sait répondre, le risque dépasse largement la consommation d'IA.
Il révèle un problème de gestion des identités techniques.
Cinq mesures concrètes pour réduire le risque
1. Faire l'inventaire des services IA
Commencez par identifier les plateformes utilisées, les comptes associés et les applications qui consomment leurs API.
N'oubliez pas les projets pilotes et les outils utilisés uniquement par les développeurs.
2. Rechercher les secrets exposés
Vérifiez les dépôts de code, pipelines CI/CD, fichiers de configuration et systèmes de gestion des secrets.
Cette recherche doit porter sur les secrets actuels, mais également sur ceux qui peuvent apparaître dans l'historique du code.
3. Limiter les permissions
Lorsqu'un fournisseur le permet, utilisez des clés distinctes par application, avec des droits aussi restreints que possible.
Évitez de partager un identifiant unique entre dix services différents.
4. Surveiller l'utilisation et les coûts
Configurez les alertes de consommation, les seuils de budget et les journaux d'utilisation disponibles.
Un pic inhabituel peut être un signal.
Mais une activité malveillante peut également rester sous les seuils habituels : les alertes de facturation ne suffisent pas à elles seules.
5. Prévoir une procédure de révocation
Si une clé est compromise, il faut pouvoir la désactiver, la remplacer dans les applications concernées et vérifier les usages effectués avant la révocation.
La rotation doit être organisée pour limiter les interruptions de service.
Le test que chaque CTO devrait faire
Demandez à votre équipe :
« Si une clé API de notre principal service d'IA était volée aujourd'hui, combien de temps faudrait-il pour le détecter et la révoquer ? »
Une réponse fiable suppose trois choses.
Savoir quelles clés existent.
Savoir où elles sont utilisées.
Disposer de traces permettant d'identifier les usages inhabituels.
Sans ces informations, l'entreprise dépend de la chance.
La visibilité devient aussi importante que la protection
Les entreprises ajoutent rapidement de nouveaux outils IA.
Mais elles ne développent pas toujours leurs capacités de supervision au même rythme.
C'est précisément le problème.
Chez Cyberhack, nous défendons une approche dans laquelle chaque nouveau service critique doit être intégré à l'inventaire des risques, avec des responsabilités identifiées et des contrôles vérifiables.
Il ne s'agit pas de ralentir l'adoption de l'intelligence artificielle.
Il s'agit d'éviter qu'elle introduise des accès que personne ne surveille.
Pour mieux comprendre cette approche, vous pouvez découvrir Cyberhack Platform.
Conclusion
Le LLM-jacking montre que l'intelligence artificielle crée de nouveaux actifs à protéger.
Les modèles, les clés API, les identifiants des développeurs et les ressources cloud ont désormais une valeur directe pour les cybercriminels.
Le danger n'est pas forcément visible.
Votre application peut continuer à fonctionner pendant qu'un tiers utilise une partie de vos ressources.
C'est pourquoi la question n'est plus seulement :
« Nos collaborateurs utilisent-ils l'IA de manière sécurisée ? »
Elle devient :
« Savons-nous réellement qui utilise nos services d'IA, avec quels droits, et comment nous détecterions un usage non autorisé ? »
