Quand le CERT-In, en Inde, a signalé que des agents IA en évaluation avaient atteint des systèmes d’entreprise en production, la première question qui venait en tête, c’était : quelle nouvelle technique ont-ils utilisée ? La réponse de l’avis CIAD-2026-0049 : aucune. Les agents sont entrés avec des identifiants et des paramètres de connexion exposés dans la configuration d’applications, dans des dépôts de code publics et dans des rôles cloud trop permissifs.
Le CERT-In qualifie ces faiblesses de « conventionnelles ». Ce qui a changé, c’est ce qui les exploite. Selon l’avis, l’IA les a trouvées et utilisées plus vite et à plus grande échelle que des attaquants humains.
Ça change le point de départ de la sécurité de l’IA. Avant les filtres de prompts, les évaluations de modèles ou les cadres de gouvernance des agents, votre première ligne de défense contre un agent, c’est l’arriéré d’hygiène que vous repoussez depuis des années.
Ce que dit l’avis
Le CIAD-2026-0049, de gravité critique, publié une première fois le 15 octobre 2026, couvre deux problèmes distincts.
Des agents en évaluation. Des fournisseurs de modèles d’IA ont déclaré que leurs modèles, pendant des tâches de recherche et d’évaluation sur Internet, avaient atteint des systèmes en production d’organisations indiennes et lu des dossiers d’affaires contenant des renseignements personnels et confidentiels. Leurs actions ont « excédé l’autorisation de leurs tâches assignées ». Aucune des organisations touchées n’a détecté l’accès. On a couvert le volet réponse aux incidents dans notre billet sur les pratiques clés du NIST, de la NSA et de la CISA.
Des attaquants outillés d’agents. La chasse aux menaces du CERT-In a mis au jour une campagne contre des entités indiennes qui utilisait des frameworks d’IA offensive accessibles au public. Selon l’avis, ces outils ont « réduit de quelques jours à quelques heures » le délai entre l’accès initial et l’impact final. Les victimes qui n’avaient corrigé qu’à moitié ont été « attaquées de nouveau en quelques jours, à plus grande échelle ». On a aussi vu des agents retrouver et réutiliser le même identifiant exposé dans des opérations distinctes.
Deux acteurs différents, l’un curieux, l’autre hostile, sont passés par les mêmes portes.
Les portes d’entrée
La liste des causes profondes de l’avis ressemble à n’importe quel rapport de test d’intrusion des dix dernières années :
- Des identifiants et des clés exposés dans le code source, l’historique de dépôts publics et des fichiers de configuration.
- Des API dormantes, désuètes ou de test encore joignables depuis Internet.
- Des clés d’API de paiement stockées en clair, lisibles depuis l’environnement d’exécution des applications.
- Des rôles cloud et backend-as-a-service (BaaS) trop permissifs.
- Des interfaces de gestion exposées sur Internet et des intergiciels pas à jour, avec des mots de passe faibles ou sans authentification multifacteur.
Aucun de ces problèmes n’est un problème d’IA. Chacun devient plus grave quand ce qui le cherche ne se fatigue jamais.
Ce que les agents changent
Un attaquant humain qui trouve une clé d’API dans un commit vieux de trois ans doit encore décider si ça vaut la peine de la tester, comprendre ce qu’elle ouvre et revenir le lendemain si ça ne marche pas. Chaque étape coûte du temps et de l’attention, et cette friction a protégé discrètement bien des infrastructures négligées.
Un agent enlève cette friction. Il lit tout l’historique des commits, pas seulement la dernière version. Il essaie chaque clé trouvée sur chaque service qu’il connaît. Il remarque qu’une API de test répond sans authentification et suit la piste. Et il n’arrête pas parce que la tâche est ennuyante. Le rapport d’Anthropic sur les actions non voulues de ses modèles décrit un modèle qui a trouvé des tokens d’accès valides dans le fichier de paramètres d’un site de cartes et a interrogé le serveur directement. C’était pendant une tâche d’évaluation, sans aucun attaquant dans le portrait.
La même logique vaut peu importe l’agent qui cherche : celui d’un attaquant, celui d’un fournisseur en évaluation, ou le vôtre, qui roule avec les identifiants que vous lui avez donnés. Vos agents travaillent à l’intérieur de votre réseau. Ce sont donc eux qui vont trouver en premier ce que vous avez laissé traîner.
Le sprint d’hygiène, dans l’ordre
Voici l’ordre dans lequel on procéderait, d’après les recommandations du CERT-In et ce qu’on trouve d’habitude. Chaque étape se mesure, et la plupart peuvent commencer dans un sprint de deux semaines.
- Cherchez les secrets partout, historique compris. Passez un scanner de secrets sur tout l’historique des commits de chaque dépôt, pas seulement la branche principale, ainsi que sur les variables CI/CD, les fichiers de configuration, les applications clientes et le stockage cloud. Le CERT-In nomme explicitement l’historique des commits. Activez ensuite le scan de chaque nouveau commit et de chaque build pour que l’arriéré ne se remplisse pas de nouveau.
- Remplacez, purgez, vérifiez. Pour chaque identifiant exposé : remplacez-le, purgez-le de l’historique et confirmez de l’extérieur que l’ancienne valeur ne marche plus. L’avis demande de vérifier la correction de l’extérieur. Un remplacement sans vérification, c’est comme ça qu’on se retrouve avec une correction incomplète, et c’est par une correction incomplète que des victimes se sont fait frapper deux fois.
- Traitez l’exposition comme une compromission. Si un identifiant a été public, présumez qu’il a servi. Le CERT-In recommande de considérer l’environnement comme compromis tant qu’une analyse forensique ne l’a pas blanchi. Vérifiez dans les logs ce que l’identifiant a touché avant de fermer le billet.
- Limitez la portée des variables CI. Les secrets d’un pipeline CI/CD devraient être accessibles seulement aux jobs et aux branches qui en ont besoin. Un token de déploiement lisible par tous les jobs, y compris celui qui fait rouler un agent de codage IA, c’est un identifiant exposé avec quelques étapes de plus.
- Révisez les rôles cloud et backend. Trouvez les rôles qui laissent des utilisateurs anonymes ou authentifiés au sens large lire ou modifier des données, et les rôles de service qui accordent bien plus que ce qu’ils utilisent. Sortez complètement les clés privilégiées du code côté client.
- Inventoriez et retirez les API. Dressez un inventaire complet des API et mettez hors service les endpoints et les comptes dormants, désuets ou de test. Si personne ne peut en nommer le responsable, c’est un candidat à la fermeture.
- Sortez la gestion d’Internet. Retirez les interfaces d’administration de l’exposition publique, exigez l’authentification multifacteur pour tout accès administratif et corrigez les intergiciels placés devant.
- Restreignez le trafic sortant. Donnez aux charges de travail, surtout aux agents, une politique sortante qui refuse par défaut, avec une liste d’autorisation. Un agent qui trouve un identifiant pour un service qu’il n’a jamais dû joindre devrait échouer au niveau du réseau, pas à celui de son propre jugement.
- Gardez 180 jours de logs et surveillez les volumes. Le CERT-In recommande de conserver les journaux au moins 180 jours et de lever une alerte sur les rafales d’énumération, les lectures massives et les inscriptions automatisées. C’est à ça que ressemble un accès à la vitesse d’une machine.
Les étapes 1 à 3 sont les plus urgentes. Une seule clé exposée liée à un rôle cloud trop large, c’est le chemin le plus court entre un agent curieux et un incident à déclarer.
Avant de déployer vos agents, pas après
Bien des organisations planifient leur premier agent en production et le ménage de leur cloud comme deux projets séparés, menés par des équipes différentes, selon des échéanciers différents. L’avis plaide pour l’ordre inverse. Un agent qui a accès au réseau et à des outils fait de chaque erreur de configuration latente quelque chose qui va être trouvé, en quelques heures plutôt qu’en quelques années.
Si vous êtes sur le point de donner des identifiants à un agent, demandez-vous ce que ces identifiants permettent d’atteindre, et ce que l’agent pourrait atteindre avec tout ce qu’il va trouver en chemin. Si la réponse honnête est « on ne sait pas trop », le sprint d’hygiène passe en premier.
Besoin d’un deuxième regard ?
Notre évaluation de la sécurité de l’IA générative comprend la revue d’hygiène que les agents rendent urgente : secrets dans les dépôts et les pipelines, exposition des rôles cloud, trafic sortant et journalisation, avec des constats classés selon ce qu’un agent atteindrait en premier. Chaque constat a un responsable, un niveau de gravité et une correction planifiée avant la mise en production de votre agent.
Quatre questions à poser à votre équipe
- À quand remonte notre dernier scan de secrets sur tout l’historique des commits de chacun de nos dépôts, et pas seulement sur le code le plus récent ?
- Pour le dernier identifiant qu’on a remplacé après une exposition, est-ce que quelqu’un a vérifié de l’extérieur que l’ancienne valeur ne marchait plus ?
- Lesquels de nos jobs CI peuvent lire un token de déploiement de production, et est-ce qu’un d’eux fait rouler un agent IA ?
- Pourrait-on sortir aujourd’hui la liste de toutes les API qu’on expose sur Internet, avec un responsable pour chacune ?
Si deux de ces questions vous ont rendu mal à l’aise, l’agent digne d’un attaquant n’est pas votre premier problème. C’est votre propre arriéré.