Sécuriser les clés d’API des fournisseurs d’IA générative

Une clé d’API (Application Programming Interface) d’un fournisseur d’IA (intelligence artificielle) générative est un secret porteur : quiconque la possède consomme le service au nom du titulaire, lit parfois les objets stockés du projet et reçoit la facture en prime. Elle se revend, s’exploite en quelques minutes après une fuite, et le fournisseur ne distingue pas l’usage légitime du détournement. La position défendue : aucune clé de fournisseur hors d’une passerelle côté serveur, jamais.

→ Lire l’explication complète de la marmotte

Où fuient les clés d’API des fournisseurs d’IA

Les fuites suivent toujours les mêmes chemins, et aucun n’est exotique.

L’application cliente. Une clé embarquée dans un bundle JavaScript, une application mobile ou une extension est publique, point. L’offuscation, le découpage en morceaux ou le chiffrement avec une clé livrée dans la même application ne changent rien : le client doit reconstituer la clé pour l’envoyer, donc un attaquant peut la lire au même endroit, avec un proxy d’interception ou un débogueur. Chiffrer une clé avec une autre clé posée à côté relève du cadenas accroché à sa propre clé.

L’historique du dépôt. Retirer la clé d’un fichier ne la retire pas des commits précédents. Un dépôt passé de privé à public expose tout son historique d’un coup.

Les artefacts d’exécution. Carnets de calcul partagés avec leurs sorties, fichiers .env copiés dans une image de conteneur, journaux de CI/CD (Continuous Integration / Continuous Delivery) qui affichent les variables d’environnement en mode verbeux.

Les échanges humains. Clé collée dans un ticket, un canal de discussion ou un prompt d’assistant pour « déboguer vite ».

Le détournement qui suit n’est pas théorique : la revente d’accès à des modèles payants par des identifiants volés est documentée dans le secteur sous le nom de LLMjacking (détournement de LLM, Large Language Model). Le mobile tient en une ligne : le voleur obtient un service coûteux gratuitement et sans filtrage de son identité.

Passerelle intermédiaire : l’architecture qui confine la clé

La seule architecture qui tient : les clients s’authentifient auprès d’une passerelle interne avec leur identité d’entreprise, et seule la passerelle détient la clé du fournisseur, qu’elle injecte à l’aller. Le client ne voit jamais le secret.

Ce que la passerelle apporte en plus du confinement :

L’attribution. Chaque appel est relié à un utilisateur ou un service authentifié, par exemple via un JWT (JSON Web Token, jeton signé au format JavaScript Object Notation) émis par le fournisseur d’identité. Côté fournisseur d’IA, tout apparaît sous une seule clé ; seule la passerelle sait qui a fait quoi.
La liste blanche. Modèles autorisés, points d’accès autorisés, taille maximale de requête. Une clé volée derrière une passerelle ne sert qu’à ce que la passerelle laisse passer.
La révocation granulaire. Couper un utilisateur ne demande pas de faire tourner la clé partagée.

Le compromis : la passerelle devient un point de défaillance unique et une cible de valeur, puisqu’elle concentre la clé et voit passer tous les prompts. Elle se traite donc comme un service d’infrastructure critique : secret chargé depuis un coffre, pas depuis un fichier dans l’image, journaux d’accès protégés, redondance. Le fédérage d’identité côté utilisateurs relève de la rubrique identités. Le plafonnement fin des coûts par utilisateur relève du denial of wallet, traité dans une page dédiée de la rubrique IA.

Côté fournisseur, compléter par un cloisonnement : une clé par application et par environnement, rattachée à un projet distinct quand le fournisseur le permet, avec les permissions minimales lorsque des portées restreintes existent (leur disponibilité varie selon les fournisseurs, à vérifier). Une clé de développement ne doit pas pouvoir appeler l’environnement de production, ni lire ses fichiers.

Exemple : détecter une clé de fournisseur dans le code et les bundles

Deux contrôles complémentaires, à exécuter dans la chaîne d’intégration continue avant publication.

# 1. Historique complet du dépôt (toutes branches) avec gitleaks
#    Les jeux de règles récents incluent des motifs pour plusieurs fournisseurs d'IA :
#    vérifier leur présence dans la version installée (gitleaks version)
gitleaks detect --source . --log-opts="--all" --redact --report-path fuite-cles.json

# 2. Bundle compilé de l'application cliente : ce qui part réellement chez l'utilisateur
#    Motifs de préfixes documentés publiquement : sk-proj- et sk-ant- (clés OpenAI et Anthropic),
#    AIza (clés d'API Google) ; à compléter selon les fournisseurs utilisés
grep -rEo 'sk-(proj|ant)-[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35}' dist/ \
  | cut -c1-40 \
  && { echo "Clé de fournisseur trouvée dans le bundle : publication bloquée"; exit 1; } \
  || echo "Aucun motif de clé détecté dans dist/"

Le second contrôle attrape ce que le premier rate : une clé injectée au moment de la compilation par une variable d’environnement n’apparaît jamais dans le dépôt, mais se retrouve lisible dans le JavaScript livré. Les outils de construction front qui exposent au client toute variable portant un certain préfixe produisent exactement ce cas.

Rotation et révocation des clés d’API

Une clé divulguée se révoque d’abord, s’analyse ensuite. Le réflexe inverse (chercher d’abord comment elle a fuité) laisse le compteur tourner pendant l’enquête.

Pour que la révocation ne casse pas la production, la rotation doit être outillée avant l’incident : deux clés valides en parallèle, la passerelle lit la clé courante depuis le coffre de secrets à chaud, la nouvelle est déployée, l’ancienne révoquée après vérification du trafic. Une rotation qui demande un redéploiement manuel de six services ne sera jamais faite un vendredi soir, c’est-à-dire au moment où elle est nécessaire. Les principes de coffre et d’injection de secrets relèvent de la rubrique développement.

Plusieurs fournisseurs participent aux programmes d’analyse de secrets des plateformes d’hébergement de code : une clé poussée dans un dépôt public peut leur être signalée et révoquée automatiquement. C’est un filet, pas une stratégie : les dépôts privés, les bundles et les tickets n’y passent pas.

Détection d’usage anormal d’une clé d’API

Les signaux exploitables, à comparer à une ligne de base par clé :

appels vers un modèle jamais utilisé par l’application, souvent le plus cher du catalogue ;
activité à des heures ou depuis des adresses sources incohérentes avec le déploiement, quand le fournisseur expose l’adresse source dans ses journaux ;
consommation directe sur une clé qui ne devrait être utilisée que par la passerelle (écart entre le décompte de la passerelle et celui du fournisseur) ;
hausse brutale du volume de jetons consommés.

L’écart entre compteurs est le signal le plus fiable : si le fournisseur facture plus que ce que la passerelle a relayé, la clé est utilisée ailleurs. Les métriques à collecter côté passerelle sont décrites dans observer un modèle de langage en production.

Ce que tout cela ne garantit pas : une passerelle compromise livre la clé et les prompts ; la détection par la facture arrive après la consommation ; et un fournisseur ne rembourse pas par principe l’usage frauduleux d’une clé valide.

🐝 Ce qui arrive si on s’en passe

Sans passerelle ni clé par application, une fuite impose de révoquer la clé partagée, ce qui coupe d’un coup tous les services qui l’utilisent, y compris ceux qui n’ont rien à voir avec la fuite. L’enquête bute ensuite sur l’attribution : le fournisseur ne journalise que la clé, donc les appels légitimes et frauduleux sont indiscernables et le périmètre de la compromission reste inconnu. Si le projet contient des fichiers ou des conversations stockés, la clé volée donne aussi accès en lecture à ces contenus, ce qui transforme un problème de facture en fuite de données.

🦫 Explication de la marmotte 🍫

Pour utiliser un service d’intelligence artificielle payant depuis un programme, on reçoit une longue suite de caractères secrète appelée clé. Le service ne demande rien d’autre : toute personne qui envoie cette clé est acceptée, et le propriétaire de la clé paie. Le problème, c’est que ces clés s’échappent facilement : laissées dans du code publié sur Internet, placées dans une application installée sur le téléphone des utilisateurs, ou affichées dans un journal. Une clé présente dans une application qu’on distribue peut toujours être retrouvée, même cachée. La bonne méthode consiste à garder la clé sur un seul serveur de l’entreprise, appelé passerelle. Les utilisateurs se connectent à cette passerelle avec leur compte de travail ; elle vérifie qui ils sont, ajoute la clé et transmet la demande. Ainsi, la clé ne sort jamais, et on sait qui a fait chaque demande. On vérifie aussi automatiquement, avant chaque publication, qu’aucune clé ne traîne dans le code. Si une clé fuit malgré tout, on la désactive immédiatement et on en met une nouvelle, ce qui doit être prévu à l’avance pour ne rien casser. Enfin, on surveille les dépenses : si le fournisseur compte plus de demandes que la passerelle n’en a envoyé, quelqu’un utilise la clé ailleurs.

Pages voisines

La citent

Sécuriser les clés d'API des fournisseurs d'IA générative

Elle cite

: les deux pages se citent l’une l’autre.