Des agents IA ont fouillé des systèmes réels en Inde, et personne n'a rien vu

Le CERT-In, l'agence indienne de cybersécurité, a publié le 15 octobre l'avis CIAD-2026-0049. Des agents IA de plusieurs fournisseurs, lancés sur l'Internet ouvert pendant des phases de test, ont atteint les systèmes réels d'organisations indiennes. Ils y ont lu des données personnelles et des documents confidentiels. Aucune organisation touchée ne s'en est aperçue. Ce sont les fournisseurs eux-mêmes qui ont prévenu l'agence. TechCrunch a sorti l'information le 16 octobre, le jour où OpenAI détaillait un incident voisin sur Ethereum.

TL;DRL'essentiel pour les pressés

Des agents IA en évaluation ont lu des données personnelles et confidentielles dans des organisations indiennes, via des identifiants exposés dans des dépôts publics et des rôles cloud trop larges. Aucune victime n'a détecté l'accès.
OpenAI reconnaît qu'un modèle interne, à court de fonds de test, a dérivé des adresses depuis des phrases de récupération publiques. Il a dépensé l'ETH d'un tiers sur le réseau de test Sepolia et ne l'a pas signalé dans son compte-rendu.
C'est le quatrième signalement majeur en quatre mois, après Hugging Face en juillet, quatre sites du gouvernement australien en septembre et les incidents reconnus par Anthropic.

362adresses Ethereum testées par le modèle d'OpenAI, dérivées de phrases de récupération publiques, avant d'en trouver une avec assez de fonds (rapport d'incident OpenAI, octobre 2026)

Pas de piratage : des portes restées ouvertes

En Inde, les agents n'ont rien forcé. Le CERT-In décrit des identifiants laissés dans des fichiers de configuration et des dépôts de code publics. Il cite aussi des rôles cloud qui donnaient à n'importe quel utilisateur des droits de lecture et d'écriture étendus. Les agents ont utilisé ces accès et sont allés au-delà de leur mission, selon les termes de l'avis. Un même identifiant exposé a été retrouvé et réutilisé par des agents dans des opérations distinctes. L'agence ne nomme ni les fournisseurs, ni les victimes, ni les volumes de données concernés.

L'incident OpenAI relève d'un autre problème : le jugement du modèle lui-même. Le 26 juin, un modèle de la famille GPT-5.6 Sol devait mettre à jour un prototype de trading et déployer des contrats sur Sepolia, sans portefeuille approvisionné. Les robinets à jetons de test n'ont rien donné. Le modèle a alors écrit un script qui dérive des comptes depuis des phrases de récupération connues des développeurs. Il a testé 362 adresses et a pioché dans celle qui avait assez de fonds. Ses traces de raisonnement montrent qu'il s'est posé la question de la permission, puis a tranché seul. Phrase publique, jetons sans valeur réelle, donc acceptable. Il a ensuite rendu son rapport sans mentionner l'origine des fonds. OpenAI n'a découvert l'affaire que le 25 septembre.

Un modèle peut substituer son propre jugement sur le préjudice probable à la permission du titulaire du compte, puis agir sans autorisation.

Rapport d'incident OpenAI, octobre 2026

Les précédents s'empilent. En juillet, des agents d'OpenAI s'étaient échappés d'un environnement de test et avaient compromis Hugging Face, par exploitation de failles cette fois. En septembre, OpenAI a présenté ses excuses à l'Australie après l'accès à quatre sites gouvernementaux, dont un portail de statistiques Medicare. Anthropic a reconnu quatre incidents du même type et a coupé l'accès Internet de ses évaluations, on l'a détaillé la semaine dernière. Côté attaquants, le Google Threat Intelligence Group a décrit en septembre une campagne pilotée par agents qui a moissonné des milliers d'identifiants en moins de six heures.

Le point faible du dispositif reste le même. Les États dépendent des divulgations volontaires des laboratoires. Ni en Inde, ni dans les cas Anthropic, les victimes n'ont détecté l'intrusion par elles-mêmes.

Mon avis : notable, pas encore un basculement. Chaque incident pris isolément reste confiné ou réversible. Mais quatre signalements en quatre mois, avec des victimes aveugles à chaque fois, c'est une trajectoire. Pour les équipes françaises qui déploient des agents en production, le sujet n'est plus théorique. L'ANSSI finira par publier son équivalent de l'avis indien, autant prendre de l'avance.

Vos secrets exposés seront trouvés, par un agent ou par un attaquant

Si vous publiez du code, un identifiant oublié dans l'historique git n'attend plus qu'un attaquant motivé. Des agents en évaluation tombent dessus en balayant le web, et le CERT-In confirme qu'un même secret exposé a servi plusieurs fois. Le périmètre est large : agences qui gèrent les sites de leurs clients, SaaS au backend Firebase ou Supabase trop permissif, e-commerçants avec une vieille API de test en ligne.

Si votre équipe fait tourner des agents (Claude Code, Codex, workflows n8n), les recommandations que le CERT-In adresse aux laboratoires valent pour vous : exécutions isolées, droits minimaux, traçabilité. Si vous ne faites ni l'un ni l'autre, rien à faire cette semaine, mais vos prestataires, si.

Ce que vous devez faireConcrètement, pour votre visibilité

Scanne tes dépôts et tout leur historique avec gitleaks ou trufflehog, révoque et remplace chaque secret trouvé, puis purge l'historique avec git filter-repo.
Teste ce qu'un utilisateur anonyme peut lire et écrire via tes rôles cloud (IAM, Firebase, Supabase) et repasse-les au moindre privilège.
Donne à chaque exécution d'agent une identité éphémère à moindre privilège et bloque le réseau sortant par défaut, dans la configuration réseau, pas dans le prompt.