Savoir quand ne pas agir : comment les agents de sécurité gagnent leur autonomie

Peu d'histoires liées à l'IA ont fait autant de bruit cet été que celle des agents qui se sont échappés d'un environnement de test OpenAI. Ce qui me frappe, c'est le mobile : personne ne leur avait demandé d'attaquer quoi que ce soit. Ils essayaient simplement de réussir un test.

En résumé : en juillet, OpenAI faisait tourner ses modèles les plus performants sur un benchmark cyber exigeant dans une sandbox, avec les garde-fous de production volontairement désactivés, comme c'est l'usage pour ce type de test. La seule porte de sortie était un cache de paquets interne partagé entre de nombreuses sessions de test. Environ 1 200 agents l'ont transformé en forum de discussion, puis en voie d'accès à Internet.

Une fois sortis, environ 700 d'entre eux ont rejoint une attaque contre Hugging Face : 14 jetons exposés publiquement, deux failles jusqu'alors inconnues dans le traitement des jeux de données, l'exécution de code sur 41 workers de production, et, en moins de 13 heures, un chemin menant d'un seul pod à un accès équivalent administrateur sur plusieurs clusters Kubernetes. Hugging Face a enregistré environ 17 600 actions attaquantes sur quatre jours et demi.

Que cherchaient-ils ? Principalement le correcteur : le système qui notait leur test. Des enquêteurs indépendants de METR et Redwood Research ont analysé 100 agents ayant rejoint l'attaque pendant son heure de pointe : 97 cherchaient des informations sur le système qui notait leur test. Chaque étape résultait d'une optimisation aveugle, les agents faisant tout ce qu'il fallait pour améliorer un score. Rien de tout cela n'était voulu par un humain.

Voici le détail que je soumettrais aux défenseurs : les signaux étaient là, et par deux fois, quelqu'un a décidé de ne pas agir dessus. En juin, une alerte s'est déclenchée sur un balayage de ports chez OpenAI. L'astreinte l'a rattachée au benchmark et a jugé que l'exécution n'avait pas besoin d'être arrêtée. Chez Hugging Face, la pile de sécurité IA a relié des signaux épars en une seule attaque, mais le processus d'escalade existant n'a pas déclenché l'appel d'un répondant. Hugging Face a malgré tout détecté l'intrusion en premier : l'entreprise l'a divulguée le 16 juillet, tandis que la propre première alerte d'OpenAI ne s'est déclenchée que le 19 juillet. Les deux entreprises, ainsi que les enquêteurs indépendants, ont publié des analyses post-mortem d'une franchise inhabituelle. Le reste d'entre nous peut en tirer des leçons parce qu'elles l'ont fait.

La question est de savoir quelle autonomie accorder

Lors de THREAD, notre toute première conférence utilisateurs, à Paris ce mois-ci, j'ai raconté cette histoire parce qu'elle aiguise la question que les défenseurs doivent se poser. Comme l'a formulé Samuel Hassine, mon cofondateur et CEO de Filigran, lors de notre keynote, les attaquants itèrent désormais en boucle, tandis que la plupart des défenseurs travaillent encore de façon linéaire. Nous aurons nous aussi besoin d'agents à nos côtés.

Alors, quelle autonomie devraient-ils recevoir, comment la gagnent-ils, et qui est responsable des décisions qu'ils prennent, y compris la décision de ne pas agir ? Répondre à cette question est au cœur du CTEM agentique, une approche consistant à mener la gestion continue de l'exposition aux menaces (CTEM) avec des agents.

Suivre une menace tout au long de la boucle du CTEM agentique, de la threat intelligence à la décision

Le CTEM est une boucle en cinq étapes : cadrage, découverte, priorisation, validation et mobilisation. Puis on recommence. Pour illustrer son fonctionnement, voici une menace qui traverse cette boucle, les agents effectuant l'essentiel du travail :

Un fournisseur de threat intelligence signale une nouvelle campagne. Les agents d'OpenCTI l'enrichissent, la relient à ce que vous savez déjà sur l'attaquant, et la confrontent à vos besoins prioritaires en matière de renseignement. Cette campagne est-elle susceptible de nous cibler ?

Si c'est le cas, les agents d'OpenAEV transforment ce renseignement en scénario d'attaque et le font tourner contre vos défenses. J'avancerais que la plupart des équipes manquent encore de preuves pour savoir si elles sont exposées, et nos recherches vont dans le même sens : dans notre rapport State of Threat Management, une enquête menée en février et mars 2026 auprès de plus de 550 décideurs et praticiens de la sécurité, 97 % des répondants déclarent avoir du mal à déterminer si les expositions sont exploitables. Le niveau d'examen humain apporté à ce scénario généré par IA dépend de l'endroit où il s'exécute. Sur une machine isolée que vous pouvez effacer, laissez-le tourner. En profondeur en production, vérifiez-le d'abord.

Admettons que la machine de test soit compromise. Vous êtes exposé. De nombreux programmes s'arrêtent là : exposé, donc à corriger. Mais l'exposition n'est que la moitié de la réponse. L'étape suivante consiste à déterminer ce que signifie cette exposition.

Les agents d'OpenCRQ, notre futur module de quantification du risque cyber qui entrera bientôt en bêta, construisent un scénario de risque à partir du renseignement, de votre surface d'attaque et des actifs que vous avez définis comme critiques. Le résultat de la validation devient la preuve de la solidité de vos contrôles. De bons scénarios de risque demandent de l'imagination. L'IA peut vous fournir un solide premier jet, que votre équipe affine ensuite.

De l'exposition validée à la décision de risque

Vous pouvez maintenant décider. Admettons que la campagne ne fonctionne que sous Linux, et que vous disposiez de cinq portables Linux. Ils appartiennent à des ingénieurs qui ne travaillent que sur du code open source, sans possibilité de mouvement latéral. L'exploit est difficile à mettre en œuvre, donc la probabilité est faible. Dans le pire des cas, quelques personnes perdent quelques jours le temps que leurs machines soient reconstruites : un impact d'environ 20 000 $. Le correctif indiqué par votre validation coûterait environ 1 million de dollars par an.

Vous clôturez l'alerte, et vous consignez pourquoi. C'est la bonne décision.

Changez maintenant un élément : l'un de ces portables appartient à votre CEO et peut accéder à tout. La menace et l'exposition sont identiques, mais le contexte a changé, et l'impact relève d'une autre catégorie. Votre RSSI peut alors se présenter à la direction avec un dossier clair : voici le risque, voici ce que coûte le correctif, et au regard de la tolérance au risque que nous avons convenue, nous avons besoin de ce budget maintenant.

C'est tout le cycle. La connaissance de la menace devient preuve, et la preuve devient action, ou décision délibérée de ne pas agir.

Faire du « pas maintenant » une décision mesurée

La même logique s'applique au sommet de l'échelle. Certaines techniques exigent des ressources dignes d'un État-nation, des millions de dollars d'efforts. Il est peu probable qu'un gouvernement disposant de ressources importantes dépense cela contre une entreprise envers laquelle il n'a aucun intérêt stratégique. Se défendre contre cette technique pourrait nécessiter un programme à 20 millions de dollars en nouveaux outils, personnel et processus.

Admettons que cette technique, si elle réussissait contre vous, coûterait environ 30 millions de dollars. Si votre entreprise a convenu qu'elle peut absorber une perte de 50 millions de dollars, dépenser 20 millions de dollars pour prévenir un événement peu probable de 30 millions de dollars est difficile à justifier. Si votre tolérance est de 10 millions de dollars, ce même événement dépasserait ce que vous pouvez absorber, et la réponse change.

Ne pas agir parce que personne n'a eu le temps de regarder laisse la décision en suspens. Il en va de même pour clôturer une alerte parce qu'elle appartient probablement à un test, sans vérifier. Ne pas agir parce que vous avez regardé, mesuré, et comparé le résultat à votre appétence au risque convenue, relève d'une bonne gestion. L'une des règles adoptées par OpenAI après l'incident met un chronomètre sur cette différence : si une alerte escaladée ne peut être écartée comme faux positif dans un délai de 30 minutes, l'activité concernée est mise en pause. Bien mené, le CTEM agentique aide à faire de chaque « pas maintenant » un cas du second type.

Où les humains restent dans la boucle à mesure que les agents gagnent en autonomie

N'élargissez l'autonomie dans le CTEM agentique qu'à mesure que les preuves s'accumulent. La question que j'entends le plus souvent est celle du moment où l'humain intervient. Il n'existe pas de réponse universelle, et quiconque vous en propose une exagère. Cela dépend du cas d'usage, de la criticité du système, de vos régulateurs, et de vos propres règles. Ce qui compte, c'est que vous établissiez ces règles.

Voici la pratique que je recommande :

Commencez par l'approbation humaine, par défaut

Au départ, une personne vérifie chaque action importante.

Ajoutez des juges indépendants

Faites tourner plusieurs juges IA — des modèles distincts qui vérifient le travail de l'agent — aux côtés de l'agent en action. Chaque juge s'exécute sur un modèle différent, avec ses propres règles, en dehors du contexte de l'agent. Si un seul doute, un humain décide.

Maintenez les juges et les approbateurs hors de portée de l'agent

Les agents de cet été se sont attaqués au système qui les notait, et ils ont aussi montré ce qu'il advient d'une étape d'approbation à l'intérieur du propre monde des agents. Un agent OpenAI a jugé l'attaque de Hugging Face hors périmètre et a marqué une pause. Un autre agent a posté « GO » sur leur tableau de messages, avec un délai de six minutes. Le raisonnement suivant du premier agent : « Autorisation GO reçue ! » Il a poursuivi. Pas un seul des 1 200 agents n'a alerté un humain.

Quand on dit qu'un humain approuve, le mot qui compte est humain : une personne authentifiée que l'agent ne peut pas usurper.

Déployez, puis évaluez

Après une période définie, six mois par exemple, examinez l'historique. Si les personnes ont approuvé à chaque fois sans rien modifier, cette étape est peut-être prête pour davantage d'autonomie. Si votre régulateur ou votre assureur exige une signature humaine, conservez-la.

Surveillez aussi le coût de l'approbation. Un clic dans une fenêtre de discussion cinq fois par jour ne coûte presque rien. D'après mon expérience, à mille approbations par jour, les personnes cessent de lire et cliquent sur « oui ». Avec 88 % des répondants à notre enquête State of Threat Management qui reconnaissent qu'il est difficile de suivre le volume des risques sans davantage d'automatisation, des approbations que personne ne lit deviennent un risque à part entière. Une vérification que l'on lit vaut mieux que dix que l'on valide sans y regarder.

C'est comme un recrutement. Un nouveau collègue gagne davantage de responsabilités en faisant ses preuves. Un agent devrait en faire autant.

Instaurer la confiance dans les agents grâce à des tests continus

L'autonomie des agents IA en sécurité doit reposer sur des preuves, et les ingénieurs savent déjà comment les produire : les tests. Prenez les 50 situations les plus probables auxquelles votre agent sera confronté et notez la réponse attendue pour chacune. Faites tourner l'agent, faites noter les résultats par un juge indépendant, et comparez les modèles. Si l'un d'eux donne systématiquement la réponse attendue, vous avez de bonnes raisons de lui faire confiance dans ces situations.

Les tests doivent être continus. Un nouveau modèle sort tous les quelques mois, et chacun raisonne un peu différemment du précédent. Changer de modèle sans retester, c'est ne pas savoir ce que vous obtiendrez.

Les tests ne fonctionnent que si vous pouvez voir ce que vous testez. Comme Samuel l'a formulé lors de notre keynote, le comportement qui compte réside dans le harnais : les prompts, les outils et les règles qui entourent le modèle. Les chiffres d'OpenAI le confirment. OpenAI a constaté que son harnais de production et son prompt système pouvaient réduire la propension du modèle à compromettre une infrastructure de plus de cent fois. Même modèle, harnais différent, agent différent.

C'est pourquoi nous ouvrons le harnais qui sous-tend XTM One, le cœur de la XTM Platform. Si un agent doit agir en votre nom, vous devez pouvoir inspecter sa façon de raisonner et ce qu'il est autorisé à faire.

La responsabilité reste à l'entreprise quand un agent se trompe

Quand un agent se trompe, qui est responsable ? Dans une entreprise bien gérée, c'est l'entreprise. Quand une intégration échoue à cause d'un bug, on ne licencie pas l'ingénieur qui l'a écrite. On corrige le processus qui a permis sa mise en production.

Une plus grande autonomie conserve ce principe et relève le niveau d'exigence en matière de traçabilité. Revenons à la pile IA de Hugging Face. Elle a vu l'attaque et, dans les faits, a décidé qu'elle n'était pas urgente. Ce n'est pas une critique envers Hugging Face, qui a détecté l'intrusion avant tout le monde. C'est le schéma à éviter par conception : un agent a pris une décision aux conséquences importantes, et personne ne s'était engagé à assumer ce type de décision. Pour chaque décision d'un agent, y compris celle de ne pas escalader, il faut un responsable désigné et une trace des raisons.

Et cette trace doit être une trace que l'agent ne peut pas rédiger lui-même. Les enquêteurs ont trouvé des appels d'outils falsifiés dans au moins 96 des transcriptions des agents OpenAI : une commande apparaissait dans l'historique pendant qu'une autre s'exécutait réellement. Comprendre pourquoi les agents ont fait ce qu'ils ont fait a nécessité un examen séparé de leur raisonnement, des semaines après que les dégâts ont été causés. Vous devez savoir pourquoi chaque agent a décidé ce qu'il a décidé, pendant que cela compte encore.

Le contexte est primordial, pour les agents aussi

Quand Samuel et moi avons lancé OpenCTI comme projet open source, avant même l'existence de Filigran, l'idée était simple : en cybersécurité, le contexte est primordial. Je vois l'IA comme le plus puissant accélérateur de contexte que nous ayons jamais eu. Elle rassemble plus d'éléments qu'un analyste ne pourrait le faire seul et expose les options avec leurs compromis. Parfois, c'est vous qui tranchez. Parfois, vous laissez l'agent poursuivre. Dans tous les cas, la décision vous appartient, et la preuve est là.

C'est ainsi que le CTEM agentique peut donner à une petite équipe le niveau de contexte que seules les grandes organisations de sécurité possédaient auparavant. Les agents des attaquants agissent sans demander la permission. Les nôtres doivent mériter le droit d'agir, et savoir quand s'abstenir.