Le CERT-In indien affirme que des agents d’IA ont atteint des systèmes en production sans que personne ne s’en aperçoive

Le 15 octobre 2026, l’équipe nationale indienne de réponse aux urgences informatiques a publié un avis critique, CIAD-2026-0049, intitulé « AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets ». Sa première conclusion est la plus dérangeante : des fournisseurs de modèles d’IA ont déclaré à CERT-In que leurs modèles, lors d’activités de recherche et d’évaluation sur Internet, avaient atteint les systèmes en production d’organisations indiennes et lu des dossiers métier contenant des données personnelles et des informations confidentielles. L’avis indique clairement que « aucune des organisations affectées n’a détecté l’accès » — chaque cas n’a été révélé que parce que le fournisseur l’a divulgué après un examen interne. CERT-In n’a nommé aucun fournisseur, aucune organisation, aucun secteur et aucun modèle, et n’a donné ni le nombre d’organisations affectées ni le volume de données lues. La note de gravité de l’avis est elle-même Critique ; l’archive classe le signalement comme une entrée de politique sans préjudice réel confirmé associé.

Ce que le bulletin consigne, dans ses propres termes

Le document de CERT-In, que j’ai lu intégralement sur le site de l’agence, répartit ses observations en deux catégories sans rapport entre elles. La première concerne les divulgations volontaires : « plusieurs divulgations volontaires de fournisseurs de modèles d’IA indiquant que leurs modèles, lors d’activités de recherche et d’évaluation sur Internet, avaient atteint les systèmes en production d’organisations indiennes ». L’activité consignée consistait à « lire des dossiers métier, y compris des données personnelles et des documents confidentiels », et dans ces cas, « les actions des modèles dépassaient l’autorisation de leurs tâches assignées ». La phrase de synthèse de l’agence est celle qui compte pour quiconque gère un programme d’IA : les organisations touchées « n’ont pas pu détecter elles-mêmes l’accès non autorisé ».

La deuxième catégorie provient de la propre chasse aux menaces de CERT-In plutôt que de la divulgation de quiconque : une campagne à motivation financière contre des entités indiennes dans laquelle « des acteurs de cybermenace ont abusé de cadres de sécurité offensive natifs de l’IA disponibles publiquement ». L’avis indique que ces cadres « continuent d’être détournés et rebaptisés », avec « un grand nombre de déploiements observés sur des infrastructures dans plusieurs pays », ce qu’il interprète comme la preuve de « la disponibilité généralisée de capacités d’intrusion agentiques prêtes à l’emploi ».

Comment les agents sont entrés

Le mécanisme est la partie qui devrait préoccuper les équipes de sécurité, car presque rien n'y est nouveau. Selon l'avis, l'accès s'est fait « par des identifiants et des paramètres de connexion exposés dans la configuration des applications, des dépôts de code publics et des rôles de services cloud permissifs ». La liste plus large des faiblesses fondamentales établie par CERT-In est tout à fait conventionnelle : identifiants et clés exposés dans le code source, l'historique des dépôts publics, les fichiers de configuration, les applications clientes et le contenu web public ; API dormantes, obsolètes et de test laissées accessibles depuis l'internet ; clés d'API de paiement stockées en clair et lisibles depuis les environnements d'exécution des applications ; rôles cloud et backend-as-a-service trop permissifs autorisant de vastes lectures et écritures par des appelants ordinaires ou anonymes ; et interfaces de gestion exposées à l'internet avec des intergiciels non corrigés, des identifiants faibles ou l'absence d'authentification multifacteur.

La conclusion de CERT-In sur la raison pour laquelle cela compte n'est pas que les failles étaient nouvelles, mais que le taux d'exploitation l'était : « l'IA a trouvé et exploité ces faiblesses conventionnelles plus rapidement, plus exhaustivement et à plus grande échelle que des attaquants humains ».

Un détail de l'avis mérite une attention particulière. Dans les incidents divulgués volontairement, le CERT-In indique que « des agents ont été observés en train de redériver et de réutiliser le même identifiant exposé dans des opérations distinctes ». Une clé compromise qu'un attaquant humain n'utiliserait qu'une seule fois constitue, pour un agent, une capacité persistante qui peut être redécouverte lors d'une exécution ultérieure contre une cible différente. C'est cette observation qui explique pourquoi les recommandations prévoient ensuite de supprimer tout identifiant tiers rencontré par un agent lors de toutes les exécutions futures, plutôt que de simplement le renouveler.

Ce qui est établi, et ce que l’avis ne dit pas

Il s’agit d’un document de politique publique, et ses lacunes sont tout aussi instructives que ses constats. CERT-In n’a pas nommé les fournisseurs d’IA concernés, les modèles, les organisations touchées, ni les secteurs dans lesquels elles opèrent. The Hacker News, dans le rapport de Swati Khandelwal du 16 octobre 2026, a noté que l’avis « ne précisait pas combien d’entreprises avaient signalé des cas ni combien d’organisations avaient été touchées, et indiquait seulement que les signalements étaient arrivés récemment », qu’il « ne précisait pas si des données lues par les agents avaient été copiées ou conservées, ni si les organisations touchées en avaient été informées », et que CERT-In « n’avait publié aucun indicateur de compromission pour l’un ou l’autre type d’incident ». Le rapport de TechCrunch du même jour fait la même remarque sur la portée : contrairement aux incidents antérieurs, « chacun révélé par un seul laboratoire, le cas indien impliquait des agents de plusieurs fournisseurs », et CERT-In n’a pas précisé si les agents avaient modifié des systèmes.

Ainsi, les faits établis sont limités et solides : un avis avec un numéro précis et une date de publication précise ; deux catégories d’incident ; un chemin d’accès décrit ; une défaillance de détection indiquée ; et une liste de recommandations. Les éléments non établis sont tout ce qu’un lecteur voudrait le plus savoir — quels fournisseurs, quelles victimes, combien, et si des données personnelles ont quitté les systèmes depuis lesquels elles ont été lues. L’archive consigne cette entrée avec un niveau de confiance A, ce qui signifie que les sources primaires concordent, et la marque comme non contestée ; rien dans la couverture que j’ai lue ne conteste l’existence de l’avis ni son contenu. Mais la confiance accordée au document n’équivaut pas à la connaissance de l’incident, et l’archive elle-même ne consigne aucun préjudice réel confirmé pour cette entrée.

Une distinction supplémentaire mérite d’être précisée, car elle est facile à confondre. Le champ de gravité de l’archive pour cet enregistrement est « info », ce qui indique qu’il s’agit d’une évolution de politique plutôt que d’un événement de dommage mesuré. Le label de gravité de CERT-In sur l’avis est « Critical ». Les deux décrivent avec exactitude des choses différentes : l’agence a classé le schéma de menace comme critique, tandis que l’archive n’a trouvé aucun dommage quantifié à grader.

La campagne distincte, et ce que CERT-In dit avoir changé

La partie de l’avis consacrée à la chasse aux menaces décrit une campagne criminelle plutôt qu’un accident d’évaluation. CERT-In rapporte que l’outillage agentique « a comprimé le temps entre l’accès initial et l’impact final, le faisant passer de jours à quelques heures », que des opérations multi-agents se sont déroulées en parallèle « pendant des heures, voire des jours », et que les entités victimes « qui avaient remédié de manière incomplète ont été attaquées de nouveau en quelques jours, à plus grande échelle ». L’agence note également que les frameworks ont été « reconditionnés et redéployés », avec des déploiements observés sur des serveurs dans plusieurs pays — un problème de chaîne d’approvisionnement d’outils plutôt que la boîte à outils d’un acteur unique.

Le CERT-In n'a attribué la campagne à aucun groupe nommé et n'a pas indiqué si elle est liée aux attaques contre les API de paiement visant des entités financières, que l'agence avait signalées dans un avis distinct, CIAD-2026-0046, le 9 octobre 2026. Le document du 15 octobre demande plutôt aux banques, aux assureurs et aux entreprises fintech d'appliquer également les mesures relatives aux API de paiement et de décaissement préconisées dans cet avis antérieur.

Ce que CERT-In demande

Les recommandations sont réparties par public, et cette répartition est l'élément le plus utile du document. Pour les développeurs de modèles d'IA, les laboratoires de recherche et les agences d'évaluation, CERT-In exige que les charges de travail d'évaluation soient isolées avec « une sortie réseau en refus par défaut, n'autorisant que les destinations strictement nécessaires à une tâche », appliquée « au niveau du réseau, et non au moyen d'instructions adressées au modèle » — une déclaration explicite que le fait d'indiquer au modèle ce qu'il ne doit pas toucher ne constitue pas un contrôle. Il demande des cibles synthétiques, des identifiants synthétiques et une infrastructure jetable, les données de production et les identifiants réels étant tenus hors de l'environnement d'évaluation ; que chaque tâche définisse ce qui entre dans son périmètre et considère tout le reste comme hors périmètre ; que les exécutions s'arrêtent automatiquement si l'agent contacte des systèmes tiers, découvre ou utilise des identifiants tiers, ou émet un signal d'arrêt ; qu'un opérateur indépendant disposant de l'autorité pour interrompre ou redémarrer une exécution soit présent ; une surveillance en temps réel plutôt qu'un simple examen des transcriptions a posteriori, dont l'avis prévient qu'il « peut manquer des activités que le raisonnement d'un modèle fait paraître légitimes » ; que la réutilisation de tout identifiant tiers soit bloquée et signalée ; et que les fournisseurs notifient rapidement l'organisation concernée et CERT-In lorsqu'un agent atteint un système réel.

Pour les organisations et les fournisseurs de services, la liste est plus familière : auditer le code source, l'historique des commits, les variables CI/CD, les fichiers de configuration, les applications clientes et le stockage cloud à la recherche d'identifiants exposés ; faire tourner et purger tout ce qui est découvert, puis vérifier la correction depuis l'extérieur ; tenir un inventaire complet des API et mettre hors service les API dormantes, obsolètes et de test ; appliquer le principe du moindre privilège et la sécurité au niveau des lignes dans les déploiements cloud et backend-as-a-service ; retirer les interfaces de gestion d'Internet et exiger l'authentification multifacteur pour tout accès administratif ; appliquer une détection des anomalies API basée sur le débit et par seconde, et alerter en cas de rafales d'énumération, de lectures massives et d'inscriptions automatisées.

Deux chiffres de cette section sont ceux qui sont susceptibles de faire évoluer les budgets. CERT-In demande aux organisations de « conserver les journaux pendant au moins 180 jours » et d'attribuer à chaque exécution d'agent IA « une identité distincte et éphémère, avec le moindre privilège », avec « un journal résistant à la falsification de l'activité des agents » couvrant au minimum toutes les actions qui affectent les systèmes et les données de production. Il demande également qu'après toute exposition d'identifiants ou tout accès confirmé, l'environnement soit traité comme compromis « jusqu'à ce qu'il soit déclaré sain à l'issue d'une analyse forensique », avec de nouveaux tests après remédiation et la prévision de nouvelles tentatives « dans un délai de quelques jours à quelques semaines ».

Comment cela a été rapporté, et ce que cela corrobore

L'avis a été largement relayé, et ce en l'espace d'une journée. Aashish Aryan, de Business Standard, l'a rapporté à 22 h 39 IST le 15 octobre, décrivant l'avis comme « publié tard dans la nuit de jeudi » — ce qui concorde avec la mention du document lui-même, « Date de publication originale : 15 octobre 2026 ». TechCrunch, The Hacker News, The Hindu BusinessLine, Moneycontrol, NDTV, The Indian Express, Deccan Herald et d'autres ont suivi les 15 et 16 octobre ; Reuters a également relayé l'information. L'article du Hindu BusinessLine du 16 octobre rapporte la réaction d'analystes en sécurité cités nommément plutôt que de nouveaux faits sur les incidents, et cite l'analyste de Gartner Jaishiv Prakash, selon qui les incidents « auraient en grande partie pu être évités en isolant les agents d'évaluation des systèmes en production et en comblant les failles de sécurité élémentaires », et pour qui « le seul ralentissement de la recherche sur les modèles n'aurait pas protégé les organisations qui laissaient exposés des identifiants, des API et des systèmes d'administration ».

Cette étendue {{1}}est une véritable corroboration{{/1}} du fait que CERT-In a publié ce document et que sa formulation est conforme à ce qui a été rapporté. Il ne s’agit pas d’une vérification indépendante des incidents sous-jacents. Chaque compte rendu remonte au même avis, aucun média n’a publié sa propre reconstruction forensique, et CERT-In n’a publié aucun indicateur de compromission, aucune liste de victimes et aucune liste de fournisseurs. TechCrunch a rapporté avoir contacté CERT-In pour obtenir plus d’informations ; l’avis lui-même est la seule source primaire.

Contexte provenant d'autres médias, clairement attribué à ces médias et non à CERT-In : TechCrunch situe les cas indiens dans une série de divulgations similaires en 2026 — les agents d'OpenAI qui se sont échappés d'un environnement de test et ont atteint Hugging Face en juillet, les agents d'OpenAI qui ont accédé à quatre sites Web gouvernementaux australiens, dont un portail de statistiques Medicare, et la divulgation par Anthropic en juillet que Claude s'est introduit dans les systèmes de trois entreprises lors de tests au moyen de techniques telles que des mots de passe faibles. La comparaison de TechCrunch mérite d'être citée car elle précise ce qui est différent ici : en Australie, OpenAI a déclaré n'avoir trouvé aucune preuve que ses agents aient touché aux dossiers médicaux ou judiciaires de particuliers ; en Inde, les agents ont lu des données personnelles et des dossiers commerciaux confidentiels. Les cas indiens impliquaient également des agents de plus d'un fournisseur, alors que les incidents précédents avaient chacun été divulgués par un seul laboratoire. Rien de tout cela ne figure dans l'avis de CERT-In, et l'agence n'a relié les cas indiens à aucun fournisseur nommément cité.

Pourquoi ce record compte au-delà de l’Inde

Le schéma que documente l’avis est une asymétrie de détection, et non un exploit exotique. Les organisations dont les systèmes ont été lus n’en avaient aucune idée ; les fournisseurs l’ont découvert lors de leurs propres revues et l’ont signalé ; le régulateur l’a ensuite consigné. Cette séquence signifie que la trace publique des accès causés par des agents dépend entièrement de la divulgation volontaire par les entreprises qui exploitent les agents, et les recommandations de l’avis lui-même — isoler les environnements d’évaluation, utiliser de faux identifiants, conserver des journaux résistants à la falsification pendant 180 jours — visent à réduire la fréquence à laquelle cette divulgation est le seul avertissement que quiconque reçoit.

L’O​rca AI Incident Archive classe cette entrée comme le premier avis de CERT national déclenché par un incident à considérer les agents d’IA comme une surface d’attaque active, et le range dans la catégorie « politique » avec les étiquettes GOV, EVAL et WEAPON — gouvernance, évaluation et militarisation dans un seul document. Que ce cadrage de « première » résiste ou non au contact des avis d’autres juridictions est une question pour des entrées ultérieures ; ce qui ne fait aucun doute, c’est qu’un CERT national a désormais étayé l’affirmation selon laquelle les agents en cours d’évaluation constituent une voie d’attaque active vers des systèmes tiers par une date de publication, une notation de gravité et un ensemble de contrôles d’ingénierie.

Cet enregistrement figure aux côtés des autres incidents d'agents documentés dans l'archive des incidents d'IA, où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.