L’ouragan de l’IA est là

Depuis un an, je décris cela comme un brouillard de l’IA : des affirmations contradictoires, des risques incertains et des dirigeants qui peinent à voir ce qui compte. Les vents se lèvent maintenant. L’IA accélère la création logicielle, révèle des années de vulnérabilités accumulées et donne aux attaquants comme aux défenseurs des capacités opérant à la vitesse des machines.

Nous appelions cela 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 c’est dans l’écart entre les deux que réside le véritable risque. Ce constat n’a pas changé. Ce qui a changé, c’est le rythme. Le type de faille critique que l’IA révèle désormais 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, survient plusieurs fois par semaine, d’après ce que j’observe. Ce n’est pas quelque chose que l’on peut attendre tranquillement.

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

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

Pendant ce temps, l’opéra de l’IA monte en puissance : prédictions annonçant la fin de la civilisation, avertissements dramatiques, demandes concurrentes visant à contrôler qui peut construire quoi. Je travaille dans la sécurité depuis longtemps, j’ai traversé plus d’un de ces moments, et je comprends l’envie de faire abstraction de tout cela en le considérant comme 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.

La surveillance indépendante est désormais l’enjeu

Dario Amodei vient de publier « We Must Pace the Frontier », proposant que les laboratoires à la pointe ralentissent l’avancement des capacités afin que les travaux de sécurité puissent rattraper leur retard. Regardez comment il propose de procéder.

Anthropic s’engage à intégrer des évaluateurs tiers bénéficiant d’un accès continu afin de vérifier ses pratiques de sécurité. Par ailleurs, Amodei cite des agents attaquant 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 éléments 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 : ralentir ce qui vient 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égiée, avec une application en temps réel et des preuves plutôt que des promesses : responsabilité au niveau du conseil d’administration, red teaming indépendant, divulgation des incidents et contrôles qui tiennent en production.

L’argument de George en faveur du contrôle à l’exécution est essentiel. Je l’étendrais au développement : gouverner les agents qui écrivent, 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 à l’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 et unique validateur.

Trois points de départ différents : un laboratoire à la pointe, un défenseur de l’exécution et nous, au point où sont créés le code et les agents. Ce n’est pas une plateforme commune. C’est la même exigence qui se manifeste à trois couches différentes : la surveillance indépendante est essentielle à chaque couche et ne peut pas être considérée comme acquise. Au-delà de ce point, notre position architecturale est la suivante : le système qui crée une modification ne doit pas être son seul validateur. Lorsque ceux 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. Elle signifie que les preuves sont produites par un système que l’agent producteur ne peut pas modifier et vérifiées au regard de contrôles 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. Il s’agit du 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é se démocratisait et, bientôt, beaucoup plus de personnes seraient capables de faire cela.

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. L’autre aspect est le suivant, 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 rattaché à l’État russe selon l’attribution d’Anthropic, qui exécutait un workflow 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 dirigeait, et l’IA a bouclé le processus plus vite qu’une nouvelle détection ne pouvait être écrite et déployée.

Le même rapport documente la transformation de la chaîne d’approvisionnement de l’IA en cible à part entière. Un acteur motivé par des objectifs financiers 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 d’API de production de l’environnement même 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 capacité 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, qui avertissent que des criminels pourraient lancer des attaques pilotées par l’IA contre des infrastructures critiques dans les prochains mois. 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 arrive la semaine prochaine, allez-vous la réparer ou non ?

Se préparer à la tempête

Sécuriser dès la conception. Appliquer les contrôles à 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 packages qu’il récupère, avant qu’il ne soit près d’être validé et livré, et non après.

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

Tester et corriger en continu, car un pentest ponctuel ne peut pas suivre le rythme d’un paysage des menaces qui évolue chaque semaine. Les tests offensifs continus, fondés sur des preuves issues de la production, permettent d’établir que les contrôles spécifiés résistent aux chemins d’attaque que vous avez effectivement 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 construit l’IA, selon 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 formulé le volet opérationnel lorsque nous avons annoncé notre partenariat : « Dans la sécurité de l’IA, la détection n’a jamais été le goulot d’étranglement. En associant les capacités de Claude à celles de Snyk, les entreprises peuvent transformer des résultats à haute fidélité en actions au sein même des workflows où les logiciels sont conçus. »

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 en dehors.

Les étapes ultérieures proposées par Amodei appellent à une coordination entre les laboratoires à la 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 la capacité à construire, inspecter et défendre les systèmes d’IA entre les mains de quelques laboratoires devient un point unique de défaillance, quelle qu’ait été sa conception. 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 de ceux qui peuvent se défendre.

Une partie de ce problème est antérieure à l’IA. Nous avons livré des logiciels pendant quarante ans 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 a ajouté ses propres risques par-dessus.

La préparation relève de la responsabilité des dirigeants, et elle commence par la part 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 l’attaque et la 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 le texte suivant à 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.