# Un audit d’agence : des clés de LLM oubliées après un test abandonné > Quatre clés d'API de fournisseurs de LLM, actives depuis plus d'un an, versionnées dans un dépôt privé. Retour sur un audit transversal qui a mis au jour ce qu'un prototype abandonné laisse derrière lui. - Auteur : Clément Hadrot - Publié le : 2024-07-31 - Mis à jour le : 2024-07-31 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/audit-agence-cles-api-llm-oubliees/ ## L’essentiel - Un prototype abandonné laisse souvent ses identifiants actifs derrière lui - Une clé versionnée dans un dépôt privé reste un risque, pas une protection - L'inventaire régulier des clés actives doit inclure les projets arrêtés Quatre. C'est le nombre de clés d'API de fournisseurs de LLM que l'audit transversal mené par l'agence Kolibri sur son propre parc de projets a retrouvées actives, alors qu'elles appartenaient toutes à des prototypes abandonnés depuis plusieurs mois, certains depuis plus d'un an. Aucune de ces clés n'avait été révoquée au moment où le projet correspondant avait été mis de côté. L'audit ne portait initialement pas sur ce sujet précis : il visait à dresser un inventaire général des accès actifs sur l'ensemble des projets clients de l'agence, dans le cadre d'une démarche de mise en conformité plus large. C'est en croisant la liste des clés actives chez les différents fournisseurs avec la liste des projets réellement en production que l'écart est apparu. ## Comment ces clés ont survécu à l'abandon du projet Le scénario s'est répété presque à l'identique sur les quatre cas : un prototype avait été développé rapidement pour une démonstration client, avec une clé d'API créée pour l'occasion et versionnée dans un fichier de configuration d'un dépôt privé, jugé suffisamment sécurisé puisque non public. Le projet n'ayant pas convaincu ou ayant été remplacé par une autre solution, le dépôt avait simplement cessé d'être actif, sans qu'aucune étape de nettoyage ne prévoie explicitement la révocation des clés utilisées. Un dépôt privé protège contre un accès non autorisé au code source, pas contre l'usage continu d'une clé qui reste valide tant qu'elle n'est pas explicitement révoquée chez le fournisseur. Ce point, souvent mal compris, a conduit l'équipe à considérer ces clés comme un non-sujet une fois le dépôt mis en sommeil, alors que rien côté fournisseur n'avait changé. ## Ce que l'audit a révélé sur l'usage réel Sur les quatre clés retrouvées, deux affichaient une activité nulle depuis l'arrêt du projet correspondant, ce qui suggérait un simple oubli sans risque immédiat. Les deux autres, en revanche, montraient des appels sporadiques mais réguliers, dont l'origine n'a pu être expliquée avec certitude : possiblement un ancien environnement de test resté déployé quelque part, ou un service tiers qui continuait d'appeler cette clé sans que personne ne s'en souvienne. > L'essentiel à retenir : Un prototype abandonné laisse souvent ses identifiants actifs derrière lui ; Une clé versionnée dans un dépôt privé reste un risque, pas une protection ; L'inventaire régulier des clés actives doit inclure les projets arrêtés Cette incertitude sur l'origine des appels a constitué le signal le plus préoccupant de l'audit : une clé active dont personne dans l'agence ne pouvait expliquer l'usage représente un risque de sécurité concret, indépendamment de la performance ou de la pertinence de l'intégration qui l'utilisait à l'origine, un sujet que l'audit n'avait pas vocation à évaluer. ### Les mesures correctives appliquées 1. Révocation immédiate des quatre clés identifiées, après confirmation qu'aucun service en production n'en dépendait. 2. Ajout d'une étape obligatoire de révocation des clés dans la procédure de clôture de tout projet interne, y compris les prototypes non facturés. 3. Mise en place d'un inventaire trimestriel des clés actives chez chaque fournisseur de LLM utilisé par l'agence, comparé à la liste des projets en cours. 4. Migration des clés restantes vers un gestionnaire de secrets centralisé, plutôt qu'un stockage dispersé dans des fichiers de configuration par projet. > Un projet abandonné n'est jamais vraiment terminé tant que ses accès n'ont pas été révoqués : la clôture d'un prototype mérite la même rigueur que sa mise en production. ## Ce que l'audit n'a pas cherché à évaluer La qualité ou la performance des intégrations qui utilisaient ces clés n'entrait pas dans le périmètre de cette mission, centrée exclusivement sur la sécurité des accès. De même, l'audit n'a pas cherché à estimer un coût financier lié à ces appels résiduels, jugé secondaire face au risque de sécurité que représentait leur simple existence. ## En résumé Un prototype abandonné n'est jamais un non-événement du point de vue de la sécurité : tant que ses clés d'API restent actives, il continue d'exposer l'agence à un risque, silencieusement, parfois pendant plus d'un an. L'inventaire régulier des clés actives, incluant explicitement les projets arrêtés et non pas seulement ceux en production, s'est imposé comme la mesure la plus simple à instaurer pour éviter que ce type de découverte ne se reproduise.