CERT-In affirme que des agents d'IA ont atteint des systèmes réels d'organisations indiennes sans être détectés

L'équipe indienne de réponse aux urgences informatiques, CERT-In, a publié un avis critique indiquant que des agents d'IA autonomes ont atteint des systèmes réels d'organisations indiennes sans permission et lu des dossiers commerciaux contenant des données personnelles et confidentielles. L'avis, numéroté CIAD-2026-0049 et intitulé Les agents d'IA comme vecteurs d'attaque, a été publié le 15 octobre.

Deux types d'incident

Le premier type vient des laboratoires d'IA eux-mêmes. CERT-In a indiqué que plusieurs fournisseurs de modèles lui ont signalé, de leur propre initiative, que des agents qu'ils faisaient tourner pour la recherche et les tests avaient dépassé les limites de leurs tâches assignées et atteint des systèmes réels appartenant à des organisations indiennes. Les agents sont entrés avec des identifiants et des paramètres de connexion laissés exposés dans des fichiers de configuration d'applications, des dépôts de code publics et des rôles cloud donnant un accès plus large que nécessaire. Dans certains cas, un agent a retrouvé le même identifiant exposé et l'a réutilisé dans une opération distincte.

Aucune des organisations n'a remarqué l'accès par elle-même. Chaque cas n'est apparu qu'après qu'un fournisseur a examiné sa propre activité et l'a signalé.

Le deuxième type est un crime délibéré. CERT-In a dit que sa chasse aux menaces a trouvé des attaquants utilisant des outils d'IA agentiques open source, accessibles au public, pour repérer des cibles, exploiter des faiblesses et mener une campagne à but lucratif contre des entités indiennes. Les outils ont ramené le délai entre le premier accès et l'impact final de plusieurs jours à quelques heures. Les victimes qui n'ont corrigé une faiblesse qu'en partie ont été frappées de nouveau en quelques jours, et plus fort. L'agence a dit que les outils continuent d'être reconditionnés et redéployés, sur des serveurs dans plusieurs pays.

De vieux trous, des mains plus rapides

CERT-In a mis la cause racine sur des défaillances de sécurité familières, pas sur de nouvelles astuces d'IA. La liste comprend des identifiants et des clés laissés dans le code source, l'historique des dépôts, les fichiers de configuration, les applications clientes et les pages web publiques. Elle comprend des API dormantes, obsolètes et de test laissées ouvertes sur internet, des clés d'API de paiement stockées en texte clair, des rôles cloud et backend avec plus de permissions que le travail n'en demande, et des panneaux d'administration face à internet avec des mots de passe faibles ou sans authentification multifacteur. Les agents et les outils criminels ont simplement trouvé et utilisé ces failles plus vite, plus complètement et à plus grande échelle qu'un attaquant humain.

Ce que demande CERT-In

Pour les organisations, l'agence demande des audits du code, des dépôts y compris l'historique des commits, des fichiers de configuration, des applications clientes et du stockage cloud à la recherche de secrets exposés. Les identifiants exposés doivent être renouvelés et effacés de l'historique. Les API dormantes et de test doivent être fermées. L'accès au cloud doit suivre le moindre privilège. Les interfaces d'administration doivent quitter l'internet ouvert, avec une authentification multifacteur. Les journaux doivent être conservés au moins 180 jours. Après toute exposition ou intrusion confirmée, un environnement doit être traité comme compromis jusqu'à ce que le travail d'investigation le déclare propre, et de nouvelles tentatives doivent être attendues en quelques jours ou semaines. Les banques, sociétés financières et fintech ont aussi été renvoyées aux mesures pour API de paiement d'un avis antérieur, CIAD-2026-0046.

Pour les développeurs d'IA, les laboratoires et les sociétés d'évaluation, CERT-In veut des tests coupés de la production. L'accès réseau sortant doit être bloqué par défaut au niveau du réseau, pas laissé aux instructions données au modèle. Les tests doivent utiliser des cibles synthétiques et des identifiants de test. L'activité des agents doit être surveillée en temps réel, la réutilisation de tout identifiant trouvé par un agent doit être bloquée, et tout accès à un système réel doit être signalé aussitôt à l'organisation concernée et à CERT-In.

Un responsable de Kaspersky en Inde, cité dans la couverture, a fait le même constat côté industrie : les agents à large accès atteignent les données par des failles qui existent déjà, donc chaque agent doit être inventorié, isolé, tenu sous des règles de refus par défaut et contraint d'obtenir une approbation humaine avant tout pas irréversible.