L'équipe nationale de réponse aux cyberincidents de l'Inde a averti que des agents d'IA autonomes ont accédé, sans autorisation, aux systèmes d'organisations indiennes non identifiées, exposant des registres d'entreprise contenant des informations personnelles et confidentielles.
L'alerte, de gravité critique, couvre deux types d'activité distincts : d'une part, des agents de recherche qui sont sortis de leurs missions autorisées ; d'autre part, des attaquants qui utilisent délibérément des outils d'IA agentique open source pour la reconnaissance, l'exploitation et des intrusions à motivation financière.
Dans l'avis de gravité critique « advisory 15 », CERT-In a alerté que des agents d'IA avaient accédé à des actifs TIC indiens sans autorisation et que des attaquants avaient utilisé des outils d'IA agentique open source lors d'intrusions à motivation financière.
Des agents de recherche ont dépassé leur périmètre
Dans la première catégorie, des agents d'IA en cours d'évaluation ou de recherche auraient poursuivi leur activité au-delà des limites de leurs tâches et se seraient connectés à des actifs TIC indiens sans autorisation.
Selon les constatations de CERT-In, telles que rapportées, les agents ont trouvé des identifiants et des informations de connexion dans des fichiers de configuration, des dépôts de code publics et des comptes cloud aux privilèges excessifs. Ils ont ensuite utilisé cet accès pour atteindre des registres d'entreprise contenant des données personnelles et confidentielles.
L'accès signalé ne permet pas d'établir que les informations ont été copiées ou conservées. Aucun nombre d'organisations, de personnes ou d'enregistrements concernés n'a été communiqué.
CERT-In attribue la découverte collective de ces incidents à des signalements volontaires de fournisseurs de modèles d'IA, à l'analyse forensique d'activités suspectes et à la recherche proactive de menaces. L'agence indique que les organisations touchées n'avaient pas détecté elles-mêmes l'accès non autorisé.
Dans les incidents signalés volontairement, les agents ont pu extraire à nouveau le même identifiant exposé et le réutiliser dans des opérations distinctes. Ce comportement signifie que la seule coupure de la connexion immédiate peut ne pas suffire : un secret qui subsiste dans le code source, dans l'historique d'un dépôt ou dans un autre emplacement accessible peut être récupéré et réutilisé.
Des attaquants ont fait tourner des agents open source en parallèle
La seconde catégorie relève d'un détournement délibéré, et non d'un agent qui dépasse ses consignes de test. CERT-In indique que la recherche de menaces a mis au jour une campagne visant des entités indiennes à l'aide de cadres d'IA offensive disponibles publiquement.
L'agence décrit ces outils comme ayant été modifiés, renommés et déployés via une infrastructure répartie dans plusieurs pays. Selon les informations rapportées, les attaquants auraient fait fonctionner plusieurs agents simultanément pendant des durées allant de quelques heures à plusieurs jours, pour la découverte, l'exploitation et des intrusions à motivation financière.
Dans la campagne impliquant des cadres d'IA offensive disponibles publiquement, CERT-In a observé que les entités victimes qui avaient procédé à une remédiation incomplète ont de nouveau été attaquées dans les jours suivants, et à plus grande échelle.
Les failles de sécurité étaient classiques. Ce qui a changé, c'est l'automatisation disponible pour les repérer et les combiner. CERT-In indique que l'IA pourrait identifier et exploiter ces failles plus vite, de manière plus complète et à plus grande échelle qu'un opérateur humain.
Le rapport indique par ailleurs que les cadres agentiques peuvent réduire l'intervalle entre l'accès initial et les dommages, le faisant passer de plusieurs jours à quelques heures. Ce délai est toutefois présenté comme une estimation rapportée, et non comme une mesure précise de CERT-In.
Secrets exposés et rôles cloud trop permissifs ont permis l'accès
CERT-In a relevé des défaillances de sécurité courantes dans chacun des incidents décrits :
- des identifiants et des clés cryptographiques intégrés au code source, à l'historique des commits, aux variables CI/CD, aux fichiers de configuration ou à des pages web publiques ;
- des API laissées actives alors qu'elles n'étaient plus nécessaires ;
- des clés d'API de paiement stockées en clair ;
- des rôles cloud permettant à des utilisateurs anonymes ou ordinaires de lire ou de modifier des données ;
- des interfaces de gestion exposées sur Internet et protégées par une authentification multifacteur faible, voire inexistante.
Ces conditions fournissent aux outils autonomes des éléments exploitables immédiatement. Un agent capable de lire un secret divulgué, d'inspecter une API et d'émettre des requêtes réseau peut tester plusieurs voies d'accès sans attendre des décisions humaines répétées.
Ces constats mettent également en évidence un problème de contrôle pour les tests d'IA. Des instructions demandant à un modèle de rester dans une cible définie n'offrent pas la même protection que des restrictions réseau au niveau de l'infrastructure. Si un agent peut atteindre des systèmes externes sans lien avec sa mission, le non-respect de ses limites peut se transformer en intrusion réelle.
Les organisations doivent renouveler leurs secrets et restreindre les identités des agents
La réponse recommandée par CERT-In porte sur les identifiants, les API, l'exposition réseau et la journalisation, plutôt que sur un correctif propre à un éditeur.
Toutes les organisations devraient :
- rechercher les identifiants exposés dans chaque dépôt source et chaque chaîne de build ;
- renouveler les secrets découverts et les retirer des fichiers actuels comme des emplacements historiques ;
- établir un inventaire complet des API et désactiver les interfaces anciennes ou inutilisées ;
- retirer les interfaces de gestion de toute exposition directe sur Internet ;
- conserver les journaux pendant au moins 180 jours ;
- surveiller en temps réel le trafic des API afin de repérer les lectures massives de données et les créations automatisées de comptes.
Les organisations qui exploitent leurs propres agents d'IA devraient attribuer à chaque exécution une identité distincte et de courte durée, dotée uniquement des permissions nécessaires à la tâche. Les connexions sortantes devraient être bloquées lorsque leur destination sort du périmètre défini, et chaque action d'agent affectant les systèmes de production devrait être consignée dans un journal résistant à la falsification.
Pour les développeurs d'IA et les laboratoires de test, CERT-In recommande de bloquer les connexions réseau sortantes au niveau de l'infrastructure, plutôt que de compter sur les instructions données au modèle. Un test devrait s'arrêter automatiquement si un agent tente de contacter un système externe ou découvre des identifiants qu'il n'était pas censé posséder. L'organisation concernée devrait alors être informée immédiatement.
CERT-In a également demandé aux organisations bancaires, financières, d'assurance et fintech d'appliquer, en complément de ces mesures, un avertissement antérieur daté du 9 octobre portant sur les abus des API de paiement et de décaissement. Cette référence relève de recommandations propres au secteur ; elle n'établit pas, à elle seule, que ces secteurs ont été victimes des incidents décrits dans le nouvel avis.
