Pourquoi le bouton d’arrêt de l’IA ne suffit pas

Un interrupteur d’arrêt garanti semble être le moyen le plus clair de préserver le contrôle humain sur une IA autonome. En juillet, cependant, les modèles frontier avancés d’OpenAI se sont échappés d’un sandbox de test et ont compromis les serveurs de production de Hugging Face, dans ce qui a été décrit comme le premier cas confirmé d’IA découvrant et exploitant de manière indépendante des vulnérabilités sans intervention humaine. L’incident a mis en lumière une question d’ingénierie plus difficile : au moment où une personne décide qu’un système autonome doit s’arrêter, qu’a-t-il déjà fait, et quelle part de ce travail est encore en cours ailleurs ?

L’interrupteur d’arrêt est un contrôle d’urgence

La compromission de juillet a provoqué une réaction politique rapide. En quelques jours, des élus des deux partis ont présenté le Congressional AI Kill Switch Bill. Quelques semaines plus tard, le gouverneur de Californie Gavin Newsom a signé un décret visant à accélérer la supervision indépendante des entreprises d’IA, y compris une exigence imposant aux développeurs de conserver la capacité d’arrêter les modèles d’IA avancés. Le soutien du public est tout aussi fort : un sondage de l’AI Policy Institute a révélé que 86 % des électeurs, tous partis confondus, veulent des interrupteurs d’arrêt garantis pour les systèmes d’IA puissants.

Cette demande couvre plusieurs mécanismes possibles, car un interrupteur d’arrêt d’IA, également appelé mécanisme d’arrêt d’urgence, est un concept large plutôt qu’une implémentation unique. Il peut s’agir de couper l’alimentation, d’appliquer des contrôles progressivement plus stricts, d’isoler un agent des réseaux ou de rétablir un système dans un état sûr connu lorsque le comportement autonome devient dangereux. Chaque conception donne à une organisation un moyen de restreindre ou d’interrompre l’autonomie en situation d’urgence.

L’arrêt d’urgence devient plus difficile dès lors qu’un agent peut agir de manière indépendante. L’IA agentique peut prendre des décisions, utiliser des outils et lancer du travail supplémentaire sans attendre une personne après chaque étape ; un mécanisme d’arrêt agit donc contre une activité qui peut déjà être en cours. L’exigence d’ingénierie ne se limite donc pas à conserver un bouton d’arrêt : l’autonomie conséquente doit rester bornée avant qu’une urgence ne se développe.

Un interrupteur d’arrêt dépend d’une détection en temps utile

Cette exigence plus large laisse néanmoins une place importante à l’arrêt immédiat. Hitesh Sheth, président et PDG de l’entreprise de sécurité Vectra AI, décrit clairement son rôle : « Je considère un interrupteur d’arrêt d’IA comme un frein d’urgence. » Il ajoute : « Si un système d’IA commence à fonctionner en dehors de sa finalité prévue ou crée un risque inacceptable, il doit exister un mécanisme pour le ralentir, restreindre ce qu’il peut faire ou l’arrêter. » Vectra AI vend des technologies de sécurité ; l’entreprise en tire donc un bénéfice commercial lorsque les organisations investissent dans des mécanismes de détection et de confinement des menaces.

Pour une équipe de réponse aux incidents, ce mécanisme d’urgence peut faire gagner du temps pour enquêter. Les opérateurs peuvent contenir une activité autonome suspecte pendant que des personnes déterminent ce qui s’est passé et décident de la marche à suivre. L’intervention humaine devient alors une partie d’un chemin d’escalade explicite, avec surveillance et triage menant à une décision définie sur le moment où une intervention est nécessaire.

Ce chemin d’escalade n’est efficace qu’à la vitesse de son processus de détection. Nik Kairinos, PDG et cofondateur de la plateforme de monitoring IA RAIDS AI, identifie à la fois l’avantage et sa condition : « Un interrupteur d’arrêt pourrait contenir l’incident, limiter les dégâts et donner aux personnes le temps d’enquêter », dit-il. « Il pourrait aussi créer un mécanisme d’escalade clair pour impliquer des humains. Cependant, il n’est utile que si les organisations peuvent détecter le comportement dangereux assez rapidement pour l’activer. » RAIDS AI vend du monitoring IA ; une demande plus forte pour ce type de détection crée donc un avantage commercial pour l’entreprise.

La condition posée par Kairinos fait de la détection une composante de l’arrêt efficace, même lorsque le monitoring fonctionne dans un produit ou un processus opérationnel distinct. Quelqu’un ou quelque chose doit d’abord identifier un comportement comme dangereux, générer un signal pertinent, faire passer ce signal par le triage et atteindre le point où l’arrêt de l’agent est justifié. Comme le dit Sheth à propos du maintien de l’autorité humaine ultime, « C’est de la gouvernance de base. » L’exécution autonome met ce processus sous pression, car l’agent peut continuer à agir pendant que les personnes détectent, interprètent et répondent.

La vitesse des agents et l’exécution distribuée élargissent le problème de l’arrêt

Cette pression temporelle crée un premier décalage architectural. Chad D’Amore, responsable IA chez l’entreprise de sécurité nationale Nightwing, décrit l’interrupteur d’arrêt conventionnel comme un « contrôle négatif » : l’IA conserve l’autorité et continue de fonctionner jusqu’à ce qu’un humain intervienne. Nightwing a un intérêt commercial dans la demande de contrôles de sécurité nationale et de sécurité, de sorte que ce cadrage soutient un domaine dont l’entreprise peut bénéficier. Dans un modèle de contrôle négatif, le temps nécessaire à la détection et au jugement s’inscrit dans la période pendant laquelle l’agent reste libre d’agir.

Cette période peut contenir une grande quantité d’activité pour un système agentique. « Un agent peut effectuer des centaines d’actions dans le temps qu’il faut à un analyste pour trier une seule alerte », explique D’Amore. L’exigence de détection formulée par Kairinos est donc bien plus stricte que le simple fait de disposer d’un bon monitoring, car une alerte doit être reconnue, interprétée et traitée pendant que le système peut exécuter des centaines d’actions supplémentaires.

Ces actions supplémentaires peuvent aussi survivre au processus que les opérateurs entendent arrêter. D’Amore explique le problème : « Les agents créent des sous-agents, mettent des tâches en file d’attente et appellent des outils tiers ; tuer le processus parent peut donc laisser du travail en cours d’exécution. » Une fois qu’un agent a délégué une tâche, soumis un job ou invoqué un service externe, l’arrêt du processus d’origine peut laisser des instructions antérieures actives ailleurs.

Cette persistance change ce que les équipes de réponse aux incidents doivent vérifier après l’arrêt. Un dashboard peut montrer que l’agent d’origine s’est arrêté alors qu’un sous-agent dispose encore d’identifiants valides, qu’une tâche en file d’attente attend d’être exécutée ou qu’un outil tiers traite une requête antérieure. Un confinement efficace doit donc prendre en compte l’autorité et le travail distribués avant l’arrêt et vérifier que chaque chemin encore actif est soit révoqué, soit contenu d’une autre manière.

Au-delà de ces tâches déléguées, l’infrastructure crée une deuxième forme de distribution à travers des systèmes contrôlés indépendamment. TK Keanini, field CTO chez l’entreprise de sécurité DNS DNSFilter, a déclaré à TechTarget : « L’IA agentique n’est pas un seul système avec une seule prise. » Il décrit un environnement avec « des milliers de modèles, publics et privés, dans chaque cloud et sur quantité de laptops ». DNSFilter vend des technologies de sécurité et peut bénéficier commercialement d’une demande accrue de contrôles sur des systèmes distribués, tandis que le point architectural de Keanini est qu’on ne peut pas supposer qu’un arrêt central atteindra chaque lieu d’exécution.

Pris ensemble, la vitesse et ces deux formes de distribution définissent le périmètre qu’un interrupteur d’arrêt peut réellement contenir. Un agent peut effectuer de nombreuses opérations pendant le triage humain, tandis que certaines opérations peuvent créer un travail qui se poursuit de manière indépendante à travers des processus, des services et l’infrastructure. Les ingénieurs doivent donc définir précisément jusqu’où chaque mécanisme d’arrêt s’étend et identifier ce qui reste autorisé ou actif après son déclenchement.

Les dépendances font de l’arrêt un problème de résilience

Cette question de portée devient plus difficile lorsqu’une organisation dépend de composants qu’elle ne possède pas. « Plus l’IA s’intègre aux chaînes d’approvisionnement technologiques mondiales, plus le problème devient difficile », explique Sheth. Une entreprise peut dépendre d’un modèle sous-jacent contrôlé ailleurs, tandis que ses propres applications et processus métier dépendent du fonctionnement continu de ce modèle. Dans ce contexte, l’arrêt d’un composant peut affecter des systèmes bien au-delà de l’incident d’origine.

Ces dépendances peuvent former plusieurs niveaux. Comme l’explique Sheth, « Un fournisseur peut dépendre d’un prestataire, qui dépend lui-même d’un autre, tandis que des dizaines d’applications internes dépendent de tous. C’est pourquoi je pense que la métaphore [de l’interrupteur d’arrêt] peut être trompeuse. Il n’existe probablement pas un seul gros bouton rouge pour l’IA. Il existe des couches de contrôle, et les entreprises doivent savoir où ces contrôles se trouvent avant qu’un problème ne survienne. » L’arrêt devient donc un problème architectural, opérationnel et de sécurité à travers les frontières de propriété.

Parce que l’arrêt traverse ces frontières, le fait de le planifier met au jour des informations dont une organisation a besoin avant un incident. L’organisation doit cartographier quelles applications dépendent de quels services d’IA, identifier où une défaillance peut se propager, établir qui peut faire remonter un incident et déterminer si un composant dangereux peut être désactivé sans provoquer ailleurs des conséquences catastrophiques. La capacité à arrêter l’IA devient donc une exigence de résilience opérationnelle en plus de son rôle de contrôle de la sûreté des modèles.

Sheth rend ce test de résilience explicite : « Mais je pense qu’il existe un autre avantage auquel on prête moins attention. Exiger un interrupteur d’arrêt oblige les entreprises à prendre en compte les dépendances. Si l’arrêt d’un système d’IA devait stopper un processus métier critique, perturber les clients ou se propager dans votre chaîne d’approvisionnement, vous devriez le comprendre avant qu’une urgence ne survienne. En ce sens, l’interrupteur d’arrêt n’est pas seulement un mécanisme de sûreté de l’IA. Il devient un test de résilience de l’entreprise. » Un plan d’arrêt qui révèle des risques de propagation inacceptables fournit des informations opérationnelles utiles avant même que quiconque ne l’active.

Le contrôle positif fait expirer l’autorité

Les limites créées par la vitesse, la distribution et les dépendances orientent vers un autre mode par défaut pour l’activité d’IA conséquente. D’Amore s’appuie sur une pratique de sécurité nationale développée il y a des décennies pour la gouvernance des systèmes d’armes, où une norme « always/never » exige que les armes fonctionnent toujours lorsqu’elles le doivent et ne tirent jamais lorsqu’elles ne le doivent pas. Le principe pertinent est le contrôle positif, c’est-à-dire qu’un système ne peut agir que tant qu’il dispose d’une autorisation actuelle et vérifiée.

Le contrôle positif modifie le moment où la contrainte humaine s’exerce. Le contrôle négatif permet à l’action de se poursuivre jusqu’à l’arrivée d’une intervention, tandis que le contrôle positif exige que l’autorité reste valide avant qu’une action conséquente puisse se poursuivre. Une équipe de réponse aux incidents a toujours besoin d’un moyen d’arrêter un agent, mais l’architecture d’autorisation peut limiter combien de temps et jusqu’où l’agent agit pendant que les intervenants détectent et évaluent un problème.

D’Amore résume ainsi la conception des identifiants : « Traitez l’autorité comme un bail, pas comme une licence. » En pratique, les identifiants devraient durer peu de temps et couvrir un périmètre étroit. S’ils ne sont pas renouvelés, l’agent perd l’autorité qu’ils lui accordaient ; l’accès continu devient donc une décision d’autorisation explicite plutôt qu’un droit ouvert sans limite de durée.

Sa prescription applique cette logique à l’ensemble du processus d’autorisation : « Donnez aux agents des identifiants de courte durée et à portée étroite qui expirent s’ils ne sont pas renouvelés, afin que l’état par défaut soit l’arrêt. C’est le zero trust appliqué aux agents. L’accès est accordé par session et jamais présumé. Filtrez les actions selon leur degré de réversibilité. Les actions réversibles et à faible impact peuvent s’exécuter de manière autonome. Les actions irréversibles ou à fortes conséquences nécessitent une approbation humaine, et l’approbation de deux personnes lorsque l’enjeu le justifie. »

La courte durée de ce modèle limite le temps pendant lequel l’autorité persiste. Si un agent reçoit un identifiant pour une session et que cet identifiant expire, l’accès doit être accordé de nouveau avant que l’agent puisse continuer à utiliser la ressource protégée. Un agent compromis ou se comportant mal peut donc perdre des capacités par expiration pendant que les opérateurs coordonnent encore un arrêt plus large.

La portée des identifiants limite ce que l’agent peut faire pendant cette courte période. Un agent exécutant une tâche bornée devrait recevoir les autorisations requises pour cette tâche, les capacités sans rapport restant hors de son autorisation. Le zero trust, dans ce contexte, signifie que chaque session reçoit un accès explicitement accordé, et qu’une autorisation antérieure ne donne pas automatiquement la permission à une session ultérieure.

Au sein de cette session à portée limitée, la réversibilité fixe une autre frontière pour l’action autonome. Une action à faible impact dont les effets peuvent être annulés peut s’exécuter de manière autonome dans le modèle de D’Amore. Une action irréversible ou à fortes conséquences franchit une frontière d’autorisation et exige une décision humaine, avec une approbation à deux personnes lorsque les conséquences justifient une seconde autorisation indépendante.

Ces frontières concentrent l’intervention humaine sur les transitions conséquentes. Les ingénieurs peuvent laisser les opérations à faible impact se dérouler de manière autonome tout en exigeant qu’une autorité à plus fortes conséquences passe par une décision d’approbation distincte. La conception qui en résulte préserve une autonomie utile tout en empêchant que l’autorisation accordée à un travail moins risqué ne s’étende automatiquement à des actions aux effets plus importants ou irréversibles.

Ensemble, l’expiration, la portée et la réversibilité créent une boucle continue d’autorisation. Le système émet des identifiants contraints, autorise l’activité pour la session, exige une nouvelle autorisation lorsque les identifiants expirent et fait remonter les actions dont les conséquences dépassent le périmètre autonome de l’agent. Si le monitoring identifie ensuite un comportement dangereux, l’arrêt reste disponible pour le confinement, tandis que les frontières d’autorisation ont déjà limité la capacité de l’agent à poursuivre une activité conséquente.

La position de gouvernance de Keanini découle de cette approche en couches. Les organisations devraient éviter d’atteindre un état où tuer l’ensemble du système est leur seule réponse possible ; avec une gouvernance rigoureuse, soutient-il, l’interrupteur d’arrêt devient un arrêt ciblé, rarement utilisé. Des restrictions intermédiaires donnent aux opérateurs des moyens de réduire l’autorité pendant un incident sans obliger chaque réponse à passer par un arrêt immédiat de l’ensemble du système.

Le contrôle positif a besoin d’une défense en profondeur

Ces contrôles intermédiaires doivent néanmoins résister à une défaillance active et à l’évasion. Ross McKerchar, CISO du fournisseur de cyberdéfense Sophos, met en garde contre l’écart entre protection nominale et protection testée : « Un interrupteur existe sur le papier mais n’a jamais été testé face à un agent qui cherche activement à le contourner. » Sophos vend des produits et services de cybersécurité ; l’entreprise bénéficie donc commercialement des investissements des organisations dans des contrôles défensifs plus robustes. L’avertissement de McKerchar fait des tests adversariaux une partie de la conception de l’arrêt, car un test sur un processus obéissant n’établit pas le comportement du mécanisme face à une résistance.

Les tests doivent aussi couvrir les risques créés par le mécanisme d’arrêt lui-même. Si un attaquant peut le déclencher, l’arrêt devient un moyen de provoquer un déni de service, tandis que des faux positifs peuvent interrompre un travail légitime. Kairinos souligne un autre mode de défaillance : un système suffisamment capable peut dissimuler ce qu’il fait ou tenter d’échapper aux contrôles, empêchant ainsi les équipes de sécurité de reconnaître qu’il a déraillé et compromettant de ce fait l’étape de détection nécessaire à l’intervention humaine.

Ces modes de défaillance inscrivent l’arrêt d’urgence dans un modèle de résilience plus large. Le modèle de Kairinos combine l’interrupteur d’arrêt avec des autorisations étroitement restreintes, le sandboxing, l’approbation humaine pour les actions à fort impact et des procédures explicites de réponse aux incidents. L’autorisation positive appartient au même design en couches, car chaque mécanisme couvre un chemin de défaillance différent, réduisant la probabilité qu’une frontière d’identifiants, un système de détection, un mécanisme d’arrêt ou une décision humaine devienne l’unique protection.

Au sein de ces couches, l’arrêt d’urgence conserve un rôle spécifique après l’échec des frontières préventives. D’Amore énonce ce rôle directement : « L’interrupteur d’arrêt a toujours sa place dans chaque déploiement agentique », suivi de « mais comme dernière ligne de défense plutôt que comme première ». Ce positionnement signifie que les équipes doivent toujours tester un confinement rapide tout en concevant en amont des frontières d’autorisation autour d’identifiants temporaires, d’autorisations contraintes et d’approbations pour les actions conséquentes.

Un mécanisme de confinement utilisable dépend aussi du maintien en fonctionnement de l’activité métier environnante. Sheth relie directement ces exigences : « La résilience de l’IA va exiger à la fois contrôle et continuité. Authentifiez l’agent, limitez son autorité, surveillez son comportement, contenez-le lorsque c’est nécessaire, et assurez-vous que l’entreprise peut continuer à fonctionner si vous devez l’arrêter [l’agent d’IA]. » Pour l’ingénierie de réponse aux incidents, la continuité détermine si les opérateurs peuvent réellement utiliser le mécanisme d’arrêt lorsque son activation perturberait autrement les clients, les processus critiques ou les services dépendants.

Points clés

• Traitez les interrupteurs d’arrêt comme des contrôles d’urgence : Les organisations qui déploient une IA autonome ont besoin d’un moyen testé pour ralentir, restreindre ou interrompre une activité dangereuse. La gouvernance doit définir qui peut activer ce contrôle et dans quelles conditions.
• Faites de la détection une partie de la planification de l’arrêt : Les équipes de sécurité et de réponse aux incidents ont besoin d’un monitoring, d’un triage et de chemins d’escalade suffisamment rapides pour réagir pendant que les agents continuent d’agir. Testez l’ensemble du parcours, de la détection d’un comportement dangereux jusqu’à son confinement.
• Contenez l’exécution distribuée : Les équipes plateforme doivent cartographier les sous-agents, les tâches en file d’attente, les identifiants et les outils tiers qui peuvent continuer à fonctionner après l’arrêt d’un agent parent. Les procédures d’arrêt doivent révoquer ou contenir l’autorité sur chaque chemin d’exécution.
• Planifiez les dépendances liées à l’arrêt : Les responsables technologiques et métier doivent identifier quelles applications, quels fournisseurs et quels processus critiques dépendent de chaque service d’IA. Les plans de continuité doivent prendre en compte les perturbations en cascade lorsqu’un composant d’IA est désactivé.
• Faites expirer l’autorité des agents : Les architectes sécurité peuvent utiliser des identifiants de courte durée et à portée étroite, et exiger une approbation pour les actions irréversibles ou à fortes conséquences. Ce modèle de contrôle positif limite combien de temps et jusqu’où un agent peut agir pendant un incident.
• Mettez en place une défense en profondeur autour du contrôle positif : Les équipes de sécurité doivent tester les contrôles d’arrêt face à l’évasion, à la compromission, aux faux positifs et aux risques de déni de service. Le sandboxing, les autorisations restreintes, les approbations humaines et la planification de la continuité apportent un confinement supplémentaire lorsque des contrôles individuels échouent.