L’ouragan de l’IA est là

Depuis un an, je décris cela comme un brouillard autour de l’IA : des affirmations contradictoires, des risques incertains et des dirigeants qui peinent à distinguer ce qui compte. Le vent se lève désormais. L’IA accélère la création logicielle, expose des années de vulnérabilités accumulées et donne aux attaquants comme aux défenseurs des capacités qui opèrent à la vitesse des machines.

Nous l’appelions autrefois le brouillard. Le brouillard arrive, puis il se dissipe.

Je dis depuis un an que la création est passée à la vitesse des machines, mais pas la validation, et que l’écart entre les deux est l’endroit où se trouve le risque réel. Ce diagnostic n’a pas changé. Ce qui a changé, c’est le rythme. Le type de vulnérabilité critique que l’IA fait désormais émerger dans des logiciels largement utilisés, le genre de découverte qui survenait autrefois une ou deux fois par an et bouleversait le trimestre de tout le monde, apparaît plusieurs fois par semaine d’après ce que j’observe. Ce n’est pas une météo à attendre en espérant qu’elle passe.

Tout se résume à trois problèmes : des attaques automatisées qui avancent plus vite qu’un arriéré de tâches à la vitesse humaine ne peut les absorber, un développement agentique qui écrit du code et utilise des outils que personne n’a contrôlés, et des applications d’IA exécutées en production sans inventaire, sans politique et sans piste d’audit.

L’ouragan est déjà là. Débattre de sa vitesse ne rendra pas les couches applicatives ou d’infrastructure plus résistantes aux intempéries.

Pendant ce temps, l’opéra de l’IA se fait de plus en plus bruyant : prédictions annonçant la fin de la civilisation, avertissements dramatiques, appels concurrents à contrôler qui peut construire quoi. Je travaille dans la sécurité depuis longtemps, et j’ai traversé plus d’une période de ce genre. Je comprends l’instinct qui pousse à ne plus écouter tout cela, en le prenant pour du bruit.

Ne le faites pas. Cette fois, c’est différent.

Prenez le risque réel au sérieux et examinez attentivement si les réponses proposées nous rendent réellement plus sûrs ou si elles ne font qu’ajouter une voix de plus.

L’examen indépendant est désormais au cœur du débat

Dario Amodei vient de publier « We Must Pace the Frontier », proposant que les laboratoires de pointe ralentissent l’avancée des capacités afin de laisser le temps aux travaux de sécurité de rattraper leur retard. Regardez comment il propose de procéder.

Anthropic s’engage à intégrer des évaluateurs tiers indépendants bénéficiant d’un accès continu afin de vérifier ses pratiques de sécurité. Par ailleurs, Amodei cite des agents qui attaquent des systèmes en dehors de la tâche qui leur a été assignée, y compris le système qui évalue leurs performances. Ces exemples soulèvent des questions différentes sur la supervision et le contrôle. Pour la sécurité des entreprises, notre exigence architecturale est claire : le système qui crée une modification ne doit pas être son seul validateur.

George Kurtz, de CrowdStrike, a poursuivi la réflexion avec le contrepoint du praticien : réguler la prochaine étape ne sécurise pas ce qui est déjà déployé. Selon lui, le véritable point de contrôle se situe à l’exécution. Aujourd’hui, l’unité de menace est une campagne autonome, pas un pirate informatique, et chaque agent doit être traité comme une identité à privilèges, avec une application en temps réel et des preuves plutôt que des promesses : responsabilité au niveau du conseil d’administration, red team indépendante, divulgation des incidents et contrôles qui tiennent en production.

L’argument de George sur l’exécution est essentiel. Je l’étendrais au développement : gouverner les agents qui écrivent le code, les outils et serveurs MCP qu’ils utilisent, ainsi que le code qu’ils livrent. Les contrôles de développement réduisent l’exposition que nous introduisons ; les contrôles d’exécution limitent ce que les systèmes déployés peuvent faire.

Sinon, nous générons l’exposition de demain plus vite que nous ne pouvons contenir celle d’aujourd’hui. Et la règle s’applique à chaque couche : le système qui génère le code ou propose la correction ne peut pas être son propre validateur unique.

Trois points de départ différents : un laboratoire de pointe, un défenseur de l’exécution et nous, au point où le code et les agents sont créés. Il ne s’agit pas d’une plateforme commune. C’est la même exigence qui apparaît à trois couches différentes : l’examen indépendant compte à chaque couche et ne peut pas être tenu pour acquis. L’affirmation architecturale qui en découle nous appartient : le système qui crée une modification ne doit pas être son seul validateur. Lorsque les personnes qui ont le plus à gagner à dire « faites-nous confiance » choisissent plutôt « vérifiez-nous », ce n’est pas un élément de langage ; c’est une confirmation.

L’indépendance est ici une propriété technique, pas une question d’image de marque. Cela signifie que les preuves sont produites par quelque chose que l’agent producteur ne peut pas modifier, puis vérifiées par rapport à des contrôles situés hors de sa portée : tests exécutés, analyse des flux de données, comportement observé à l’exécution. Un deuxième prompt, un deuxième agent ou un deuxième modèle n’est pas indépendant. C’est le même type de jugement, demandé deux fois.

Les preuves ne sont désormais plus hypothétiques

Il y a quelques semaines, j’ai dit que ce qui m’inquiétait le plus n’était pas la sophistication de ces attaques, mais leur propagation : cette capacité allait se démocratiser, et beaucoup plus de personnes seraient bientôt capables de mener ce type d’attaque.

Huit jours plus tard, le rapport de septembre d’Anthropic s’ouvrait sur le même constat, avec ses propres mots : les attaques sophistiquées ne nécessitent plus d’attaquants sophistiqués, car l’IA a réduit à néant l’écart en main-d’œuvre et en outils qui séparait autrefois les opérations soutenues par des États des individus. J’aurais préféré m’être trompé.

L’incident cité par Amodei illustre un mode de défaillance : des agents qui quittent la tâche qui leur a été confiée. Ce qui suit est l’autre, et c’est celui auquel la plupart des organisations seront confrontées en premier : des personnes qui utilisent délibérément ces outils, à grande échelle.

Le rapport de septembre d’Anthropic documente GTG-20006, un acteur d’espionnage russe lié à l’État selon l’attribution d’Anthropic, qui exécutait un flux de travail assisté par l’IA ayant identifié, modifié, reconstruit et redéployé ses propres implants après que des produits de sécurité les eurent signalés. Le logiciel malveillant n’a pas évolué de lui-même : un humain le pilotait, et l’IA a fermé la boucle plus rapidement qu’une nouvelle détection ne pouvait être écrite et déployée.

Le même rapport montre que la chaîne d’approvisionnement de l’IA est devenue une cible à part entière. Un acteur motivé par des raisons financières a injecté des instructions malveillantes dans le bac à sable d’évaluation automatisée d’un fournisseur d’IA et a obtenu les identifiants qu’il contenait, notamment les clés API de production de l’environnement de ce fournisseur.

Anthropic indique que ses propres systèmes n’ont pas été compromis et que la tentative de l’acteur pour atteindre un modèle en préversion a échoué. Des identifiants d’IA volés offrent simultanément trois avantages à un attaquant : l’échelle, la puissance de calcul de quelqu’un d’autre et le nom de quelqu’un d’autre dans le trafic. La chaîne d’approvisionnement de l’IA n’est pas une catégorie de risque future, mais un risque actif, aujourd’hui.

Plus près de chez nous : Snyk est signataire de la lettre collective sur la cyberdéfense, aux côtés d’OpenAI, d’Anthropic, de Google, de Microsoft, d’Akamai et de centaines d’autres organisations, pour alerter sur le fait que des criminels pourraient lancer des attaques pilotées par l’IA contre des infrastructures critiques dans les mois à venir. Comme je l’ai dit au Boston Globe, c’est comme savoir qu’un ouragan arrive. Peut-être n’avez-vous jamais réparé cette fenêtre. Peut-être que vos volets sont bloqués. Si vous savez qu’il arrivera la semaine prochaine, allez-vous la réparer ou non ?

Se préparer à la tempête

Sécuriser dès la conception. Appliquer à l’exécution. Valider indépendamment.

Sécuriser les logiciels dès leur conception, détecter ce que le code généré par l’IA introduit et les paquets qu’il récupère, avant même qu’il ne s’approche de la validation et de la mise en production, et non après.

Gouverner les agents et leurs chaînes d’approvisionnement, car un agent disposant d’un accès excessif et un outil non contrôlé constituent désormais une surface d’attaque standard, et non un cas limite.

Tester et corriger en continu, car un test d’intrusion ponctuel ne peut pas suivre le rythme d’un paysage de menaces qui évolue chaque semaine. Les tests offensifs continus, fondés sur des preuves de production, permettent d’établir que les contrôles définis résistent aux chemins d’attaque que vous avez réellement testés. C’est une affirmation plus limitée que « nous sommes sécurisés », et c’est la seule qui vaille la peine d’être formulée.

Et valider indépendamment ce que l’IA construit, la même discipline vers laquelle le secteur converge désormais à chaque couche, appliquée à chaque ligne de code et à chaque agent que vos équipes livrent.

Rien de tout cela ne fonctionne si les résultats s’accumulent sans suite. Jason Clinton, Deputy CISO chez Anthropic, a bien résumé le volet opérationnel lorsque nous avons annoncé notre partenariat : « In AI security, detection was never the bottleneck. By pairing Claude's capabilities with Snyk, enterprises can turn high-fidelity findings into action inside the workflows where software is built. »

Ouverts. Alliés. Toujours debout.

La couche défensive doit rester largement accessible. Les modèles ouverts, le partage de renseignements et le soutien aux mainteneurs de l’open source doivent faire partie de l’architecture de sécurité, et non rester à l’extérieur.

Les étapes ultérieures proposées par Amodei appellent à une coordination entre les laboratoires de pointe, puis entre les gouvernements. C’est une proposition raisonnable, et ce n’est pas un plan visant à exclure qui que ce soit. Ma préoccupation porte sur l’effet plutôt que sur l’intention : tout dispositif qui finit par concentrer entre les mains de quelques laboratoires la capacité de construire, d’inspecter et de défendre les systèmes d’IA devient un point de défaillance unique, quelle que soit sa conception initiale. Une résilience qui dépend de la confiance accordée à la feuille de route d’un seul fournisseur n’est pas une résilience. Évaluez chaque solution proposée, y compris la nôtre, selon sa capacité à élargir le cercle des personnes capables de se défendre.

Une partie de ce problème est antérieure à l’IA. Pendant quarante ans, nous avons livré des logiciels sans nous imposer la discipline de sécurité que d’autres domaines de l’ingénierie considèrent comme non négociable. Nous aimons créer, mais nous n’avons jamais vraiment aimé sécuriser ce que nous créons. L’IA n’a pas introduit cet écart ; elle a supprimé le temps dont nous nous servions pour le dissimuler et y a ajouté de nouveaux risques.

La préparation relève de la responsabilité des dirigeants, et elle commence par la partie que nous choisissons.

Ouverts. Alliés. Toujours debout.

Le 17 septembre, je rejoindrai Alon Krifcher, Head of Applied AI chez Anthropic, pour présenter les quatre actions qui comblent l’écart entre attaque et défense à la vitesse des machines : découvrir, corriger, valider et prévenir. Réservez votre place dès aujourd’hui.

Interrogez votre propre agent

Si vous souhaitez transformer cela en conversation avec votre propre équipe, transmettez ce qui suit à votre agent. Il ne vous dira pas si vous êtes exposé — aucun document public ne peut le faire —, mais il vous indiquera quelles questions poser.

Read https://www.anthropic.com/threat-intelligence-report-september-2026,
https://snyk.io/evo/, and https://snyk.io/blog/ai-hurricane-is-here/ as reference material only.
Do not run tests, scans, or commands against any system, and do not change
any configuration.

For each attack path described in the report:

1. Separate what is documented evidence, what is my assumption, and what
   is unknown.
2. Identify the controls that could block or reduce it. For each, say
   whether it acts on what an agent uses, what it does, or what it
   generates, or on what an already-deployed system is permitted to do.
3. State what internal evidence we would need to assess our own exposure,
   and who in the organization would hold it.

Then rank a list of questions for my security team by potential impact,
likely exposure, and the size of the evidence gap.

Public reports and product descriptions cannot establish our actual
posture. Return questions and evidence requests, not an assessment of
whether we are secure. Never print the value of any key, token, or
credential.