Le signal le plus clair de la semaine écoulée n’est pas que l’IA devient plus intelligente. C’est que nos assistants deviennent la nouvelle surface d’attaque. Dit ainsi, cela paraît presque évident. Pourtant, une grande partie de la couverture actuelle en sécurité continue de traiter les incidents liés à l’IA comme des curiosités isolées : une prompt injection ici, un cas de détournement de modèle là, ou une démo qui fait peur mais déconnectée des opérations quotidiennes. L’enseignement le plus important est d’ordre opérationnel. Les attaquants ne ciblent plus seulement des utilisateurs ou des serveurs. Ils ciblent désormais les systèmes auxquels nous faisons de plus en plus confiance pour naviguer à notre place, exécuter des tâches, gérer des workflows et prendre des décisions rapides en notre nom. C’est essentiel pour la défense de l’IA, car le point faible n’est plus seulement le modèle. C’est la couche qui l’entoure : l’agent navigateur avec accès local, le moteur de workflow qui détient des identifiants, la dépendance logicielle qui ouvre discrètement une porte vers l’infrastructure cloud, et la pile d’automatisation du SOC capable de transformer une compromission en cascade. En pratique, ce nouveau risque a deux faces : l’agent comme cible, et l’agent comme vecteur. Les attaquants peuvent orienter des systèmes d’IA qui agissent en notre nom, mais aussi utiliser l’IA pour accélérer l’exploitation des environnements que nous défendons.

1) Les systèmes agentiques réduisent la distance entre prompt injection et impact réel

L’exemple le plus parlant vient de l’accumulation continue de problèmes autour du navigateur Comet de Perplexity. Les travaux “PleaseFix” de Zenity Labs, ainsi que les analyses qui ont suivi, ont montré comment un navigateur agentique pouvait être manipulé via des entrées ordinaires, comme du contenu de calendrier ou des prompts web, puis poussé vers des actions sensibles telles que l’accès à des fichiers ou l’abus d’identifiants. La démonstration de phishing publiée ensuite rend le problème encore plus concret : les chercheurs auraient réussi à faire exécuter un flux de phishing par Comet en moins de quatre minutes.

• Détournement de Comet par Zenity
• Analyse du phishing via Comet

Le changement de perspective essentiel pour les défenseurs est le suivant : le prompt injection n’est plus seulement un problème d’intégrité du contenu. Dans des environnements agentiques, elle devient un problème d’intégrité de l’exécution. Dès qu’un système peut lire des fichiers locaux, interagir avec un gestionnaire de mots de passe, naviguer dans des sessions authentifiées ou agir dans des applications SaaS, l’ancien cadrage du type « le modèle a dit quelque chose d’étrange » perd toute utilité. La question centrale devient : une entrée non fiable peut-elle orienter un workflow privilégié vers une action ? Pour les équipes SOC, cela signifie que les détections et les contrôles doivent se rapprocher de la frontière d’action :

• journaliser et examiner les actions agentiques à haut risque, pas seulement les transcriptions de chat
• isoler par défaut l’accès aux fichiers locaux, les capacités du navigateur et les permissions sur les coffres d’identifiants
• exiger une approbation explicite pour les transitions sensibles comme la connexion, le paiement, l’envoi de messages, l’accès à un coffre ou l’exécution de scripts
• traiter les sources indirectes de prompt (e.g. invitations calendrier, documents, emails, pages web) comme hostiles jusqu’à preuve du contraire

La leçon est simple : si une IA peut opérer votre environnement, alors l’ingénierie sociale de cette IA devient un vecteur d’intrusion concret.

2) Les plateformes d’automatisation deviennent des infrastructures critiques

Le deuxième grand thème de la semaine est la compromission des plateformes d’automatisation. La CISA a ajouté une faille RCE n8n activement exploitée à la KEV, tandis que plusieurs analyses indiquaient que des dizaines de milliers d’instances restaient exposées.

• Couverture KEV sur n8n
• Autres failles n8n

Ce sujet mérite plus d’attention qu’il n’en recevra probablement en dehors des cercles de défense. n8n n’est pas simplement une application exposée sur Internet. Dans de nombreuses organisations, c’est la couche d’orchestration qui relie la réponse à incident, les workflows DevOps, les opérations cloud, le triage d’alertes et les flux de données internes. Autrement dit, c’est exactement le type de plateforme qui accumule des jetons API, de la confiance webhook et des permissions étendues. Cela la rend structurellement comparable au SOC moderne : centrale, fortement connectée et digne de confiance pour tout ce qui l’entoure. Le danger ne se limite pas à l’accès initial. Il s’agit d’une compromission du plan de contrôle. Si un attaquant accède à la couche d’automatisation, il peut hériter :

• d’identifiants couvrant des plateformes SaaS, des environnements cloud et des systèmes de ticketing
• de la capacité à déclencher ou à bloquer des workflows
• d’un accès au contexte d’enrichissement des alertes et d’investigation
• d’un chemin direct pour altérer la logique de réponse avant qu’un humain ne s’en aperçoive

Pour les blue teams, cela devrait faire remonter le durcissement de l’automatisation bien plus haut dans la liste des priorités. Nous parlons beaucoup de défense autonome ; beaucoup moins du fait que l’orchestrateur lui-même est peut-être devenu le point le plus facile à compromettre. Une base de sécurité raisonnable ressemble désormais à ceci :

• aucune exposition publique sauf nécessité absolue
• MFA administrateur fort et, lorsque possible, authentification résistante au phishing
• cloisonnement des identifiants par workflow plutôt qu’un grand pool partagé
• traces d’audit immuables pour les modifications de workflow et l’historique d’exécution
• séparation entre tâches d’enrichissement et tâches d’exécution
• détections sur les créations, modifications, rejouements de workflow ou exportations d’identifiants inhabituels

3) La chaîne d’approvisionnement logicielle n’est plus seulement un problème de développeurs

Le troisième axe de la semaine relie outillage IA, confiance open source et compromission cloud. D’abord, des analyses ont mis en lumière un paquet npm malveillant se faisant passer pour un installateur OpenClaw, visant à compromettre des postes de développeurs.

• Faux paquet installateur OpenClaw

Ensuite est venue l’histoire la plus stratégique : UNC6426 aurait utilisé des clés volées lors de l’« incident de supply chain npm de nx » pour obtenir un accès administrateur AWS en moins de 72 heures.

• Pivot de nx vers AWS

En parallèle, des chercheurs ont signalé des crates Rust malveillantes associées à un bot IA pour exfiltrer des crédentielles développeur et des données .env depuis des pipelines CI/CD.

• Crates Rust malveillantes et bot IA

Pris ensemble, ces éléments montrent que l’expression « supply chain logicielle » est trop faible pour décrire la réalité. En pratique, le poste développeur, le système de build, l’écosystème de packages et le plan de contrôle cloud forment désormais une seule chaîne d’attaque continue. Cette chaîne devient encore plus critique dans les environnements fortement marqués par l’IA, car les équipes avancent vite, installent des outils peu familiers, expérimentent de nouveaux frameworks agentiques et banalisent des privilèges locaux étendus. Les attaquants l’ont bien compris. Le point opérationnel pour les défenseurs est simple : si vous considérez encore la compromission de dépendances comme un problème limité à l’intégrité du build, vous passez à côté des impacts sur le cloud et l’identité. Aujourd’hui, un paquet compromis peut entraîner :

1. la compromission du poste local
2. le vol de jetons, clés SSH, identifiants cloud ou secrets .env
3. l’accès au CI/CD et l’altération des artefacts
4. l’escalade de privilèges dans le cloud
5. la persistance via la même pile d’automatisation utilisée par les défenseurs

C’est pourquoi la défense de l’IA ne peut plus être dissociée de la sécurité des plateformes. Les équipes qui construisent des workflows IA détiennent souvent précisément les identifiants que les attaquants cherchent ensuite à exploiter.

4) Vitesse et variation : les attaquants utilisent l’IA pour cibler le talon d’Achille des défenseurs

Enfin, il faut mentionner l’usage par Hive0163 du malware « Slopoly », assisté par IA, pour établir une persistance avant des opérations de ransomware.

• Hive0163 / Slopoly

Il convient de ne pas exagérer. Le thème du « malware généré par IA » se transforme encore trop facilement en titres apocalyptiques. Mais il existe une raison pratique pour laquelle les défenseurs doivent s’y intéresser : la valeur n’est pas tant dans des capacités inédites que dans le tempo opérationnel. Si l’IA permet à un acteur de générer suffisamment de variantes fonctionnelles, de construire plus rapidement une logique de persistance ou d’adapter le code juste assez pour ralentir les détections statiques et l’ingénierie inverse, cela a déjà une valeur considérable. Les groupes de ransomware n’ont pas besoin d’un code élégant. Ils ont besoin d’un code produit rapidement, jetable, et capable de leur faire gagner du temps. Cela doit bien résonner avec les équipes SOC, car cela reflète leur propre réalité : plus d’alertes, plus de surface d’attaque, et trop peu de temps pour une analyse approfondie. L’enseignement stratégique n’est donc pas que « les machines deviennent des auteurs géniaux de malware ». C’est que même une assistance IA médiocre peut creuser l’écart de débit entre attaque et défense si les blue teams restent trop manuelles.

Lecture d’ensemble : défendre le plan de contrôle, pas seulement l’endpoint

Pris dans leur ensemble, les événements de la semaine révèlent un schéma clair.

• Les navigateurs agentiques montrent comment du contenu non fiable peut orienter des workflows IA privilégiés.
• Les failles d’automatisation montrent comment un orchestrateur exposé peut compromettre l’infrastructure même du défenseur.
• Les incidents de supply chain montrent que l’outillage IA/dev constitue désormais une voie directe vers le cloud et les systèmes d’identité.
• Les malwares assistés par IA montrent que les attaquants utilisent l’automatisation pour gagner en vitesse, pas seulement en sophistication.

C’est pourquoi le prochain champ de bataille majeur de la défense de l’IA est le plan de contrôle. Dans ce sens, ce texte prolonge l’argument de La course aux agents : une fois que l’IA devient une infrastructure opérationnelle, la question décisive n’est pas seulement de savoir qui dispose des meilleurs modèles, mais qui sécurise les systèmes, les workflows et les plans de contrôle qui les entourent. Pas le benchmark du modèle. Pas la démo. Pas le débat sur la classification de la prompt injection. La vraie question est : que peut faire le système une fois compromis ? Pour les défenseurs, en particulier dans les fonctions SOC et threat intel, cela redéfinit les priorités :

• cartographier chaque workflow agentique capable d’agir, pas seulement de générer du texte
• identifier où les identifiants, sessions navigateur, fichiers locaux et rôles cloud intersectent avec les outils pilotés par l’IA
• mettre en place des mécanismes d’approbation, une journalisation durable et des capacités de rollback dans les systèmes d’automatisation
• traiter l’abus de packages, le vol de jetons et la compromission CI/CD comme une seule surface d’attaque, et non trois problèmes distincts
• prioriser la détection de séquences d’actions le long de la kill chain, plutôt que des événements isolés

Une base de sécurité robuste devrait désormais inclure :

• des frontières d’exécution strictes et le principe du moindre privilège pour les agents et les couches d’automatisation
• des barrières de filtrage entre les entrées non fiables et les systèmes capables d’agir
• une approbation explicite pour les transitions à haut risque, comme l’utilisation d’identifiants, les paiements, la messagerie sortante ou les changements en production
• une séparation entre composants de raisonnement et composants d’exécution, autant que possible

Le modèle précédent était que les attaquants visaient les utilisateurs tout simplement parce qu’ils cliquaient. Le modèle émergent est qu’ils visent les assistants IA parce que ceux-ci cliquent plus vite, disposent de plus de contexte et ont de plus en plus la capacité d’agir. C’est un changement bien plus structurant qu’une nouvelle semaine de battage médiatique autour de l’IA. Et cela fournit aussi un meilleur cadre pour les blue teams : ne vous demandez pas seulement si l’IA est présente dans votre environnement. Demandez quelles parties de cet environnement peuvent désormais agir à vitesse machine avec une autorité déléguée par des humains. C’est là que surviendront les prochains incidents majeurs de sécurité.