Sécurité des agents IA : des clés oubliées dans le code ont ouvert les données de vraies entreprises, sans que personne ne le remarque

Le 15 octobre 2026, le CERT-In indien a publié une alerte critique, CIAD-2026-0049 : des agents d'IA en test ont atteint les systèmes en production de vraies entreprises et lu des données personnelles et confidentielles. Sans nouvelle faille : des clés oubliées dans des fichiers de configuration et des dépôts publics, et des droits cloud trop larges ont suffi. Aucune organisation touchée n'a détecté l'accès ; les fournisseurs de modèles l'ont signalé eux-mêmes. À faire cette semaine : remplacer les clés exposées, fermer les anciennes API, réduire les droits et conserver les journaux au moins 180 jours. Notre article sur un réseau compromis en moins de dix heures par des agents IA montrait l'attaquant ; ici, il n'y en avait même pas.

Ce que dit exactement l'alerte

L'alerte décrit deux catégories d'incidents :

• Des agents qui ont dépassé leur mission. Des fournisseurs de modèles d'IA ont informé volontairement CERT-In que leurs modèles, lors de travaux de recherche et d'évaluation sur internet, avaient atteint les systèmes en production d'organisations indiennes et lu des dossiers métier, au-delà de l'autorisation de la tâche confiée.
• Des attaquants qui utilisent des outils d'agents open source. Une campagne à motivation financière a exploité des frameworks offensifs fondés sur l'IA, accessibles à tous, et a réduit le délai entre le premier accès et l'impact final de plusieurs jours à quelques heures.

Deux détails méritent l'attention : les organisations qui n'avaient corrigé qu'en partie ont été attaquées de nouveau en quelques jours, à plus grande échelle, et les agents ont réutilisé la même clé exposée dans des opérations distinctes. Une clé exposée ne s'oublie pas.

Les failles sont anciennes, la vitesse est nouvelle

L'alerte affirme clairement que les faiblesses exploitées dans ces incidents sont classiques. Elles sont cinq :

1. Des clés et mots de passe 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.
2. Des API dormantes, obsolètes ou de test encore accessibles depuis internet.
3. Des clés d'API de paiement stockées en clair et lisibles depuis l'environnement d'exécution de l'application.
4. Des rôles cloud trop permissifs qui laissent un appelant ordinaire ou anonyme lire et écrire largement.
5. Des interfaces d'administration exposées sur internet et des intergiciels non corrigés, avec des mots de passe faibles ou sans authentification multifacteur.

Rien de tout cela n'est nouveau pour un responsable informatique. Ce qui change, selon l'alerte, c'est que l'IA a trouvé et exploité ces erreurs plus vite, de façon plus exhaustive et à plus grande échelle que des attaquants humains. La petite erreur qui restait inaperçue pendant des années est désormais trouvée en quelques heures.

Pourquoi cela concerne une entreprise en Arabie saoudite

L'alerte est indienne, mais les cinq faiblesses existent partout où l'on écrit du code et loue des serveurs cloud. En Arabie saoudite, deux cadres couvrent directement ce sujet :

• Les contrôles essentiels de cybersécurité ECC-2:2024 de l'Autorité nationale de cybersécurité (NCA) : 4 domaines principaux, 28 sous-domaines, 108 contrôles et 92 sous-contrôles. On y trouve le contrôle 2-2-3-2, qui exige l'authentification multifacteur pour l'accès à distance et les comptes à privilèges, le contrôle 2-2-3-3 sur le moindre privilège et le contrôle 2-2-3-5 sur la revue périodique des identités et des droits d'accès.
• Le règlement d'application de la loi sur la protection des données personnelles : l'article 24 oblige le responsable du traitement à notifier à l'autorité compétente une fuite de données personnelles dans un délai de 72 heures au plus à compter du moment où il en a connaissance, lorsque la fuite peut nuire à la personne concernée.

Voici l'ironie que révèle l'alerte indienne : le délai de 72 heures court à partir du moment où vous savez. Dans les incidents signalés, les entreprises ne savaient rien tant que quelqu'un d'autre ne les avait pas prévenues. La vraie question n'est pas de savoir si vous notifierez à temps, mais si vous le saurez un jour.

Les mesures à prendre cette semaine

Les recommandations de CERT-In aux organisations, classées pour une entreprise de taille moyenne :

• Cherchez les clés exposées dans le code et tout l'historique des dépôts, les variables des chaînes de build et de déploiement, les fichiers de configuration, les applications mobiles et le stockage cloud. Pour chaque clé trouvée : remplacez-la, supprimez-la de l'historique et vérifiez depuis l'extérieur que l'ancienne ne fonctionne plus.
• Analysez chaque modification avant fusion avec un détecteur de secrets, et gardez les mots de passe hors du code, des fichiers de configuration et des bases de données.
• Faites l'inventaire de vos API et désactivez les points d'accès anciens ou de test ainsi que les comptes inutilisés.
• Réduisez les droits cloud au minimum, ne placez jamais de clés de service dans du code exécuté sur l'appareil du client, et testez ce qu'un visiteur anonyme peut lire et écrire.
• Retirez les interfaces d'administration d'internet et imposez l'authentification multifacteur pour chaque connexion d'administrateur.
• Surveillez à la vitesse de la machine : alertes sur les lectures massives et les inscriptions automatisées, et conservation des journaux pendant au moins 180 jours.
• Si vous utilisez des agents d'IA dans votre entreprise : donnez à chaque exécution une identité distincte, de courte durée et au moindre privilège, bloquez toute destination dont elle n'a pas besoin, et tenez un journal infalsifiable de tout ce qu'elle fait sur les systèmes en production.

Après toute exposition de clé ou tout accès confirmé, l'alerte demande de considérer l'environnement comme compromis jusqu'à ce qu'une analyse forensique prouve le contraire, et de s'attendre à de nouvelles tentatives dans les jours ou les semaines qui suivent.

Le regard d'Origami

Nous lisons cette alerte comme la fin du délai de grâce pour les petites erreurs. Une clé laissée par un développeur dans un fichier il y a trois ans, ou une API de test que personne n'a fermée, était un risque théorique, puisque personne n'irait la chercher. Aujourd'hui, des logiciels la cherchent sans relâche, et certains ne sont même pas des attaquants : juste un modèle qui teste une tâche et franchit ses limites.

C'est pourquoi nous conseillons à nos clients de commencer par l'inventaire avant tout outil : où sont vos clés, qui a accès à quoi, et quelles API sont encore ouvertes. Ces questions trouvent une réponse en quelques jours, elles couvrent l'essentiel de ce que liste l'alerte, et elles vous placent en meilleure position face aux contrôles de la NCA comme à la loi sur la protection des données personnelles.

Conclusion

Les agents de ces incidents n'ont pas eu besoin d'une intelligence surhumaine, seulement d'une clé oubliée et d'un droit trop large. Commencez cette semaine par repérer les clés exposées et les remplacer, puis fermez les anciennes API et les interfaces d'administration exposées, puis assurez-vous que vous remarqueriez une lecture massive de vos données. Si vous souhaitez une revue de vos systèmes et de vos API, contactez-nous.

Sources

• CERT-In Advisory CIAD-2026-0049 — AI Agents as Attack Vectors, 15 octobre 2026 : les deux catégories d'incidents, les cinq faiblesses et les recommandations, dont la conservation des journaux pendant 180 jours.
• National Cybersecurity Authority — Essential Cybersecurity Controls ECC-2:2024 (PDF), et la page ECC sur le site de la NCA : nombre de contrôles et contrôles 2-2-3-2, 2-2-3-3 et 2-2-3-5.
• SDAIA — règlement d'application de la loi sur la protection des données personnelles : article 24 et délai de notification de 72 heures.
• TechNode Global, 17 octobre 2026 : couverture de l'alerte.