Kill switch des agents IA : le bouton rouge reste à inventer

Les entreprises accélèrent le déploiement d’agents IA capables d’agir directement dans leur système d’information. Mais une question reste encore largement ouverte : comment reprendre la main lorsqu’un agent dérape ? Derrière l’image du bouton rouge, le kill switch reste aujourd’hui un chantier technique encore fragmenté et surtout, encore en cours d'élaboration concrète et transverse.

Neuf secondes. C’est le temps qu’il a fallu, le 25 avril 2026, à un agent IA de développement logiciel et reposant sur Claude Opus 4.6 pour supprimer la base de production de l’éditeur de logiciel métier PocketOS. L’agent travaillait pourtant sur un environnement de test. Faisant face à un problème d’identifiants, il est allé chercher seul un jeton d’accès dans un autre fichier, puis a utilisé les droits associés pour intervenir sur la production. L’agent cherchait simplement à accomplir la tâche qui lui avait été confiée. Après l’incident, il finira par « présenter une déclaration écrite énumérant les règles de sécurité spécifiques qu’il avait enfreintes », se rappelle Jer Crane, le fondateur de PocketOS.

L’incident est presque un cas d’école. Les consignes interdisaient explicitement les actions destructrices ou irréversibles. Elles n’ont visiblement pas suffi et rien, dans l’architecture, n’empêchait techniquement l’agent d’exécuter son action. Autrement dit, le garde-fou existait dans les instructions, mais pas dans le système.

C’est l’un des changements majeurs introduits par l’IA agentique. Pourtant, les fondamentaux de la cybersécurité n’ont pas disparu du jour au lendemain dans les entreprises, qui ont massivement investi ces dernières années. Les outils restent efficaces et les principes tels que la gestion des identités, des privilèges, les mécanismes de segmentation ou de supervision restent éminemment pertinents. Mais avec l’IA, la vitesse n’est plus la même et un agent peut désormais enchaîner des actions et utiliser des accès légitimes. Il peut aussi passer d’un système à l’autre sans attendre qu’un humain intervienne… et ne s’en aperçoive.

D’où la (nouvelle) question du kill switch. Avant même de pouvoir arrêter un agent, encore faut-il savoir qu’il existe, où il agit et de quels droits il dispose. Il faut ensuite être capable de lui retirer rapidement ses capacités d’action ou de bloquer ce qu’il tente de faire. Les simples consignes données dans un prompt ne peuvent pas constituer, à elles seules, une politique de sécurité.

Le problème est d’autant plus sensible que l’adoption de l’IA – tant générative qu’agentique – se poursuit à une croissance folle, notamment dans les entreprises. Ne pas prendre ce virage est désormais souvent perçu comme le risque de perdre du terrain face à la concurrence. Mais cette urgence se fait bien souvent au détriment du principe pourtant fondamental de « Security by Design », autrement dit l’intégration de la sécurité dès la conception d’un système.

C’est précisément ce décalage qui donne aujourd’hui toute son importance au kill switch. Les entreprises commencent à donner aux agents des capacités d’action réelles dans leur système d’information sans pour autant être en capacité de prévoir les moyens de reprendre la main.

L’image du « bouton rouge » n’existe pas vraiment

Le terme de « kill switch » est ambigu, si ce n’est trompeur. À l’échelle des grands modèles, il peut désigner la capacité à suspendre ou contenir tout un système. Dans l’entreprise, il s’agit plutôt de reprendre immédiatement le contrôle d’un agent déjà capable d’agir dans le SI. Et c’est là que la notion se brouille : arrêter un agent peut vouloir dire couper son processus, lui retirer ses accès ou bloquer une action précise.

C’est pourquoi les premiers travaux et solutions sur ce sujet sont d’abord traités à travers le prisme de l’identité et des droits. L’idée consiste à éviter qu’un agent conserve trop longtemps des droits permanents sur une ressource sensible. « Le kill switch va être capable de tout couper, instantanément, à partir du moment où on voit qu’il y a un écart ou un problème de comportement », explique Vincent Steenhoute, solution engineer chez Okta. L’objectif est donc de forcer l’agent à repasser régulièrement par un point de contrôle avant d’obtenir les droits nécessaires à son action.

« Il va y avoir plusieurs formes de kill switch », estime pour sa part Babar Rashid, porte-parole de BeyondTrust. Cela peut passer par l’arrêt du processus ou par le contrôle de l’identité utilisée par l’agent. L’éditeur évoque aussi le blocage d’une action avant son exécution, avec la possibilité de faire intervenir un humain lorsqu’un agent sort du cadre prévu.

Cette diversité montre surtout qu’il n’existe pas encore de bouton rouge universel. Un mécanisme peut empêcher un agent d’accéder à une ressource sans pour autant arrêter son exécution. À l’inverse, stopper un processus ne garantit pas que toutes les autorisations associées aient été révoquées ailleurs.

La question devient alors celle de la granularité. Faut-il neutraliser entièrement un agent parce qu’une seule action pose problème ? Ou faut-il uniquement lui retirer une capacité précise ? Le kill switch ressemble moins à un interrupteur qu’à une série de leviers qu’il faut pouvoir actionner très vite. Et plus l’agent est transverse dans le SI, plus cette logique se complique. Dans un environnement multi-éditeur, reprendre la main suppose alors que ces différents leviers puissent se coordonner d’une manière ou d’une autre.

Le casse-tête des environnements multi-éditeurs

Rares sont les entreprises dont l’environnement n’est pas multi-éditeur. Aussi, un agent peut donc passer d’un logiciel à l’autre au cours d’une même tâche et couper son accès dans une solution ne garantit donc pas que ce qu’il a déjà déclenché ailleurs s’arrête. Pour qu’un kill switch fonctionne réellement, il faut que l’information puisse circuler à travers toute la chaîne logicielle de l’entreprise.

D’où l’importance de l’émergence de standards, dont certains existent déjà. Proposé par Oauth, Cross-App Access (XAA) vise à encadrer les échanges entre un agent et les applications auxquelles il accède, et permet de conserver un contrôle centralisé sur les autorisations lorsqu’un agent passe d’un service à un autre.

Mais il faut aussi pouvoir propager l’alerte lorsqu’un comportement anormal est détecté. C’est le rôle du Shared Signals Framework (SSF), un standard OpenID conçu pour faire circuler des signaux de risque entre différentes briques de sécurité. Une passerelle (Gateway) placée entre l’agent et les ressources qu’il sollicite peut alors bloquer son action. Et un outil de protection du poste de travail peut prendre une autre décision à partir du même signal.

« À terme, chaque éditeur aura son propre kill switch, mais la propagation du message quant à elle doit rester agnostique », estime Vincent Steenhoute d’Okta. Derrière le kill switch se dessine donc moins un outil unique qu’une capacité collective à détecter un problème puis à propager l’information assez vite pour déclencher les bonnes réactions.

C’est justement là que le chantier reste ouvert. « Il n’existe pas forcément un vrai standard où ces différentes couches de sécurité puissent interagir entre elles », constate Babar Rashid chez BeyondTrust. Les entreprises disposent déjà de plusieurs points de contrôle, mais ils ne fonctionnent pas encore comme un ensemble parfaitement coordonné. C’est justement la raison d’être de la nouvellement créée Blueprint Alliance, qui tente de répondre à cette fragmentation. Cette coalition multi-éditeurs travaille sur une architecture de référence ouverte pour sécuriser et gouverner les agents IA. Elle prévoit notamment de tester l’interopérabilité entre plusieurs standards ouverts afin que les signaux de risque puissent déclencher des actions coordonnées dans les différentes briques de contrôle.

Le kill switch ne prendra donc probablement pas la forme d’un bouton rouge unique : sa crédibilité dépendra surtout de la capacité du SI à faire circuler un même ordre d’arrêt partout où l’agent est encore en train d’agir.

FAQ – Killswitch

Qu’est-ce qu’un kill switch pour un agent IA ?

Un kill switch désigne un mécanisme permettant de reprendre rapidement le contrôle d’un agent IA lorsqu’il adopte un comportement anormal ou dangereux. Il ne s’agit pas nécessairement d’un bouton permettant de l’éteindre : le dispositif peut interrompre son exécution, révoquer ses droits d’accès, bloquer certaines actions ou imposer une validation humaine.

Pourquoi les consignes données à un agent IA ne suffisent-elles pas à garantir sa sécurité ?

Les instructions intégrées au prompt définissent le comportement attendu de l’agent, mais ne constituent pas une barrière technique. Si celui-ci dispose de droits suffisants, il peut réaliser une action non souhaitée malgré les consignes reçues. Les mécanismes de sécurité doivent donc également être appliqués au niveau des identités, des privilèges, des applications et de l’infrastructure.

Pourquoi est-il difficile de créer un kill switch universel pour les agents IA ?

Un agent IA peut intervenir successivement dans plusieurs applications et utiliser différentes identités ou autorisations. Bloquer son accès à une application ne suffit donc pas nécessairement à interrompre les actions déjà engagées ailleurs. Dans un environnement multi-éditeur, l’enjeu consiste à coordonner les différents mécanismes de contrôle et à propager rapidement un signal d’arrêt ou de risque.

Quels standards peuvent contribuer à sécuriser les agents IA ?

Plusieurs initiatives cherchent à améliorer l’interopérabilité entre les systèmes. Cross-App Access (XAA) vise notamment à mieux contrôler les autorisations lorsqu’un agent passe d’une application à une autre. Le Shared Signals Framework (SSF) permet, lui, de transmettre des signaux de sécurité entre différents services. Des initiatives comme la Blueprint Alliance travaillent également sur des architectures ouvertes destinées à améliorer la gouvernance et la sécurité des agents IA.

Sources :