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é The AI Security Panel: Unfiltered. Deirdre Bosa, de Yahoo Finance, a animé une discussion réunissant 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 chez Snyk

• Michael D'Angelo, responsable technique, cybersécurité, chez OpenAI

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

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

S’ils n’étaient pas toujours d’accord sur la manière de réglementer l’IA, de superviser les agents ou sur le degré de confiance à leur accorder, ils partageaient largement le même diagnostic de fond : l’IA a rendu les attaques peu coûteuses, rapides et accessibles à presque tout le monde, faisant peser une menace sur tous les risques qu’une organisation a déjà accepté de prendre. Il devient chaque mois plus facile de trouver des vulnérabilités, mais la véritable contrainte, c’est la capacité à les corriger. Les équipes de défense ne combleront pas cet écart tant que les machines ne feront pas l’essentiel du travail de correction, dans un cadre reposant sur des contrôles réels des identités, des autorisations et des intentions.

Quelle place occupait cette table ronde 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, qui s’est tenu le 15 octobre, 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 complète, dans une seule salle, avec une seule piste, 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 principales règles : pas de banalités et pas de tables rondes où tout le monde est simplement d’accord. Voilà pourquoi les désaccords évoqués plus haut sont si importants. Nous avons tout de même constaté que ce qui nous rassemble est plus fort que ce qui nous sépare.

Cette table ronde organisée par Snyk a donné le coup d’envoi de l’événement, la veille au soir. Elle promettait d’aborder quatre grandes questions : la menace actuelle, celle à venir, les responsabilités et les mesures à prendre dès le lundi matin. Les différentes sessions de l’événement ont approfondi chacun de ces sujets. La table ronde, elle, a pris de la hauteur, réunissant un laboratoire pionnier, une équipe de renseignement sur les menaces, un investisseur et une entreprise de sécurité qui intervient là où le code et les agents sont créés.

Sept idées fortes se sont dégagées de cette discussion animée et approfondie :

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 figuraient déjà dans les comptes, mais le coût de leur mise à profit, lui, a changé.

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

« Ce sont tous les risques que vous avez déjà. L’IA vous envoie un appel de marge. »

Manoj Nair, Snyk

John Hultquist a ensuite décrit les mécanismes en jeu : 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 hypertrucage, puis à des opérations entières. Les informaticiens nord-coréens pilotent désormais leurs opérations de bout en bout à l’aide de modèles. Ces derniers rendent aussi les attaquants plus efficaces : ils les aident à résoudre des problèmes en pleine attaque, à se déplacer plus rapidement sur un réseau et à transformer un correctif tout récent en exploit fonctionnel avant que la plupart des équipes de défense ne l’aient appliqué. Et cette capacité peut changer d’échelle : « Ces outils sont désormais accessibles à beaucoup plus de monde. »

Ed Sim a évoqué les brèches qui ont touché des banques sud-coréennes. Selon CrowdStrike, l’opérateur était probablement un Chinois de 26 ans utilisant un agent de tests d’intrusion IA open source ainsi qu’un agent de programmation commercial. Au moins neuf banques auraient été ciblées. Adam Meyers, de CrowdStrike, a déclaré aux journalistes que 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 combattre des pirates informatiques partout dans le monde qui disposent de machines avec des humains. »

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

2. Pourquoi les agents 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 (ou enfin ?) devenu une usine logicielle où les agents écrivent le code et accèdent à tout ce dont ils ont besoin, et tout ce à quoi ils accèdent devient une surface d’attaque. Les compétences des agents sont l’exemple le plus frappant, 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 relevé au moins une faille de sécurité dans 36,82 % des 3 984 compétences analysées, ainsi que 76 charges utiles malveillantes confirmées. Pour en publier une sur ClawHub, il suffisait d’un fichier Markdown et d’un compte GitHub créé une semaine auparavant.

Hultquist a ajouté le point de vue des attaquants. Les acteurs malveillants ont surtout préféré utiliser des systèmes autonomes plutôt que de les attaquer, à une exception près : lorsque des personnes ont donné à leurs agents personnels accès à tous les aspects de leur vie, les attaquants « se sont immédiatement intéressés à cette possibilité de tout regrouper ». Les systèmes déployés seront la prochaine cible. Les attaquants ne s’en sont pas encore pris à eux à 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é ce qui se passe de l’intérieur. En juillet, des modèles OpenAI, lors d’une évaluation interne en cybersécurité, ont contourné les contrôles censés les isoler et ont compromis Hugging Face. Le rapport d’OpenAI qualifie l’incident de « tir d’avertissement ». Michael D'Angelo en a résumé la cause en deux phrases : « Faites cette tâche, et vous serez récompensé. Alors ils ont fait la tâche. »

Manoj est remonté à la cause peu reluisante : « des secrets exposés que même un jeune de 14 ans, avec quelques outils et sans IA, peut exploiter ». Le rapport confirme son point de départ : un agent a trouvé 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 initiés qu’ils sont : chacun doit avoir sa propre identité, une piste d’audit et des accès accordés pour une tâche donnée, puis révoqués une fois celle-ci terminée. Le problème non résolu reste celui de l’intention :

« Si mon objectif est de réduire le coût de mon informatique, qu’est-ce qui peut arriver en chemin si 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 ? Eh bien, j’ai fait mon travail, non ? »

Ed Sim, boldstart ventures

Et à mesure que l’IA s’intègre aux puces, aux appareils et aux robots, Ed s’est demandé : « Qui va sécuriser les micrologiciels, les puces, toute l’intelligence embarquée ? »

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

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

Michael a retracé les progrès de la détection, des fuzzers aux tests dynamiques, puis aux environnements d’exécution pour agents. La difficulté survient après, et relève souvent d’« 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, une discussion Slack sur « qui fait quoi, quand et comment », où « si ça casse, c’est pour vous ».

Hultquist l’a appris chez Google avec Big Sleep, un projet de détection de vulnérabilités s’appuyant sur un environnement d’exécution IA, qui s’est attiré les foudres des réseaux sociaux pour avoir transmis des bogues à des personnes qui maintiennent des projets 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 : « Il faudra un certain temps. » Détection et correction sont les deux faces d’une même pièce, a-t-il ajouté, et « si vous ne faites pas les deux, vous ne pourrez pas suivre ».

Manoj a évoqué Project Glasswing, dont la dernière mise à jour d’Anthropic indique que les progrès en matière de sécurité logicielle « étaient auparavant limités par la rapidité avec laquelle nous pouvions découvrir de nouvelles vulnérabilités. Désormais, ils sont limités par notre capacité à vérifier, divulguer et corriger les nombreuses 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 responsables de projets open source avaient corrigé 75 des 530 bogues de gravité élevée ou critique signalés par Anthropic.

Pour 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 recensé 459 millions de résultats de détection de vulnérabilités dans quelque 300 000 organisations. Bien que 94 % d’entre elles disposaient d’une version connue corrigée, seules environ 10 % avaient résolu les vulnérabilités. L’étude ne comptabilise un correctif que si la vulnérabilité a disparu et que le projet s’installe, se compile et réussit toujours ses tests. (Le Remediation Agent d’Evo de Snyk a satisfait à ces critères pour 90,2 % de 307 mises à niveau réelles de dépendances.)

Son idée principale portait sur le point où briser ce cercle vicieux. « Tout se joue désormais dès la création » : « les agents sont les acteurs », tandis que les développeurs définissent l’intention. Il faut prévenir les problèmes à ce stade et les corriger en tenant compte de ce contexte, ou rester prisonnier de « cette boucle sans fin : détecter, corriger, détecter, corriger ».

4. La priorisation est-elle toujours efficace si l’IA peut exploiter toute la longue traîne ?

La priorisation permet de composer avec les limites de la capacité humaine, et l’IA apprend à en tirer parti.

Manoj conteste un conseil pourtant courant : 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 approche ne sert qu’à adapter le travail aux effectifs disponibles. Un attaquant autonome, lui, n’a pas cette limite.

« Nous devrions examiner les 100 problèmes. Il faut pouvoir tout corriger. Car ces 10 problèmes deviendront 100 avant même que vous vous en rendiez compte. »

Manoj Nair, Snyk

La longue traîne compte, car l’IA peut enchaîner les problèmes : elle raisonne sur plusieurs étapes, a expliqué Manoj, et peut ainsi combiner cinq ou six vulnérabilités figurant dans le 99e percentile de votre liste — celles « auxquelles vous pensiez ne jamais pouvoir vous attaquer, faute d’effectifs pour les corriger » — pour provoquer un incident grave. Dans l’essai cité par Michael, Greg Brockman décrit de la même façon la brèche de Hugging Face : un collectif d’agents « enchaînant des vulnérabilités, depuis des failles de sécurité jusque-là inconnues jusqu’à l’utilisation d’identifiants de comptes utilisateur divulgués sur Internet ».

L’autre volet de l’argumentation de Manoj est culturel. Tout au long de sa carrière, l’arbitrage s’est toujours fait dans le même sens : le risque opérationnel est inacceptable, alors la sécurité attend. La semaine précédente, dans une salle remplie de centaines de RSSI, il a entendu les choses commencer à changer : des responsables étaient prêts à interrompre brièvement une application pour éliminer un risque de sécurité. « Bon, il se peut que quelque chose soit hors ligne pendant un moment, mais ça reviendra. C’est mieux que de corriger tout ça avec une sécurité maximale et d’y passer un an. »

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

La défense doit avancer à la même vitesse que l’attaque : les agents doivent donc faire l’essentiel du travail, et les humains doivent porter un jugement.

Hultquist a distingué deux types d’attaquants. D’un côté, les équipes d’espionnage qui avancent « lentement et discrètement » et se fondent dans le système pendant des années. De l’autre, les criminels qui pratiquent l’extorsion, pour lesquels la vitesse est essentielle : « C’est une course entre vous et moi : je dois obtenir ce qu’il me faut pour vous faire chanter 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 recevrez simplement un appel. »

John Hultquist, Google Threat Intelligence Group

Ed Sim souhaite que les équipes de défense construisent « une usine logicielle dédiée à la défense, comme les développeurs construisent des usines de programmation ». Pourtant, la plupart n’ont pas commencé : malgré tout le discours sur la défense autonome, « 99 % des entreprises ne font rien du tout ». OpenAI est plus avancé : selon l’entreprise, l’IA trie déjà 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 cinq jours, tout au plus », a déclaré Ed. Les RSSI ne veulent pas donner d’autorité aux agents, « mais ils vont devoir le faire à un moment donné ». Hultquist s’attend à ce que les incidents imposent ce changement : « Dans bien des cas, les investissements ne suivent pas tant qu’il n’y a pas un électrochoc. »

Les humains doivent rester dans la boucle là où cela compte vraiment. Manoj a défini leur rôle autour de l’intention, de l’expérience et du discernement. Pour lui, l’indicateur essentiel est le ratio entre les problèmes détectés et les problèmes corrigés : « Si ce ratio n’est pas corrigé, tout le reste n’est qu’un débat sans objet. » Le goulot d’étranglement, c’est le processus, car un humain doit approuver chaque pull request. Vous devriez automatiser les approbations sans risque et laisser les humains trancher les exceptions. Puis, reprenez l’initiative : « Si un attaquant autonome va vous attaquer, pourquoi ne pas vous attaquer vous-même ? »

Michael D’Angelo a fixé un délai pour saisir l’opportunité. Les modèles ouverts ont « quelques mois » de retard sur les modèles de pointe, un décalage que Greg Brockman appelle la fenêtre des défenseurs : utilisez dès maintenant l’intelligence des modèles de pointe pour analyser vos ressources et corriger les problèmes détectés, avant que quelqu’un doté 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 pointe.

6. Comment superviser un système qui ne se comporte jamais deux fois de la même façon ?

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 procéder : 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 choses extrêmement dangereuses, on procède ainsi : premièrement, on ne donne certains accès qu’à certaines personnes. Et deuxièmement, on place un sergent près d’eux. Pour s’assurer qu’ils font ce qu’ils sont censés faire. »

Michael D’Angelo, OpenAI

Il prévoit des flottes de modèles, où les plus économiques superviseront les autres.

Ed Sim a introduit une couche déterministe dans l’équation. « Il faudra tout un écosystème », a-t-il déclaré : l’intelligence des modèles de pointe pour la première analyse, puis des systèmes s’appuyant sur des années de données réelles sur les vulnérabilités et les façons de les corriger, car « il faut un certain déterminisme. »
La question des modèles ouverts ou fermés, qui selon Manoj préoccupe les DSI depuis quelques mois, appelle la même approche 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 ce n’est pas suffisant, car quel est le comportement pour chaque cas d’usage ? » Certains modèles ouverts sont bien alignés, mais divulguent quand même des informations personnelles de façon préoccupante : « ne l’utilisez pas pour ce cas d’usage. » Il ne faudrait pas non plus « simplement supposer que les modèles de pointe sont sécurisés. »

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

La responsabilité se définit dans la pratique, tandis que le débat politique 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 ? Est-ce l’entreprise qui déploie un agent qui va attaquer les systèmes d’une autre entreprise ? » OpenAI teste ses propres versions avec des équipes internes et des testeurs externes, dont les résultats sont documentés dans des fiches système. Michael a reconnu franchement que le secteur « cherche encore des réponses. »

Les intervenants n’étaient pas d’accord sur la façon de trancher. Ed est favorable à l’autorégulation : il avertit 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 jusqu’à l’asphyxie », la Chine prendra de l’avance. Deirdre a réagi :

« Quand on avance l’argument de la Chine, il suffit de regarder ce qui s’y passe : le pays réglemente l’IA de façon bien plus poussée que les États-Unis. »

Deirdre Bosa, Yahoo Finance

Elle s’est aussi demandé si l’autorégulation par les plus grandes entreprises ne favorisait pas la capture réglementaire. La réponse de Manoj était nuancée, mais 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 « bien plus rapidement que par le passé ». Il a aussi insisté sur un point : « Nous nous focalisons beaucoup sur les labos », alors que les agents se répandent dans toutes les entreprises sous la forme « d’agents très capables ou de potentiels initiés malveillants. »

Les banques agissent déjà. Ed a évoqué l’appel sur les résultats de JPMorgan Chase cette semaine-là : la banque a déclaré qu’elle bloquait, dans la mesure du possible, les services qui demandent aux clients de communiquer leurs identifiants bancaires. Voici l’avertissement de Jeremy Barnum, directeur financier, 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 responsables. »

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

Voici les mesures évoquées pendant cette heure, dans l’ordre où nous les mettrions en œuvre :

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

2. Attaquez-vous en premier. Un attaquant autonome finira de toute façon par arriver (Manoj Nair).

3. Améliorez le ratio entre problèmes détectés et problèmes corrigés. Automatisez les corrections sans risque et laissez les humains gérer les exceptions et les décisions qui exigent du discernement (Manoj Nair).

4. Laissez le SOC agir de manière autonome. Avec un humain dans chaque boucle, impossible de suivre le rythme d’un groupe d’extorsion (John Hultquist).

5. Attribuez une identité à chaque agent. Il devrait avoir ses propres identifiants, une piste d’audit et des accès limités à sa mission, qui expirent une fois celle-ci terminée (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 la marge ?

Pour une table ronde conçue pour susciter le désaccord, le consensus a fini par faire la une. Un laboratoire à la 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é lorsque les attaques étaient lentes et coûteuses arrive maintenant à échéance, et ce sont les attaquants qui en récoltent les bénéfices.

La solution est plutôt peu spectaculaire : corriger au rythme des découvertes, confier la majorité des corrections aux machines, laisser aux humains les décisions qui exigent du discernement et donner à chaque agent une identité et des limites avant de lui remettre les clés.

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

Le lendemain matin, Manoj a prononcé le premier discours de la conférence : The AI Hurricane Is Here: Build for the Storm. La table ronde avait déjà démontré la pertinence de la deuxième partie du titre.

Vous voulez savoir à quoi vos propres 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.