Des agents IA ont compromis tout un réseau en moins de dix heures, sans la moindre faille zero-day

Le 2 septembre 2026, Unit 42 de Palo Alto Networks a publié les détails d'une enquête sur l'intrusion dans le réseau d'une entreprise. Le chiffre qui a porté le rapport : l'attaquant est parti d'un service web accessible publiquement et a terminé avec un accès de niveau root sur l'ensemble de l'environnement en moins de dix heures, un travail qui prend environ deux semaines à une équipe humaine.

Le détail le plus important, c'est ce qui n'a pas été utilisé. Pas de zero-day. Pas de savoir-faire rare. L'intrusion a employé plus de 50 techniques déjà répertoriées dans le référentiel MITRE ATT&CK, c'est-à-dire des techniques documentées et publiées que les défenseurs connaissent. Ce qui a changé, ce n'est pas la méthode mais le rythme. Au lieu d'exécuter chaque étape à la main, l'opérateur a dirigé des agents IA qui surveillaient, évaluaient, agissaient et replanifiaient dans une boucle unique et ininterrompue, sans jamais faire de pause ni dormir.

Ce qui s'est passé pendant ces dix heures

La séquence telle que le rapport la décrit :

1. L'entrée. Un service web accessible publiquement a été compromis, puis un tunnel a été ouvert vers le réseau interne.
2. La reconnaissance. Un agent automatisé a cartographié les microservices internes sans aucune intervention humaine.
3. La collecte des secrets. Des sous-agents ont passé au peigne fin les dépôts de code à la recherche de jetons d'accès et de mots de passe de services écrits directement dans le code.
4. L'élévation de privilèges. Ces jetons ont ouvert le système de gestion des secrets, qui a livré des identifiants d'administration principaux donnant un accès root sur tout l'environnement.
5. Les pipelines. Les pipelines de build et de déploiement ont été détournés au moyen de workflows personnalisés pour exfiltrer des clés d'accès au cloud.
6. Le retournement. Ces clés ont servi à transformer les propres points d'accès IA de la victime en infrastructure post-compromission au service de l'attaquant.

Relisez cette dernière étape. L'abonnement IA de l'entreprise elle-même est devenu un outil entre les mains de l'intrus, fonctionnant sur son compte et sur sa facture. C'est un nouveau schéma qui mérite d'être ajouté à votre registre des risques : chaque clé d'API d'un modèle d'IA est à la fois un actif opérationnel et une ligne de dépenses.

Le chiffre qui vous concerne n'est pas dix heures

Dix heures, c'est un chiffre frappant, mais il provient d'un seul incident. Le chiffre qui devrait réellement changer votre planification figure dans le CrowdStrike 2026 Global Threat Report, qui mesure le « breakout time » : l'écart entre le premier accès d'un attaquant et le moment où il commence à se déplacer vers d'autres systèmes à l'intérieur du réseau.

• Le temps moyen de propagation de la cybercriminalité est tombé à 29 minutes, soit une vitesse en hausse de 65 % sur un an.
• Le cas le plus rapide jamais enregistré : 27 secondes.
• Une hausse de 89 % des attaques attribuées à des adversaires dotés d'IA.
• 82 % des détections en 2025 étaient sans logiciel malveillant : l'attaquant se connecte avec des identifiants valides au lieu de déposer un virus.
• Une hausse de 266 % des intrusions ciblant le cloud menées par des acteurs liés à des États.

Ce que 29 minutes signifient concrètement : un plan de réponse qui suppose que quelqu'un remarque l'alerte le matin et que l'équipe se réunit après le déjeuner est un plan pour une époque révolue. Et le chiffre de 82 % dit quelque chose de plus dur encore. Votre antivirus ne voit pas l'attaque, parce que l'attaque ne transporte rien qu'il puisse voir. Une intrusion moderne, ce n'est pas un fichier malveillant qui arrive, c'est un compte légitime utilisé à mauvais escient.

Pourquoi cela a fonctionné : des secrets écrits dans le code

Les agents n'ont cassé aucun chiffrement et n'ont inventé aucune vulnérabilité. Ils ont trouvé des mots de passe écrits là où des mots de passe ne devraient jamais se trouver, dans les fichiers du projet. Un seul jeton valide a ouvert le gestionnaire de secrets, et le gestionnaire de secrets a tout ouvert.

Ce n'est pas un problème réservé aux grandes entreprises. Passez cette liste en revue sur vos propres projets :

• Des clés de passerelle de paiement ou de service de messagerie dans un fichier de configuration enregistré avec le code.
• Un mot de passe de base de données dans un vieux script de déploiement que personne n'ouvre.
• Des jetons d'accès d'un employé ou d'un développeur externe parti il y a un an, toujours valides.
• Un dépôt qui était privé et est devenu public après une migration ou un changement de compte.
• Une copie de sauvegarde d'un fichier de configuration sur l'ordinateur portable de quelqu'un.

La différence entre un agent et un attaquant humain ne tient pas ici à l'intelligence, mais à la patience et au débit. L'agent lit tout le dépôt, chaque branche et chaque ancienne version de l'historique, ne manque aucun fichier et termine en quelques minutes. Tout secret que vous avez enregistré une fois puis supprimé plus tard vit toujours dans l'historique du dépôt, et c'est précisément là qu'il cherche.

Ce qu'il faut faire cette semaine

Cinq étapes. La première ne demande ni budget ni prestataire externe :

1. Analysez vos dépôts à la recherche de secrets. Des outils de détection de secrets existent et sont intégrés aux principales plateformes de code. Lancez-les sur tout l'historique, pas seulement sur la version actuelle.
2. Faites du renouvellement des clés une routine, pas une mesure d'urgence. Une clé qui n'a pas changé depuis deux ans est une clé divulguée que vous n'avez pas encore découverte. Et lorsque vous la renouvelez après une fuite, renouvelez-la partout où elle était utilisée, pas à un seul endroit.
3. Préparez une procédure de révocation unique. C'est la recommandation directe d'Unit 42 : être capable d'exécuter un confinement synchronisé qui révoque ensemble les identifiants, les sessions OAuth, les pipelines CI/CD et les comptes cloud. Révoquez-en seulement la moitié, et vous donnez à l'attaquant le temps de revenir par l'autre moitié.
4. Gouvernez l'IA comme une infrastructure essentielle. Tenez un inventaire de chaque modèle et de chaque clé utilisés, fixez des limites de débit, appliquez le principe du moindre privilège et activez la journalisation de diagnostic. Le rapport le recommande explicitement, et c'est ce qui transforme l'incident ci-dessus d'une catastrophe silencieuse en alerte précoce.
5. Exigez une revue de code à plusieurs et la protection des branches. En particulier sur les dépôts d'infrastructure as code, car c'est la porte par laquelle une modification d'une seule ligne installe une porte dérobée. En parallèle, surveillez les comportements plutôt que les signatures : des rafales de requêtes API et des changements d'état rapides sont l'empreinte d'un agent automatisé.

Dans le contexte saoudien, ces étapes ne sont pas de simples bonnes pratiques facultatives. Les contrôles essentiels de cybersécurité de l'Autorité nationale de cybersécurité (NCA) comprennent des domaines explicites pour la gestion des identités et des accès et pour la sécurité des changements et du développement, et la responsabilité de la protection des données personnelles incombe à l'organisation en vertu de la loi sur la protection des données personnelles (PDPL). Une intrusion partie d'une clé écrite dans le code source ne réduit en rien cette responsabilité.

Le regard d'Origami

Nous lisons cet incident comme la fin d'une idée : celle selon laquelle la sécurité est un ensemble d'outils que l'on achète. L'attaquant n'a jamais eu à affronter un pare-feu ni à contourner un antivirus, parce qu'aucun des deux ne se trouvait sur son chemin. Il est entré avec une clé valide qu'il a trouvée écrite quelque part, et a agi avec des autorisations qui avaient réellement été accordées. Aucun produit que vous achetez ne règle cela. Ce qui le règle, c'est la discipline dans la manière d'écrire le code, de stocker les secrets, et d'accorder et de retirer les autorisations.

Un schéma que nous voyons régulièrement chez nos clients : les secrets les plus dangereux se trouvent rarement dans le système principal. Ils sont dans les projets annexes : un script de migration de données écrit une fois, un tableau de bord interne de reporting construit par un prestataire, une intégration fournisseur temporaire qui tourne depuis deux ans. Ceux-ci n'entrent jamais dans une revue de sécurité, parce que personne ne les considère comme un système. L'attaquant, lui, ne fait pas cette distinction. Lorsque nous examinons l'environnement d'un client, nous commençons précisément ici : où sont les clés, qui détient quelle autorisation, et que se passe-t-il si une clé fuit ce soir. Si vous souhaitez une revue sous cet angle, vous nous trouverez sur la page de contact.

Conclusion

La méthode d'attaque n'a pas changé. Sa vitesse, si. Plus de 50 techniques connues ont été exécutées en moins de dix heures parce que des agents automatisés les ont enchaînées sans pause, et le temps moyen de propagation à l'intérieur du réseau est désormais de 29 minutes. Une défense qui dépend de quelqu'un qui remarque à temps ne suffit plus. Commencez par la question la plus simple et la plus difficile : savez-vous où se trouvent vos clés en ce moment, et qui peut les lire ?

Sources

• Unit 42 — An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation, Palo Alto Networks, 2 septembre 2026 : durée de l'intrusion, chaîne d'attaque, nombre de techniques MITRE ATT&CK et recommandations défensives.
• CrowdStrike 2026 Global Threat Report : temps de propagation de 29 minutes et record de 27 secondes, hausse de 89 % des attaques d'adversaires dotés d'IA, et chiffre de 82 % de détections sans logiciel malveillant.
• Check Point AI Security Report 2026 : l'IA passe du rôle d'assistant à celui d'opérateur dans des intrusions réelles.
• Autorité nationale de cybersécurité (NCA) — contrôles essentiels de cybersécurité, et Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) — loi sur la protection des données personnelles.