Vol de clés d'API et attaques par distillation : comment protéger les clés de vos outils d'IA

Une clé d'API d'un fournisseur d'IA est un justificatif au porteur : celui qui la détient peut dépenser votre argent et consommer votre quota, et le fournisseur ne peut pas distinguer ce détenteur de vous. Une attaque par distillation est l'une des raisons pour lesquelles quelqu'un veut beaucoup de clés de ce type. Elle entraîne un modèle moins coûteux sur les réponses d'un modèle plus puissant et demande un très grand nombre de requêtes payantes. Si les requêtes passent par des clés volées, quelqu'un d'autre les paie et le trafic ne ressemble pas à celui d'un seul client. La défense pratique consiste à limiter ce que chaque clé peut faire, à surveiller ce qu'elle fait et à garder les clés dans le moins d'endroits possible.

Le 17 octobre 2026, OpenCode a signalé un incident de sécurité qu'il a relié à une attaque par distillation à grande échelle. Cet article part de ce qu'OpenCode a dit, explique ce qu'est la distillation et pourquoi les clés sont la cible, énumère les signes d'abus et propose des listes de contrôle pour ceux qui utilisent des outils d'IA et pour ceux qui les construisent. Il précise aussi ce que zn-gate fait face à ce problème et ce qu'il ne fait pas.

Qu'est-ce qu'OpenCode a dit qu'il s'était passé ?

Nous ne reprenons que ce qu'OpenCode a dit en public. La publication d'OpenCode sur X et son avis aux utilisateurs touchés sont cités ci-dessous tels que les rapportent Officechai et Blockonomi, avec des liens. Ce qu'OpenCode n'a pas dit publiquement est signalé comme non confirmé.

Le 17 octobre 2026, OpenCode a écrit sur X : « We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users » (en français : nous avons subi une faille de sécurité la nuit dernière, liée à une attaque par distillation à grande échelle qui a touché 1,4 % des utilisateurs d'OpenCode Console). La même publication, telle que la cite Blockonomi, indique que les utilisateurs touchés ont été prévenus par e-mail le matin même et que « if you did not get an email you were not impacted » (si vous n'avez pas reçu d'e-mail, vous n'êtes pas concerné). OpenCode a ajouté que « it was a subset of users who had external providers » (il s'agissait d'un sous-ensemble d'utilisateurs qui avaient des fournisseurs externes).

L'avis envoyé aux utilisateurs touchés, tel que le cite Officechai, dit qu'OpenCode a « identified unauthorized access to a legacy system » (identifié un accès non autorisé à un système ancien) et que « third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed » (les clés de fournisseurs tiers, par exemple OpenAI ou Anthropic, enregistrées dans votre workspace ont pu être exposées). Il ajoute que « the incident is ongoing so we cannot share more details at this point » (l'incident est en cours, nous ne pouvons donc pas donner plus de détails pour le moment).

C'est tout ce qui est confirmé. Certaines choses en découlent, d'autres non :

• Le 1,4 % est une part des utilisateurs d'OpenCode Console, pas de tous ceux qui utilisent l'agent de code open source OpenCode. La documentation d'OpenCode décrit la Console comme l'endroit où l'on ajoute ses informations de facturation et du crédit et où l'on copie sa clé d'API, et indique que les propriétaires et administrateurs d'un workspace peuvent connecter leurs propres fournisseurs.
• Selon l'avis, les clés exposées sont des clés de fournisseurs tiers enregistrées dans un workspace.
• OpenCode n'a pas publié comment les attaquants sont entrés, combien de temps ils ont eu accès, combien de clés ont été utilisées ni quels modèles ont été appelés. Tout ce que vous lirez ailleurs sur ces points est une hypothèse.

Nous utilisons OpenCode tous les jours, dans les versions officielles et dans des builds que nous adaptons à notre propre configuration, et nous faisons confiance au produit. Nous n'avons aucune relation commerciale avec l'équipe d'OpenCode. Nous écrivons sur cet incident parce qu'il montre un schéma que chaque éditeur d'outils d'IA et chaque utilisateur doivent anticiper, et parce que l'équipe s'est montrée transparente alors que l'enquête se poursuit. Nous n'en savons pas plus que ce qu'elle a dit et nous ne faisons pas de conjectures sur ses systèmes.

Qu'est-ce qu'une attaque par distillation, et qu'est-ce que l'extraction de modèle ?

La distillation consiste à « training a less capable model on the outputs of a stronger one » (entraîner un modèle moins capable sur les sorties d'un modèle plus puissant), selon les mots de la publication d'Anthropic sur les attaques par distillation. La technique est légitime et ancienne. Hinton, Vinyals et Dean l'ont décrite en 2015 dans Distilling the Knowledge in a Neural Network comme un moyen de compresser un ensemble de modèles en un modèle plus petit et moins coûteux à exécuter. Les fournisseurs distillent leurs propres modèles pour proposer à leurs clients des versions plus petites et moins chères.

L'abus consiste à distiller le modèle d'un autre sans autorisation. La publication d'Anthropic dit que des concurrents l'utilisent pour acquérir des capacités « in a fraction of the time, and at a fraction of the cost » (en une fraction du temps et du coût) de leur développement, et que les modèles ainsi obtenus conservent difficilement les garde-fous d'origine. Anthropic y rapporte trois campagnes qui ont généré ensemble plus de 16 millions d'échanges avec Claude via environ 24 000 comptes frauduleux et dit que les campagnes illicites se reconnaissent à leur motif : « massive volume concentrated in a few areas, highly repetitive structures » (volume massif concentré sur quelques domaines, structures très répétitives).

Une idée voisine est l'extraction de modèle. Dans Stealing Machine Learning Models via Prediction APIs (USENIX Security 2016), Tramèr et ses coauteurs montrent que quelqu'un qui n'a qu'un accès par requêtes à un modèle peut en copier fidèlement le comportement, et que retirer les valeurs de confiance des sorties ne l'empêche pas entièrement. L'article porte sur des modèles classiques, pas sur de grands modèles de langage, mais la leçon reste valable : si l'on peut interroger un modèle assez longtemps, son comportement peut être copié à partir de ses réponses.

Aucune des deux techniques n'exige l'accès aux poids. Il faut du volume. C'est là que les clés interviennent.

Pourquoi les attaquants utilisent-ils des clés d'API volées pour cela ?

Il y a deux raisons, toutes deux liées au coût et à la visibilité.

La victime paie. Une campagne de distillation demande beaucoup de requêtes, et le fournisseur facture chacune. Avec une clé volée, la facture va au propriétaire de la clé. Le coût de l'attaquant se réduit à l'effort de collecter des clés.

La piste est dispersée. Un fournisseur qui voit un compte envoyer des millions de requêtes répétitives peut le détecter, comme le décrit Anthropic, avec des classifieurs, des empreintes comportementales et des outils qui repèrent une activité coordonnée sur de nombreux comptes. Si le même volume est réparti sur des centaines de clés de clients différents, chaque clé envoie une petite quantité de trafic d'apparence ordinaire. La vue du fournisseur sur un compte donné semble banale et le motif n'apparaît qu'en regardant de nombreux comptes ensemble. La détection côté fournisseur est difficile pour cette raison, et le propriétaire de la clé peut être la première personne à pouvoir voir que quelque chose cloche, car lui seul sait quel est son usage normal.

Le propriétaire de la clé a donc un intérêt à la surveiller que personne d'autre n'a.

D'où viennent les clés volées ?

Les clés fuient des endroits où on les range. En pratique, voici les plus courants :

La dernière ligne est celle que cet incident met en évidence. Quand vous enregistrez une clé de fournisseur dans la console d'une autre entreprise, vous ajoutez la sécurité de cette entreprise à celle de la clé. Ce peut être un bon compromis, car un service doté d'une équipe peut mieux protéger une clé qu'un ordinateur portable. Cela signifie aussi qu'une faille dans ce service peut exposer les clés de clients qui ont tout fait correctement sur leurs propres machines.

Cet article ne décrit pas comment ces fuites sont exploitées, et nous ne le ferons pas. Les défenses n'en dépendent pas.

Comment savoir qu'une clé est utilisée à votre insu ?

Les signes apparaissent côté fournisseur : c'est donc le tableau de bord de chaque fournisseur qu'il faut regarder. Cherchez :

• Une dépense qui augmente sans changement dans votre travail. Un saut d'un jour à l'autre, ou une hausse régulière à une heure où personne ne travaille.
• Des modèles que vous n'utilisez pas. Si vous n'appelez qu'un modèle et que la page d'usage en montre un autre, la clé est utilisée par quelqu'un d'autre.
• Un usage à des heures ou à des volumes inhabituels, comme un débit élevé et constant toute la nuit.
• Un usage par clé qui ne correspond pas à son rôle. Une clé créée pour un outil qui affiche du trafic quand cet outil est fermé.
• Des frais inattendus ou l'atteinte d'une limite que vous ne pensiez pas atteindre.
• Des avis du fournisseur. Les fournisseurs détectent aussi les abus et peuvent vous écrire ou désactiver une clé.

Aucun de ces signes ne prouve à lui seul un vol. Chacun est une raison de vérifier. Le moyen le moins coûteux de les rendre visibles est de configurer des alertes avant d'en avoir besoin.

Comment protéger vos clés en tant qu'utilisateur ?

Le but est qu'une clé volée fasse peu de dégâts, pendant peu de temps, et que vous le remarquiez vite. Ces mesures fonctionnent ensemble :

1. Utilisez une clé par outil et par usage. Quand une clé fuit, vous savez d'où, vous pouvez la révoquer sans tout casser et sa page d'usage raconte une histoire claire. Les fournisseurs regroupent les clés en projets ou workspaces, ce qui permet de séparer les environnements. Les bonnes pratiques de production d'OpenAI recommandent des projets distincts pour le staging et la production, ce qui permet aussi des limites de débit et de dépense propres à chacun.
2. Fixez des limites de dépense et des alertes. La documentation d'OpenAI décrit des alertes qui vous préviennent quand l'usage dépasse un montant en dollars et des limites strictes qui arrêtent le trafic quand la dépense atteint la limite. La limite stricte est le contrôle qui transforme une perte sans plafond en perte bornée. Fixez-la plus bas que ce que vous croyez nécessaire et relevez-la quand vous l'atteignez.
3. Donnez une expiration aux clés et renouvelez-les. OpenAI recommande de fixer une date d'expiration à la création d'une clé de projet et d'avoir un processus de rotation régulier : créer une clé de remplacement, mettre à jour vos applications, vérifier qu'elle fonctionne, puis révoquer l'ancienne. La documentation de Google recommande de renouveler les clés périodiquement, indique que les clés d'API sans restriction ne sont pas sûres et recommande de restreindre chaque clé aux API dont elle a besoin.
4. Révoquez, ne vous contentez pas de remplacer, au moindre doute. Si un outil que vous utilisez signale un incident et que vous ne savez pas si votre clé est concernée, révoquez la clé. En créer une nouvelle prend une minute. Examinez ensuite l'usage de l'ancienne clé les jours précédant sa révocation.
5. Gardez les clés hors du code, des dépôts et des journaux. Utilisez des variables d'environnement ou un gestionnaire de secrets, comme le recommande OpenAI, et gardez .env hors du contrôle de version.
6. Ne stockez pas une clé dans la console d'un tiers sauf si le service en a besoin. Si l'outil s'exécute sur votre machine, la clé peut rester sur votre machine. Si le service doit appeler le fournisseur à votre place, utilisez une clé créée uniquement pour cela, avec son propre projet, une limite de dépense et une expiration.
7. Relisez de temps en temps la liste des clés. Supprimez les clés des outils que vous n'utilisez plus. Les consoles des fournisseurs indiquent quand chaque clé a été créée, et certaines indiquent quand elle a été utilisée pour la dernière fois. L'Admin API d'Anthropic, par exemple, expose l'état, la date de création et l'expiration de chaque clé et ne renvoie jamais le secret.

Que doivent faire ceux qui créent des outils d'IA ?

Si votre produit stocke des clés qui appartiennent à vos clients, vous avez accepté une responsabilité que l'ordinateur portable d'un utilisateur n'a pas, et la conception doit le montrer.

• Chiffrez les clés stockées avec un service de clés géré, comme un KMS cloud, avec des contrôles d'accès qui séparent les personnes et les services pouvant déchiffrer de ceux qui font seulement tourner le produit. Ne stockez que ce dont vous avez besoin pour appeler le fournisseur.
• Appliquez le moindre privilège entre vos composants. La partie du système qui appelle un fournisseur doit pouvoir lire les clés dont elle a besoin pour la requête en cours, pas tout le stock.
• Ne réaffichez pas une clé après son enregistrement. Montrez un indice, comme les derniers caractères, et laissez l'utilisateur la remplacer. Les objets clé de l'Admin API d'Anthropic fonctionnent ainsi, avec un indice partiel et sans le secret.
• Appliquez des quotas par clé et des contrôles d'anomalie de votre côté. Vous voyez le trafic de tous vos clients avant chacun d'eux. Une clé qui fait soudain des milliers de requêtes de même forme mérite une pause et une question.
• Retirez les anciens systèmes. Le code et les stockages de données encore accessibles mais qui ne sont plus utilisés activement tendent à recevoir le moins de revue. Supprimez-les, ou maintenez-les sous les mêmes contrôles que le système en production.
• Facilitez la rotation. Si révoquer et remplacer une clé est une longue procédure, les utilisateurs ne le font pas.
• Prévenez vos clients tôt et clairement, en disant quoi faire ensuite. Un message court qui indique quels utilisateurs sont touchés et quoi renouveler permet d'agir avant la fin de l'enquête.

Que fait zn-gate face à cela, et que ne fait-il pas ?

zn-gate est une couche de sécurité open source qui s'exécute sur votre machine, entre votre agent de code et les outils et contenus qu'il touche. Il aide pour la partie du problème qui se trouve sur votre machine. Il n'aide pas pour la partie qui se trouve dans le cloud de quelqu'un d'autre. Nous indiquons les deux pour que vous ne comptiez pas sur lui pour ce qu'il ne fait pas.

Ce qu'il fait. Ces affirmations figurent dans le README de zn-gate et dans la documentation Scrubber et coffre de secrets :

• Avec le plugin Claude Code, ou les hooks de zn pour Codex CLI, Cursor et OpenCode, l'agent de code ne peut pas lire les fichiers .env contenant de vraies valeurs ni les fichiers d'identifiants comme ~/.aws/credentials. C'est un garde-fou, pas un bac à sable.
• Les secrets présents dans ce que renvoient les outils de l'agent, comme les lectures de fichiers et la sortie de commandes, sont remplacés par des marqueurs avant que le modèle les voie, et un secret collé dans un prompt est bloqué. Dans Cursor, seule la sortie des outils MCP est nettoyée.
• zn env shadow .env déplace vos valeurs vers un coffre chiffré sur votre machine et laisse des marqueurs comme __ZN_STRIPE_KEY__ dans le fichier. Le coffre est local et n'est pas synchronisé.
• Une clé peut être utilisée sans que le modèle la voie. Une commande que vous avez autorisée reçoit la valeur via zn run, et sa sortie est masquée. Pour les API HTTP, le serveur MCP secrets n'envoie la valeur qu'aux hôtes que vous avez autorisés et renvoie la réponse avec les secrets remplacés par des marqueurs. Aucun outil ne renvoie une valeur à l'agent.

Ce qu'il ne fait pas.

• Il ne protège pas une clé stockée dans le cloud d'un tiers. Dans le cas ci-dessus, les clés à risque étaient celles enregistrées dans un workspace d'une console hébergée. zn-gate ne se trouve pas sur le chemin entre ce service et le fournisseur, il ne peut donc pas réduire cette exposition. Seuls le service et vous, en limitant et en renouvelant cette clé, le pouvez.
• Il ne remplace ni les limites de dépense, ni les alertes, ni la rotation. Ce sont vos contrôles chez le fournisseur.
• Il n'arrête pas un processus que vous lancez vous-même, ni un logiciel malveillant exécuté sous votre utilisateur. Son modèle de menaces indique que tout programme exécuté sous votre utilisateur du système peut demander un secret par son nom à un coffre déverrouillé, et recommande de verrouiller le coffre avec zn lock quand vous ne l'utilisez pas.
• Une commande que vous avez autorisée détient toujours la valeur pendant son exécution. zn contrôle où va un identifiant, pas ce qu'un programme autorisé en fait.
• Il ne détecte pas une attaque par distillation. Le trafic côté fournisseur est hors de ce qu'il voit.

Ce que zn-gate supprime, c'est une source courante de fuites : la clé en clair dans un fichier .env où un agent ou une injection de prompt peut la trouver. Une dépendance compromise qui s'exécute sous votre utilisateur est un cas différent : voir le modèle de menaces ci-dessus. Garder une clé hors de portée de l'agent sur votre machine est utile, et c'est une mesure parmi celles énumérées plus haut.

Quelle liste de contrôle pouvez-vous utiliser dès aujourd'hui ?

Pour les utilisateurs :

• Chaque outil a sa propre clé, dans son propre projet ou workspace.
• Chaque clé a une limite de dépense et une alerte à un montant inférieur.
• Chaque clé a une date d'expiration et vous savez quand vous la renouvellerez.
• Vous savez où chaque clé est enregistrée : environnement local, coffre, secret de CI ou console d'un tiers.
• Les clés dans des consoles de tiers sont uniquement celles dont le service a besoin, avec une limite.
• Les fichiers .env ne sont pas dans le contrôle de version et l'agent de code ne peut pas les lire (npx -y zn-gate check).
• Vous regardez l'usage par clé au moins une fois par semaine, et après tout avis d'incident d'un éditeur d'outils.
• Les clés inutilisées sont supprimées.
• Si un éditeur signale un incident qui peut vous concerner : créez une nouvelle clé, mettez l'outil à jour, révoquez l'ancienne et examinez son usage.

Pour ceux qui construisent des outils :

• Les clés des clients sont chiffrées avec un service de clés géré, avec des droits de déchiffrement étroits.
• Une clé n'est jamais réaffichée après son enregistrement.
• Des quotas par clé et des alertes d'anomalie existent de votre côté.
• Les anciens systèmes et stockages sont retirés ou couverts par les mêmes contrôles.
• Il existe une procédure testée pour prévenir les clients et renouveler toutes les clés stockées.

Que ne couvre pas cet article ?

• Il ne décrit pas comment l'incident d'OpenCode s'est produit au-delà de ce qu'OpenCode a dit, car ce n'est pas public.
• Il ne donne aucune méthode pour voler des clés ni pour mener une campagne de distillation.
• Il ne couvre pas la détection côté fournisseur au-delà de ce que les fournisseurs ont publié.
• Il ne couvre pas les clés de services qui ne sont pas des fournisseurs d'IA, bien que la plupart des conseils s'y appliquent.

Questions fréquentes

Qu'est-ce qu'une attaque par distillation ?

Entraîner un modèle moins capable sur les sorties d'un modèle plus puissant. Anthropic décrit la distillation illicite comme l'usage que font des concurrents pour acquérir des capacités en une fraction du temps et du coût nécessaires pour les développer. Elle exige un très grand nombre de requêtes vers le modèle le plus puissant.

Pourquoi un attaquant volerait-il des clés d'API pour une attaque par distillation ?

Parce que les requêtes se paient et doivent venir de quelque part. Avec une clé volée, c'est le propriétaire de la clé qui paie la facture, et le trafic est réparti sur de nombreux comptes au lieu d'un seul compte que le fournisseur pourrait repérer et bloquer.

Comment savoir si ma clé de fournisseur d'IA est utilisée à mon insu ?

Cherchez une dépense qui augmente sans changement dans votre travail, des requêtes vers des modèles que vous n'utilisez jamais, un usage à des heures où personne ne travaille ou du trafic provenant d'outils que vous ne reconnaissez pas. Les alertes de dépense et les vues d'usage par clé sont les premiers signaux.

Que faire si un outil que j'utilise a subi une fuite de clés ?

Créez une nouvelle clé, mettez à jour l'outil qui en a besoin, révoquez l'ancienne, puis examinez l'usage de l'ancienne clé sur la période précédant la révocation. Faites-le même si vous n'êtes pas sûr que votre clé ait été touchée.

zn-gate protège-t-il une clé que j'ai enregistrée dans la console cloud d'un tiers ?

Non. zn-gate s'exécute sur votre machine, empêche l'agent de code de lire vos fichiers .env et d'identifiants, garde les valeurs secrètes hors de ce que voit le modèle et peut utiliser une clé d'un coffre local sans la montrer au modèle. Une clé que vous avez collée dans le service d'un tiers est hors de sa portée.

Dois-je garder mes clés de fournisseur dans la console cloud d'un outil ?

Seulement si l'outil en a besoin pour exécuter un service à votre place. S'il peut fonctionner sur votre machine avec la clé dans votre propre environnement ou un coffre local, c'est un endroit de moins à protéger. Si vous l'y enregistrez, fixez-lui une limite de dépense et utilisez une clé dédiée à cet usage.

À quelle fréquence faut-il renouveler les clés d'API ?

Les recommandations d'OpenAI conseillent de fixer une date d'expiration à la création d'une clé de projet et d'avoir un processus de rotation régulier. La fréquence dépend du dommage qu'une seule clé peut causer : une clé avec une limite de dépense basse peut être renouvelée moins souvent qu'une clé sans limite.

---

Pour les bases sur la façon de garder un .env hors de portée d'un agent, voir comment empêcher Claude Code, Codex CLI, Cursor et OpenCode de lire votre .env avec une seule commande. Pour voir comment un hook d'agent pouvait être contourné et comment cela a été corrigé, lisez comment un agent de code pouvait lire votre fichier .env de façon indirecte. zn-gate est sous licence MIT, s'exécute en local et ne demande aucun compte : GitHub et Install.