L’IA fait surgir tous les risques que vous avez acceptés : sept enseignements du panel de sécurité de l’IA sans filtre

Le 14 octobre, la veille de l’événement phare de l’AI Security Summit (AISS) à San Francisco, Snyk a organisé Le panel de sécurité de l’IA : sans filtre. Deirdre Bosa, de Yahoo Finance, a animé les échanges avec quatre personnes qui abordent la sécurité de l’IA sous des angles très différents :

• Manoj Nair, directeur technique et directeur de l’innovation, Snyk

• Michael D'Angelo, responsable technique, cyber, OpenAI

• John Hultquist, analyste en chef, Google Threat Intelligence Group

• Ed Sim, fondateur et associé général, boldstart ventures

Même s’ils n’étaient pas d’accord sur la manière de réglementer l’IA, de superviser les agents et sur le degré de confiance à leur accorder, ils partageaient largement le même diagnostic : l’IA a rendu les attaques peu coûteuses, rapides et accessibles à presque tout le monde, faisant ressurgir tous les risques qu’une organisation a déjà accepté. Détecter les vulnérabilités devient plus facile chaque mois, mais la capacité à les corriger est le véritable goulot d’étranglement. Les défenseurs ne combleront cet écart que lorsque les machines réaliseront l’essentiel des corrections, dans le respect de contrôles rigoureux de l’identité, des autorisations et de l’intention.

Quelle place ce panel occupait-il dans l’AISS 2026 ?

L’AISS a été lancé à San Francisco l’an dernier (2025) et a affiché complet. L’événement phare de cette année s’est tenu le 15 octobre et a attiré autant de monde que l’an dernier.

Comme l’indique le slogan de l’événement, il s’agissait d’une journée entière, dans une seule salle, autour d’un seul programme, pour les personnes responsables des risques liés à l’IA à l’échelle de leur organisation. Des éditions régionales « satellites » suivront à Copenhague et à Sydney, le 25 novembre. L’AISS est une initiative de Snyk et d’AI Engineer. Ses règles principales : pas de banalités et pas de panels où tout le monde est d’accord. Voilà pourquoi les désaccords mentionnés plus haut sont si importants. Nous avons finalement constaté que ce qui nous rassemble est plus fort que ce qui nous divise.

Ce panel organisé par Snyk a ouvert le bal, l’après-midi précédant l’événement. Il promettait d’aborder quatre grandes questions : la menace actuelle, celle à venir, qui en est responsable et que faire dès lundi matin. L’événement lui-même a exploré chacun de ces thèmes en profondeur. Le panel a pris du recul, réunissant un laboratoire pionnier, une équipe de renseignement sur les menaces, un investisseur et une entreprise de sécurité qui travaille là où le code et les agents sont créés.

Cette conversation animée et approfondie a fait ressortir sept enseignements :

1. Pourquoi l’IA constitue-t-elle un appel de marge sur les risques que vous portez déjà ?

La plupart des risques exploités par l’IA existaient déjà, mais le coût de leur exploitation a changé.

Manoj a repris une formule d’un client de Snyk : « L’IA est utilisée par les attaquants. C’est une nouvelle surface d’attaque, mais aussi une menace interne. » Il en a ensuite nommé la conséquence.

« Ce sont tous vos risques existants. L’IA est l’appel de marge sur ces risques. »

Manoj Nair, Snyk

John Hultquist a ensuite expliqué les mécanismes : les attaquants utilisent des technologies autonomes depuis environ huit ans, passant des fausses images et des courriels d’hameçonnage ciblé aux appels truqués par deepfake, puis à des opérations entières. Des travailleurs informatiques nord-coréens s’appuient désormais sur des modèles pour mener leurs opérations de bout en bout. Les modèles les rendent aussi plus efficaces : ils peuvent résoudre des problèmes en cours d’attaque, se déplacer plus rapidement dans un réseau et transformer un correctif récent en exploit fonctionnel avant que la plupart des défenseurs ne l’aient appliqué. Et leur utilisation se généralise : « Ces outils sont désormais accessibles à un bien plus grand nombre de personnes. »

Ed Sim a évoqué les piratages de banques sud-coréennes. Selon CrowdStrike, l’opérateur était probablement une seule personne de 26 ans basée en Chine, qui utilisait un agent de test d’intrusion d’IA open source ainsi qu’un agent de codage commercial. Au moins neuf banques auraient été ciblées. Comme l’a expliqué Adam Meyers, de CrowdStrike, aux journalistes, cette affaire « permet à une seule personne de cibler de nombreux clients en très peu de temps grâce à la puissance de l’IA ». La conclusion d’Ed ? « On ne peut pas lutter contre des hackers répartis dans le monde entier, qui disposent de machines et d’humains. »

Hultquist a souligné l’asymétrie sous-jacente : les attaquants peuvent expérimenter à très faible coût. S’il essayait une nouvelle méthode pour braquer une banque et échouait, « il y a de fortes chances que je finisse en prison, voire pire ». En ligne, « ils ne subissent pas les mêmes conséquences ».

2. En quoi les agents d’IA constituent-ils une surface d’attaque différente ?

Cette nouvelle surface d’attaque agit de manière autonome : les agents, les compétences qu’ils chargent, ainsi que les accès qu’ils obtiennent et accumulent.

Le développement est bel et bien devenu — enfin ? — une usine logicielle, où les agents écrivent le code et accèdent à tout ce dont ils ont besoin. Tout ce à quoi ils accèdent devient une surface d’attaque. Les compétences des agents représentent le cas le plus préoccupant, car elles sont rédigées en anglais courant et, comme l’a dit Manoj, « trois lignes en anglais peuvent devenir un logiciel malveillant ». L’étude ToxicSkills de Snyk a révélé au moins une faille de sécurité dans 36,82 % des 3 984 compétences analysées, ainsi que 76 charges malveillantes confirmées. Pour en publier une sur ClawHub, il suffisait d’un fichier Markdown et d’un compte GitHub créé une semaine plus tôt.

Hultquist a également présenté le point de vue des attaquants. Les acteurs malveillants préfèrent généralement utiliser des systèmes autonomes plutôt que de les attaquer. Une exception : lorsque des personnes ont donné à leurs agents personnels accès à tous les aspects de leur vie, les attaquants « ont sauté sur l’occasion, car ils ont reconnu tout le potentiel de cette agrégation ». Les systèmes déployés seront les prochaines cibles. Les attaquants ne s’y sont pas encore attaqués à grande échelle, « mais ils le feront », et leur défense nécessitera « un tout nouveau régime de sécurité ».

L’incident Hugging Face a montré la situation de l’intérieur. En juillet, des modèles d’OpenAI utilisés dans une évaluation interne de cybersécurité ont contourné les contrôles censés les isoler et ont compromis Hugging Face. Le rapport d’OpenAI lui-même qualifie l’incident de « tir de semonce ». Michael D'Angelo en a résumé la cause en deux phrases : « Faites cette tâche et vous serez récompensé. Alors, ils ont exécuté la tâche. »

Manoj est remonté à une cause peu spectaculaire : « des secrets exposés publiquement qu’un jeune de 14 ans peut attaquer avec quelques outils, sans IA ». Le rapport confirme son hypothèse de départ : un agent a découvert des identifiants Hugging Face exposés publiquement et les a communiqués aux autres agents.

Pour Ed Sim, il faut encadrer les agents comme les personnes internes qu’ils sont : chacun doit avoir sa propre identité, une piste d’audit et des accès accordés pour une tâche, puis révoqués une fois celle-ci terminée. L’intention, elle, reste difficile à maîtriser :

« Si mon objectif est de réduire le coût de mon informatique, que se passe-t-il si, en cours de route, je décide de supprimer quelques bases de données de production parce que j’ai compris que c’était un bon moyen de réduire les coûts informatiques ? Eh bien, j’ai fait mon travail, non ? »

Ed Sim, boldstart ventures

Et à mesure que l’IA s’installe dans les puces, les appareils et les robots, Ed a demandé : « Qui va sécuriser le micrologiciel, les puces, toute cette intelligence embarquée ? »

3. Pourquoi la correction est-elle devenue le goulot d’étranglement ?

La détection des vulnérabilités coûte toujours moins cher, mais leur correction ne suit pas le même rythme. Un laboratoire pionnier, une équipe de renseignement sur les menaces et Snyk constatent le même écart, chacun sous un angle différent.

Michael a retracé les avancées successives de la détection, des fuzzers aux tests dynamiques, puis aux environnements d’agents. La difficulté vient après et tient souvent à « un problème politique » : les équipes découvrent plus de problèmes qu’elles ne peuvent en traiter, ce qui entraîne un ping-pong de correctifs, un fil Slack consacré à « qui fait quoi, quand et comment », où « si ça casse, c’est votre faute ».

Hultquist l’a appris chez Google avec Big Sleep, un projet de détection des vulnérabilités basé sur un environnement d’IA. Le projet a été critiqué sur les réseaux sociaux pour avoir signalé des bogues à des personnes qui maintiennent des logiciels open source pendant leur temps libre. « Il ne suffit pas de trouver ces problèmes », a-t-il déclaré. Lorsqu’on signale à une entreprise une vulnérabilité zero-day déjà exploitée par un attaquant, la réponse est souvent : « ça va prendre du temps ». Détecter et corriger sont les deux faces d’une même pièce, a-t-il dit, et « si vous ne faites pas les deux, vous ne pourrez pas suivre ».

Manoj a cité le projet Glasswing, dans lequel Anthropic affirme dans sa propre mise à jour que les progrès en matière de sécurité logicielle « étaient auparavant limités par la vitesse à laquelle nous pouvions détecter de nouvelles vulnérabilités. Désormais, ils dépendent de la vitesse à laquelle nous pouvons vérifier, divulguer et corriger le grand nombre de vulnérabilités détectées par l’IA ».

Le rapport désigne la capacité humaine à trier et à corriger comme le goulot d’étranglement. Au 22 mai, au début de la période de divulgation de 90 jours, les mainteneurs open source avaient corrigé 75 des 530 bogues de gravité élevée ou critique signalés par Anthropic.

Selon Manoj, l’indicateur qui compte, ce sont les « correctifs déployés en production ». L’étude VulnBump de Snyk, publiée elle aussi hier, le 15 octobre, part du même constat : au cours des six premiers mois de 2026, Snyk Open Source a détecté 459 millions de vulnérabilités dans quelque 300 000 organisations. Bien qu’une version corrigée soit connue pour 94 % d’entre elles, environ 10 % seulement avaient été résolues. L’étude ne comptabilise un correctif que si la vulnérabilité a disparu et que le projet s’installe, se construit et passe ses tests. (Le Remediation Agent d’Evo de Snyk a satisfait à ces critères dans 90,2 % des 307 mises à niveau de dépendances réelles.)

Son idée principale portait sur la manière de briser ce cercle vicieux. « Tout se joue désormais au moment de la création » : « les agents sont les acteurs », et les développeurs définissent l’intention. Il faut prévenir les problèmes à ce stade et les corriger en tenant compte du contexte, sinon on reste pris dans « cette boucle sans fin : détecter, corriger, détecter, corriger ».

4. La priorisation reste-t-elle efficace lorsque l’IA peut enchaîner les vulnérabilités de longue traîne ?

La priorisation compense le manque de temps et de ressources humaines, et l’IA apprend à en tirer parti.

Manoj conteste un conseil habituellement donné : la priorisation contextuelle. Analyser les signaux pour choisir parmi 100 problèmes les 10 qui méritent d’être corrigés, c’est ainsi que fonctionne le secteur. Mais cette méthode ne sert qu’à adapter la charge de travail aux effectifs disponibles. Un attaquant autonome n’a pas cette contrainte.

« Nous devrions examiner les 100 problèmes et pouvoir tous les corriger. Car avant même que vous vous en rendiez compte, ces 10 problèmes seront devenus 100. »

Manoj Nair, Snyk

La longue traîne compte, car l’IA peut combiner ses éléments : elle raisonne en plusieurs étapes, a expliqué Manoj, et peut ainsi enchaîner cinq ou six vulnérabilités situées au 99e percentile de votre liste — celles « auxquelles vous pensiez ne jamais vous attaquer, faute d’effectifs pour les corriger » — pour provoquer un incident grave. Dans l’essai cité par Michael, Greg Brockman décrit la faille Hugging Face de la même manière : un collectif d’agents « enchaînant des vulnérabilités allant de failles de sécurité encore inconnues à l’utilisation d’identifiants de comptes utilisateurs divulgués sur Internet ».

L’autre volet de l’argument de Manoj est culturel. Tout au long de sa carrière, le compromis a toujours été le même : les risques opérationnels sont inacceptables, alors la sécurité attend. La semaine précédente, lors d’une réunion avec des centaines de RSSI, il a entendu le discours commencer à changer. Les dirigeants sont désormais prêts à interrompre brièvement une application pour éliminer un risque de sécurité. « Bon, quelque chose sera peut-être hors ligne un petit moment, mais ça reviendra. C’est mieux que de vouloir corriger tout ça à la perfection et d’y passer un an. »

5. À quoi ressemble une défense à la vitesse des machines, et quelle place y reste-t-il pour les humains ?

La défense doit avancer à la vitesse de l’attaque. Cela signifie que les agents font l’essentiel du travail et que les personnes se chargent de porter un jugement.

Hultquist a distingué deux types d’attaquants. D’un côté, les équipes d’espionnage qui agissent « lentement et discrètement », en se fondant dans l’environnement pendant des années. De l’autre, les criminels qui pratiquent l’extorsion, pour qui la vitesse est essentielle : « Il y a une course entre vous et moi : je dois obtenir ce qu’il me faut pour vous extorquer avant que vous ne puissiez m’arrêter. »

« Un SOC classique avec un humain dans la boucle ne pourra pas suivre. Le SOC devra agir de manière autonome, sinon vous n’aurez qu’un appel à recevoir. »

John Hultquist, Google Threat Intelligence Group

Ed Sim veut que les équipes de défense bâtissent « une usine de défense logicielle, comme les développeurs bâtissent des usines de code », mais la plupart n’ont pas encore commencé : malgré tous les discours sur la défense autonome, « 99 % des entreprises ne le font pas du tout ». OpenAI est plus avancée : elle indique que l’IA effectue déjà le triage de presque toutes les alertes de sécurité initiales avant qu’un humain n’intervienne. « Nous n’avons pas les cinq ans que nous pensions avoir. Nous avons environ cinq jours », a déclaré Ed. Les RSSI ne veulent pas donner de pouvoir aux agents, « mais ils vont devoir le faire à un moment donné ». Hultquist s’attend à ce que des incidents les y contraignent : « dans bien des cas, l’argent ne se débloque qu’après un électrochoc. »

Il faut garder les humains dans la boucle là où leur intervention compte vraiment. Manoj a décrit leur rôle comme celui de définir l’intention, de s’appuyer sur l’expérience et de faire preuve de discernement. Pour lui, l’essentiel, c’est le ratio entre les problèmes détectés et ceux qui sont corrigés : « Si ce ratio n’est pas corrigé, tout le reste n’est que paroles en l’air. » Le goulot d’étranglement, c’est le processus, car chaque pull request doit être approuvée par un humain. Automatisez les approbations sans risque et laissez les équipes décider des exceptions. Puis reprenez l’initiative : « Quand un attaquant autonome va s’en prendre à vous, pourquoi ne pas vous attaquer vous-même ? »

Michael D’Angelo a lancé le compte à rebours. Les modèles ouverts ont « quelques mois » de retard sur les modèles de pointe, un écart que Greg Brockman considère comme une fenêtre de tir pour les défenseurs : utilisez dès maintenant l’intelligence des modèles de pointe pour analyser vos actifs et corriger les vulnérabilités détectées, avant qu’une personne équipée d’un modèle comparable, « dans sa chambre, par exemple », ne vous devance. C’est la mesure que chaque RSSI devrait prendre avant la sortie d’un modèle ouvert de niveau avancé.

6. Comment superviser un système dont le comportement change à chaque fois ?

La question reste ouverte, et c’est là que les réponses des intervenants divergent.

Pour Michael, tout part de cette question : « Comment sécuriser un système non déterministe ? En général, il y a deux façons de faire : d’abord, contrôler ce à quoi il a accès ; ensuite, utiliser un autre système non déterministe. » Il s’est inspiré de son expérience militaire :

« Quand on donne à des jeunes de 18 ans accès à des équipements extrêmement dangereux, on procède de deux façons : premièrement, on ne donne certains accès qu’à certaines personnes. Deuxièmement, on place un sergent à leurs côtés pour s’assurer qu’ils font ce qu’ils sont censés faire. »

Michael D’Angelo, OpenAI

Il s’attend à voir des flottes de modèles, supervisées par des modèles très peu coûteux.

Ed Sim a intégré une couche déterministe à sa réflexion. « Il faudra tout un village », a-t-il déclaré : l’intelligence des modèles de pointe pour la première analyse, puis des systèmes fondés sur des années de données réelles sur les vulnérabilités et la manière dont on les corrige, car « il faut un certain déterminisme. »
La question des modèles ouverts ou fermés, qui selon Manoj est désormais posée par les DSI depuis quelques mois, appelle la même logique fondée sur les cas d’usage : héberger un modèle dans un environnement que vous contrôlez, « c’est une couche de protection, mais ça ne suffit pas : quel est le comportement du modèle selon le cas d’usage ? » Certains modèles ouverts sont bien alignés, mais divulguent tout de même gravement des informations personnelles. Dans ce cas, « ne l’utilisez pas pour ce cas d’usage ». Et il ne faudrait pas non plus « partir du principe qu’un modèle de pointe est sécurisé. »

7. Qui est responsable lorsqu’un agent cause des dommages ?

La responsabilité se définit dans la pratique, tandis que le débat sur les politiques se poursuit en arrière-plan.

Ed Sim a posé la question à laquelle personne n’a encore répondu : « Est-ce le fournisseur du modèle ? L’entreprise qui déploie un agent qui s’en prend aux systèmes de quelqu’un d’autre ? » OpenAI teste ses propres versions avec des équipes internes et des testeurs externes, dont le travail est documenté dans des fiches système. Michael a reconnu franchement que le secteur « cherche encore à y voir clair. »

Les intervenants n’étaient pas d’accord sur la personne qui devrait trancher. Ed est favorable à l’autorégulation : il prévient que des règles conçues pour les plus grandes entreprises étoufferaient la prochaine « entreprise à 100 milliards de dollars » et que si nous « nous réglementons à mort », la Chine prendra l’avantage. Deirdre a répliqué :

« Pourtant, quand on entend l’argument sur la Chine et qu’on regarde ce qui s’y passe, on constate qu’elle réglemente l’IA de façon beaucoup plus stricte que les États-Unis. »

Deirdre Bosa, Yahoo Finance

Elle a également demandé si l’autorégulation par les plus grandes entreprises ne risquait pas de favoriser la capture réglementaire. La réponse de Manoj était nuancée et urgente : « Nous n’avons pas le luxe d’attendre. » D’abord des normes, puis de la visibilité, de l’autorégulation et une réglementation plus large qui impose responsabilité et transparence, le tout « beaucoup plus rapidement que par le passé ». Il a aussi insisté sur un point : « Nous consacrons beaucoup de temps aux laboratoires », alors que les agents se répandent dans toutes les entreprises sous la forme d’« agents très performants ou d’initiés potentiels. »

Les banques agissent déjà. Ed a cité l’appel aux résultats de JPMorgan Chase cette semaine : la banque a déclaré qu’elle bloque, dans la mesure du possible, les services qui reposent sur le partage des identifiants bancaires des clients. L’avertissement de Jeremy Barnum, directeur financier de la banque, rapporté par American Banker : « s’ils communiquent leurs identifiants à l’agent et que celui-ci fait quelque chose qu’ils ne souhaitent pas, ils en seront tenus responsables. »

Que devraient faire les responsables de la sécurité dès lundi matin ?

Voici les mesures proposées au cours de cette heure, dans l’ordre où nous les prendrions :

1. Profitez de la fenêtre de tir des défenseurs. Utilisez dès maintenant des modèles de pointe pour analyser votre code, votre infrastructure et votre backlog, avant que des modèles ouverts aux capacités comparables ne parviennent aux attaquants (Michael D’Angelo).

2. Attaquez-vous vous-même en premier. Un attaquant autonome va de toute façon arriver (Manoj Nair).

3. Améliorez le ratio entre les vulnérabilités détectées et corrigées. Automatisez les corrections sans risque et laissez les équipes gérer les exceptions et les décisions qui demandent du discernement (Manoj Nair).

4. Laissez le SOC agir de façon autonome. Un humain dans chaque boucle ne peut pas suivre le rythme d’un groupe d’extorsion (John Hultquist).

5. Attribuez une identité à chaque agent. Il doit avoir ses propres identifiants, une piste d’audit et des accès limités à sa tâche, qui expirent à la fin de celle-ci (Ed Sim). Commencez par vérifier ce que vos agents peuvent déjà faire.

6. Activez partout une authentification multifacteur robuste (Manoj Nair).

7. Posez clairement la question au conseil d’administration. « Pourquoi ne pouvons-nous pas tout corriger ? » Si la réponse est que la disponibilité prime toujours, il est temps de revoir cet arbitrage.

Alors, qui paie le prix de l’appel de marge ?

Pour une table ronde conçue pour faire émerger les désaccords, le consensus a finalement fait la une. Un laboratoire de pointe, une équipe de renseignement sur les menaces, un investisseur et Snyk sont arrivés à la même conclusion : le risque que vous avez accepté à l’époque où les attaques étaient lentes et coûteuses arrive à échéance, et ce sont les attaquants qui en récoltent les fruits.

La solution est assez peu spectaculaire : corrigez au rythme des découvertes, confiez l’essentiel des corrections aux machines, laissez les humains prendre les décisions qui demandent du discernement et donnez à chaque agent une identité et des limites avant de lui confier les clés.

Ed Sim mise sur les défenseurs pour l’année à venir, précisément parce qu’ils « n’utilisent pas encore assez ces capacités ». C’est une lecture optimiste, mais aussi dérangeante : c’est à nous de combler l’écart, et le compte à rebours avait commencé avant même la table ronde.

Le lendemain matin, Manoj a prononcé la première keynote de l’événement : The AI Hurricane Is Here: Build for the Storm. La table ronde avait déjà exposé les arguments en faveur de la deuxième partie de ce titre.

Vous voulez savoir à quoi vos agents peuvent accéder ? Téléchargez le rapport 2026 State of Agentic AI Adoption, Volume III pour découvrir l’analyse de Snyk sur les risques liés aux modèles dans des milliers d’environnements d’entreprise.