Des modèles d’IA auraient pu être entraînés sur 12 000 clés API et mots de passe valides

Des milliers de clés API et mots de passe actifs se baladent dans des données publiques utilisées pour entraîner certaines IA. Une découverte qui relance le débat sur la sécurité des modèles et les risques liés à leurs sources d’apprentissage.

Vous le savez sûrement maintenant, l’intelligence artificielle se nourrit de volumes de données massifs pour perfectionner ses modèles. Normalement, ces jeux de données sont censés être maîtrisés en amont. Et pourtant, les équipes de Truffle Security viennent de révéler des failles dans le process. Près de 12 000 clés API et mots de passe valides ont ainsi été retrouvés dans l’un des derniers datasets de Common Crawl, base d’archives publique utilisée pour entraîner des modèles d’IA, dont ceux de DeepSeek. Une découverte inquiétante, qui pose la question de l’impact de ces données sur les modèles d’IA, de leur influence sur les pratiques de développement, et d’une hypothétique restitution d’informations sensibles.

Une exposition massive de données sensibles

Pour remettre les choses en contexte, on rappellera que Common Crawl est une sorte de gigantesque snapshot du web, un corpus accessible au public et largement exploité dans l’entraînement des modèles d’IA. À titre d’exemple, rien qu’en décembre dernier, la plateforme a collecté près de 400 To de données web compressées, issues de 2,67 milliards de pages. C’est justement sur cet immense dataset que Truffle Security a mené son enquête… et les résultats donnent matière à s'interroger.

Car après analyse, le bilan est sans appel. L’entreprise affirme avoir détecté 11 908 clés API et identifiants valides, identifiés comme actifs par un processus de vérification automatique. Dispersés sur plus de 2,76 millions de pages web, ces secrets étaient parfois exposés en clair dans du HTML ou du JavaScript. Au milieu de cette manne ultra-sensible, des clés API MailChimp, des webhooks Slack, des tokens WalkScore, et même une clé AWS root (heureusement inopérante pour S3 Basic Auth) – autant d’informations critiques qui, en cas d’exploitation malveillante, pourraient compromettre des infrastructures entières.

Autre constat alarmant : 63 % de ces clés étaient répliquées sur plusieurs pages, la palme de la catastrophe revenant à une même clé WalkScore, apparue 57 029 fois sur 1 871 sous-domaines.

Si les équipes de Truffle Security ont pu mettre la main dessus, c’est bien parce que ces identifiants n’étaient pas protégés par des variables d’environnement serveur. Une erreur de développement classique, mais lourde de conséquences dans la mesure où un très basique « afficher le code source » sur une page web aurait suffi à récupérer une grande partie de ces informations.

Des risques sous-estimés, pourtant réels

Puisque les LLM s’entraînent sur des milliards de lignes de texte, doit-on craindre qu’ils puissent reproduire ces erreurs, voire restituer des données critiques sur demande s’ils intègrent du code mal sécurisé ? En théorie, non. Si les choses sont bien faites, les jeux d'entraînement sont censés être filtrés pour éliminer les contenus sensibles.

Mais en pratique, c’est une tout autre histoire : il est quasiment impossible de tout nettoyer, surtout sur des volumes aussi conséquents que ceux fournis par Common Crawl. Aussi, même en excluant une partie de ces clés API avant l’entraînement, rien ne garantit que certaines ne soient pas déjà intégrées dans des modèles en production.

Et c’est là que les choses se gâtent. À force d’exemples répétés, les LLM risquent de normaliser de mauvaises pratiques. Car s’ils observent régulièrement des identifiants écrits en dur dans le code source, ils pourraient finir par suggérer de telles méthodes comme solution de développement acceptable, et donc contribuer à la diffusion involontaire de mauvaises habitudes de codage.

Se pose aussi la question de la restitution. Ces clés et identifiants ne sont pas juste de simples bouts de texte oubliés sur le web. Ils permettent d’accéder à des services critiques. Les clés MailChimp, par exemple, pourraient être utilisées pour envoyer des mails frauduleux sous une identité légitime. Une clé AWS root compromise pourrait ouvrir la porte sur des données sensibles stockées sur Amazon Web Services. Des webhooks Slack exposés pourraient permettre d’envoyer des messages dans des canaux privés, sans authentification préalable.

En réalité, leur divulgation par des chatbots dépend de nombreux facteurs, comme la fréquence d’apparition et les filtres appliqués par le fournisseur. Si les LLM sont conçus pour éviter la restitution de secrets, la présence de telles données dans leurs jeux d’entraînement pose néanmoins un risque théorique. Bref, pour la sécurité infaillible des infrastructures, des comptes et des données, on repassera.

Comment limiter les risques d'entraînement IA sur les données sensibles ?

Sans surprise, si ces erreurs sont humaines, les solutions le sont aussi. À tous les développeurs et développeuses qui lisez ces lignes, cessez d’hardcoder des clés API et des identifiants dans du code accessible en ligne. Usez et abusez des variables d’environnement serveur, et n’hésitez pas à recourir à des gestionnaires de secrets. Si vous utilisez l'intelligence artificielle pour accompagner vos projets, pensez aussi à guider votre chatbot en lui imposant des consignes strictes – par exemple : "ne suggère jamais d'identifiants harcodés ou d'autres pratiques de développement non sécurisées".

Dans le développement de l’IA, pour éviter que les modèles ne manipulent des informations sensibles comme des clés API ou des identifiants, il faut agir à deux niveaux. D’abord en renforçant les filtres appliqués aux datasets avant l’entraînement, afin d’éliminer ces informations avant même qu’elles ne soient assimilées. Ensuite en intégrant des garde-fous directement dans les modèles, pour empêcher deux dérives majeures : la restitution accidentelle de secrets ingérés pendant l’entraînement, et la génération de code source encourageant des pratiques risquées, comme le codage en dur d’identifiants dans un script.

Dans toute cette affaire, cette enquête révèle surtout un problème structurel. Les données utilisées pour entraîner les LLM ne sont pas toujours maîtrisées. Si des informations sensibles comme des clés API peuvent se retrouver dans ces datasets, on peut légitimement s’inquiéter de ce qu’il advient d’autres données confidentielles. Car l’IA ne fait que reproduire ce qu’on lui donne. Si ses bases d’apprentissage contiennent des vulnérabilités, il est probable qu’elle les perpétue d’une manière ou d’une autre.

Source : Truffle Security