Clés d'API volées : le risque oublié des projets IA

Une clé d’API, c’est une carte d’accès qu’un programme présente à un service pour être servi, et facturé. Dans un projet d’IA, ces cartes se multiplient vite : une par fournisseur de modèles, une par automatisation, une pour le prototype de la semaine dernière qui tourne encore. Chacune ouvre un compteur payé par l’entreprise. Volée, elle ouvre le même compteur à quelqu’un d’autre.

Ce texte de notre rubrique Infrastructure et cloud parle de ce risque sous l’angle qui fâche les directions financières : la facture. Où les clés fuient dans un projet d’IA, ce qu’une clé volée peut coûter, comment limiter les dégâts avant même la fuite, et quoi faire dans la première heure.

Pourquoi les projets IA multiplient les clés exposées

Parce qu’ils vont vite et qu’ils empilent les services. Un assistant interne appelle un modèle, un moteur de recherche dans vos documents, un outil d’automatisation ; chaque brique demande sa clé, et le prototype qui devait durer une semaine part en production avec la clé collée là où elle dépannait.

Le dernier rapport de GitGuardian sur l’éparpillement des secrets mesure l’ampleur du phénomène :

Le dernier chiffre est le plus inquiétant : une clé qui a fuité n’est presque jamais changée. Elle reste utilisable pendant des années par quiconque l’a récupérée.

Ce qu’une clé volée coûte vraiment

Une clé de messagerie volée expose des données. Une clé de modèle d’IA volée expose aussi un budget. En mai 2024, l’équipe de recherche de Sysdig a décrit une attaque baptisée LLMjacking : des identifiants cloud volés, via une faille d’un site non mis à jour, servaient à utiliser des modèles hébergés et à en revendre l’accès, aux frais de la victime. Dans le pire des cas calculé par Sysdig, la consommation dépassait 46 000 dollars par jour.

L’OWASP, la fondation de référence en sécurité des applications, range ce risque dans son classement 2025 des risques des applications d’IA sous le nom de consommation non bornée, et lui donne un surnom parlant :

La parade que recommande l’OWASP n’a rien d’exotique : des limites de requêtes, des quotas par utilisateur, et une surveillance qui alerte sur une consommation inhabituelle. Autrement dit, des plafonds posés avant l’incident.

Où les clés fuient dans un projet IA

Quatre endroits reviennent sans cesse.

• Le code envoyé au navigateur ou à l’application mobile. Un prototype appelle le modèle directement depuis la page : la clé voyage avec, lisible par n’importe quel visiteur. Google le dit sans détour dans ses bonnes pratiques sur les clés d’API : jamais de clé dans le code client ni dans un dépôt de code, c’est le serveur qui l’ajoute à la requête.
• Le dépôt de code, historique compris : retirer la clé du fichier ne l’efface pas des versions précédentes.
• Les outils de collaboration : messageries, tickets, documents partagés. GitGuardian estime que 28 % des fuites ont lieu uniquement hors des dépôts de code.
• Les instructions et les documents donnés à un modèle : une clé qu’un agent IA lit est une clé qu’il peut répéter. Notre article sur le coffre-fort de secrets détaille comment un agent peut s’en servir sans jamais la voir.

Limiter les dégâts avant la fuite

On ne garantit jamais qu’une clé ne fuira pas. On peut en revanche décider, à l’avance, de ce qu’elle permettra de faire le jour où elle fuira.

Concrètement :

• Une clé par usage. Le jour où l’une fuit, on la coupe sans arrêter les autres projets, et le journal dit tout de suite lequel est touché.
• Des restrictions sur chaque clé. Chez Google Cloud, par exemple, une clé peut être limitée à certains services ou à certaines applications, et Google le résume ainsi : une clé restreinte réduit l’impact d’une clé compromise. Vérifiez ce que permet chacun de vos fournisseurs.
• Des plafonds et des alertes. Un budget par usage, une alerte à 50 ou 80 % de ce budget, et un arrêt automatique au plafond quand le fournisseur le propose. Notre article sur la facture de l’IA, les tokens et le routage explique comment prévoir ce budget usage par usage.
• Le ménage régulier. Les clés que plus rien n’utilise se suppriment, et les autres se renouvellent à intervalle régulier.
• La détection à la source. Depuis février 2024, GitHub bloque par défaut l’envoi de secrets reconnus vers les dépôts publics ; GitHub disait alors avoir détecté plus d’un million de secrets divulgués sur des dépôts publics dans les huit premières semaines de l’année.

Les droits d’un agent, eux, se découpent comme ceux d’un salarié : notre guide sur la gouvernance de l’IA en entreprise détaille ce découpage.

La première heure après une fuite

Quand une clé a été vue là où elle n’aurait pas dû l’être, la question n’est pas de savoir si quelqu’un l’a récupérée. On fait comme si.

L’ordre compte : révoquer d’abord, même si un service s’arrête quelques minutes. Une clé encore valide pendant qu’on cherche à la remplacer proprement continue de coûter. Si des données personnelles ont pu être lues avec la clé, la question d’une notification à la CNIL se pose aussi, dans le délai de 72 heures prévu en cas de violation de données.

Par où commencer

1. 01Listez vos clés d’IA

   Fournisseur, usage, personne responsable, date de création.

2. 02Supprimez celles que plus rien n’utilise

   Et changez celles qui ont circulé par messagerie ou dans du code.

3. 03Séparez les usages

   Une clé par projet ou par agent, avec ses seuls droits.

4. 04Posez un plafond et une alerte

   Sur chaque compte de fournisseur de modèles.

5. 05Écrivez la procédure de la première heure

   Avec le nom de qui a le droit de révoquer.

Les clés des programmes relèvent d’un coffre de secrets ; les mots de passe des personnes, d’un gestionnaire de mots de passe d’équipe. Les deux font partie du socle d’infrastructure commun à vos projets. Le reste de la rubrique couvre les décisions voisines : les cinq postes qui gonflent une facture cloud, serveur dédié, VPS ou cloud, Kubernetes et les PME, la supervision, le plan de reprise après sinistre, NIS2 en France, les sauvegardes d’un serveur à soi, n8n auto-hébergé en production, les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans, la migration cloud sans tout casser, la dépendance au cloud américain, le matériel pour faire tourner un modèle d’IA chez soi, Postgres géré ou à soi et le choix d’une messagerie d’entreprise.

Pour un coffre à votre nom que vos IA utilisent sans voir les clés, voyez notre Coffre-fort IA ; pour des plafonds par usage et un budget suivi, l’IA au juste coût ; pour héberger ces outils chez vous, notre offre de sortie du SaaS.

Questions fréquentes

Sources

1. Sysdig, LLMjacking: Stolen Cloud Credentials Used in New AI Attack, mai 2024 (nouvel onglet)sysdig.com
2. OWASP, LLM10:2025 Unbounded Consumption (nouvel onglet)genai.owasp.org
3. Google Cloud, Best practices for managing API keys (nouvel onglet)docs.cloud.google.com
4. GitHub, Keeping secrets out of public repositories, février 2024 (nouvel onglet)github.blog
5. CNIL, mots de passe : une nouvelle recommandation, octobre 2022 (nouvel onglet)cnil.fr