Clés API d’IA volées financent désormais des scans de piratage : comment sécuriser vos clés OpenAI, Anthropic et Gemini

Les clés d'API IA volées paient désormais les attaques informatiques d'autres personnes. En octobre 2026, l'équipe de renseignement sur les menaces de Bitsight a décrit MONST3R-AI, un outil vendu sur un forum criminel qui exécute des scans de tests d'intrusion autonomes sur des clés OpenAI, Anthropic et Google volées. L'acheteur apporte la clé, l'agent effectue le scan, et le propriétaire de la clé reçoit la facture. Ce guide couvre la façon dont les clés fuient, comment repérer les abus et les contrôles que chaque fournisseur propose aujourd'hui.

Pour protéger une clé OpenAI, Anthropic ou Gemini, limitez-la à un seul projet ou espace de travail, définissez un plafond de dépenses mensuel strict, restreignez les lieux depuis lesquels elle peut être appelée, fixez une date d'expiration ou faites-la tourner, gardez-la hors du code client et des dépôts, et activez la détection de secrets avec protection push. Si une clé fuit, créez un remplacement, déployez-le, puis désactivez l'ancienne et auditez l'utilisation.

Qu'est-ce que le LLMjacking ?

Le LLMjacking est l'abus d'un identifiant de grand modèle de langage volé, généralement une clé d'API, pour exécuter de l'inférence payée par le propriétaire de la clé. Les attaquants revendent l'accès, le consomment pour leurs propres charges de travail ou, désormais, selon Bitsight, l'utilisent pour alimenter des agents d'attaque autonomes. La victime ne voit l'activité que comme une utilisation facturable sur son propre compte.

Ce que Bitsight a découvert à propos de MONST3R-AI

Les faits ci-dessous proviennent de la couverture de la recherche de Bitsight par Help Net Security et AI Weekly, publiée le 17 octobre 2026. L'analyse de Bitsight sur l'outil n'était pas publique au moment de la rédaction de cet article.

• Ce que c'est : un vendeur sur un forum criminel restreint commercialise MONST3R-AI comme une « plateforme autonome de tests d'intrusion ».
• Quelles clés : il fonctionne avec des clés d'API OpenAI, Anthropic et Google volées.
• Qui paie : l'acheteur colle une clé volée dans le panneau de l'outil, fixe un budget et pointe l'agent vers une liste de cibles. Le vendeur n'héberge aucun modèle, donc la facture d'inférence retombe sur le propriétaire légitime de la clé.
• Résultats annoncés : le tableau de bord du vendeur revendique 1 072 constats sur 199 hôtes scannés. Bitsight indique ne pas pouvoir vérifier ce chiffre de manière indépendante, donc à traiter comme du marketing, pas comme une preuve.
• La tendance de fond : sur 16 forums clandestins entre février et août 2026, les mentions d'agents IA, d'injection de prompt indirecte et du Model Context Protocol ont augmenté de 67 %.

Une clé divulguée n'est plus seulement une facture surprise. Elle peut financer la campagne d'attaque de quelqu'un d'autre, et chaque requête ressemble à votre trafic normal.

Comment les clés d'API IA fuient

La plupart des clés volées n'ont jamais été « piratées ». Elles ont été publiées par accident. Les chemins courants :

Le guide des clés d'API Gemini de Google énonce clairement la règle côté client : les clés compilées dans des applications web ou mobiles peuvent être extraites par les utilisateurs, il faut donc exécuter un proxy backend qui effectue les vrais appels. Notre guide sur le stockage des clés d'API traite plus en profondeur l'aspect stockage.

Les configurations d'agents méritent une attention particulière : les fichiers MCP et de paramètres d'agents finissent dans des dépôts de dotfiles, des partages d'écran et des rapports de bugs.

Comment savoir que votre clé est utilisée abusivement

Aucune alerte ne dit « un criminel utilise ceci ». Surveillez les données d'utilisation et de facturation pour :

1. Des pics de dépenses sans déploiement derrière. Un coût quotidien stable qui double du jour au lendemain est le signe le plus clair.
2. Des modèles que vous n'utilisez pas. Une utilisation sur une famille de modèles que votre produit n'appelle jamais.
3. Du trafic en dehors des heures ouvrables. Des requêtes régulières à 3 h du matin dans votre fuseau horaire depuis une clé utilisée par une application de journée.
4. Des erreurs de limite de débit que vous n'avez pas causées. Quelqu'un d'autre consomme votre quota par minute.
5. Des clés ou projets inconnus sur les pages d'utilisation. La page Usage de Google AI Studio regroupe les requêtes qu'elle ne peut associer à une clé nommée sous « (unknown keys) ».

Découpez les clés assez finement pour qu'un pic pointe vers une seule clé.

Comment protéger votre clé d'API OpenAI

Vérifié le 28 octobre 2026 par rapport à la documentation développeur d'OpenAI.

• Limites de dépenses strictes : selon le guide des limites de dépenses, vous pouvez définir une limite mensuelle pour l'organisation ou un projet unique et activer « Enforce a hard limit ». Une fois les dépenses suivies atteignant cette limite, les requêtes échouent avec un 429 et le code organization_spend_limit_exceeded ou project_spend_limit_exceeded. L'application n'est pas instantanée, les dépenses peuvent donc dépasser légèrement le plafond.
• Alertes de dépenses : les alertes vous notifient mais n'arrêtent pas le trafic. Utilisez les deux, avec l'alerte réglée bien en dessous de la limite stricte.
• Liste d'IP autorisées : la liste d'autorisation d'IP rejette les requêtes venant d'autres IP même avec une clé valide. Elle accepte jusqu'à 50 adresses ou plages CIDR, peut s'appliquer par projet ou à l'échelle de l'organisation, et les appels bloqués reçoivent un HTTP 401 avec ip_not_authorized. Les modifications prennent jusqu'à 15 minutes.
• Un projet par application et par environnement : les limites et listes d'autorisation au niveau du projet ne servent à rien si les clés ne sont pas séparées par projet.
• Permissions de clé restreintes : le guide des projets d'OpenAI liste les permissions All (la valeur par défaut), Restricted et Read Only pour les clés détenues par des utilisateurs. Ne donnez à chaque clé que ce dont son application a besoin.
• Accès aux modèles par projet : dans les Limits d'un projet, Model usage détermine quels modèles le projet peut appeler. Une clé volée ne peut alors pas sauter vers un modèle plus cher que vous n'utilisez jamais.

Voir notre guide des clés d'API OpenAI.

Comment protéger votre clé d'API Anthropic

Vérifié le 28 octobre 2026 par rapport à la documentation de la plateforme Claude.

• Limites de dépenses par espace de travail : selon la documentation sur les espaces de travail, vous pouvez plafonner les dépenses mensuelles par espace de travail et configurer des alertes à des seuils. Vous ne pouvez pas définir de limites de dépenses sur l'espace de travail par défaut, donc placez les clés de production dans leur propre espace de travail.
• Limites de débit par espace de travail : plafonnez les requêtes, les jetons d'entrée et les jetons de sortie par minute pour chaque espace de travail.
• Expiration des clés : la documentation d'authentification vous permet de choisir une expiration à la création : 3 heures, 1 jour, 7 jours, 30 jours, une durée personnalisée ou Never. Elle ne peut pas être modifiée ensuite.
• Clés rattachées à une identité : les clés personnelles et de compte de service cessent de fonctionner lorsque leur propriétaire est supprimé. Anthropic qualifie les clés d'espace de travail d'héritées et recommande Workload Identity Federation pour la production sur les plateformes cloud et en CI.
• Désactiver versus supprimer : Désactiver est réversible et affiche la clé comme inactive. Supprimer est définitif. Désactivez d'abord en cas de doute.

Voir notre guide des clés d'API Anthropic.

Comment protéger votre clé d'API Google Gemini

Vérifié le 28 octobre 2026 par rapport à la documentation des clés d'API Gemini et à la documentation de facturation de Google.

• Clés d'authentification : depuis le 28 mai 2026, les nouvelles clés créées dans Google AI Studio sont des clés d'autorisation liées à un compte de service, restreintes par défaut à l'API Gemini. Google indique qu'elles bénéficient d'une application rapide contre les clés divulguées que ses systèmes détectent.
• Pas de clés sans restriction : l'API Gemini rejette les requêtes provenant de clés standard sans restriction. Restreignez les anciennes clés à l'API Gemini dans AI Studio, ou migrez vers une clé d'authentification.
• Restrictions applicatives : dans la page des identifiants de la console Cloud, restreignez une clé à des adresses IP spécifiques.
• Plafonds de dépenses par projet : définissez un plafond mensuel par projet sur la page Spend d'AI Studio. Google qualifie cela d'expérimental et signale des dépassements pendant un délai de facturation d'environ 10 minutes.

La liste de verrouillage pour chaque fournisseur

À exécuter une fois par clé que vous détenez :

1. Inventaire. Listez chaque clé, l'application qui l'utilise et l'endroit où elle est stockée.
2. Séparation. Un projet ou espace de travail par application et par environnement, pour qu'un pic nomme sa source.
3. Plafond. Définissez une limite mensuelle stricte et une alerte plus précoce.
4. Restriction. Liste d'IP autorisées ou restriction applicative partout où votre sortie réseau est fixe.
5. Expiration ou rotation. Expiration courte là où le fournisseur le permet ; un calendrier de rotation là où ce n'est pas le cas.
6. Analyse. Les motifs de détection de secrets de GitHub incluent les clés d'API OpenAI, Anthropic et Google Gemini, et les clés OpenAI prennent en charge la protection push. Notre article sur la vérification des clés d'API divulguées couvre les scanners que vous pouvez exécuter localement.
7. Préférez les identifiants à courte durée de vie. Anthropic et OpenAI documentent tous deux la fédération d'identité de charge de travail pour la production.

Pour l'aspect politique, voir les bonnes pratiques de gestion des clés d'API.

Que faire dans la première heure après une fuite

La rapidité prime sur la cause racine. Dans l'ordre :

1. Créez une clé de remplacement dans un nouveau projet ou espace de travail.
2. Déployez-la vers les applications qui en ont besoin.
3. Désactivez la clé divulguée. La liste de vérification de Google en cas de fuite indique de désactiver l'ancienne clé seulement après avoir vérifié la nouvelle, pour éviter une interruption de service. Si les dépenses grimpent vite, désactivez d'abord et acceptez l'interruption.
4. Abaissez le plafond de dépenses du projet concerné pendant votre investigation.
5. Auditez l'utilisation par modèle, heure et clé sur la période depuis la fuite.
6. Trouvez le chemin de la fuite à l'aide du tableau ci-dessus, et purgez-la de l'historique git.
7. Contactez le fournisseur au sujet de l'utilisation frauduleuse une fois que vous avez la chronologie.

Laissez votre agent de codage tester la gestion des clés avec Apidog CLI

Votre proxy backend vers OpenAI, Anthropic ou Gemini est l'endroit où la gestion des clés casse : il accepte des appels non authentifiés, ou renvoie la clé du fournisseur dans un corps d'erreur. Laissez votre agent de codage écrire et exécuter des tests pour cela avec Apidog CLI, en gardant les secrets hors des définitions de test.

Configurez-le une fois :

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Ensuite, donnez un seul prompt à votre agent :

In Apidog project <id>, create a test case for POST /v1/ai/chat on our proxy.
Assert: no Authorization header returns 401, a bad token returns 401, a valid
token returns 200, and no response body contains "sk-" or "AIza". Read the
token from the {{PROXY_TOKEN}} environment variable, never hardcode it.
Then run it against the staging environment and summarize failures.

L'agent lit le schéma de la charge utile, le valide, crée le cas et l'exécute :

apidog cli-schema get test-case-create
apidog test-case category --project <id>
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> \
  --env-var "PROXY_TOKEN=$PROXY_TOKEN" -r cli,junit

--env-var passe le jeton au moment de l'exécution, il ne réside donc jamais dans la spécification ou le dépôt. La même ligne apidog run s'intègre à la CI ; voir Apidog CLI dans un pipeline CI/CD et Apidog CLI dans Claude Code.

FAQ

Qu'est-ce que le LLMjacking ? C'est l'utilisation d'un identifiant de LLM volé, généralement une clé d'API, pour exécuter de l'inférence payée par le propriétaire. Les attaquants revendent l'accès ou, comme avec MONST3R-AI, l'utilisent pour alimenter des agents d'attaque.

Des clés d'API IA volées peuvent-elles vraiment payer des outils de piratage ? Oui. Bitsight a rapporté que les acheteurs de MONST3R-AI collent des clés OpenAI, Anthropic ou Google volées dans son panneau, et le vendeur n'héberge aucun modèle, donc les victimes paient. Les résultats annoncés par le vendeur ne sont pas vérifiés.

Une limite de dépenses arrête-t-elle une clé volée ? Une limite stricte arrête les dépenses au plafond, mais pas instantanément. OpenAI et Google signalent tous deux de légers dépassements pendant la propagation des limites. Les alertes de dépenses seules n'arrêtent jamais le trafic.

Puis-je mettre ma clé d'API OpenAI dans du code frontend ? Non. Tout ce qui est livré à un navigateur ou une application mobile peut être extrait. Appelez le modèle depuis votre backend.

GitHub détectera-t-il une clé d'IA divulguée ? La détection de secrets de GitHub détecte les motifs de clés d'API OpenAI, Anthropic et Google Gemini. Activez la protection push pour qu'un commit contenant une clé soit bloqué avant d'être public.