CrowdStrike AI Kill Switch : ce qu'il arrête aujourd'hui et ce que votre runbook d'agents doit encore prévoir

Le CrowdStrike AI Kill Switch permet aux équipes de sécurité de couper les agents d'IA des modèles dont ils dépendent, en ordonnant aux passerelles d'IA connectées de bloquer cet accès. Ce blocage ne prouve pas pour autant que le travail déjà lancé par l'agent s'est arrêté. D'après les sources publiées, un agent disposant de sa propre clé d'API pourrait continuer à recevoir des réponses de modèles une fois le coupe-circuit actionné.

Ce que fait aujourd'hui le CrowdStrike AI Kill Switch

Les informations ci-dessous proviennent principalement de l'article de lancement de CrowdStrike et du compte rendu de Channel Insider.

L'AI Kill Switch a été annoncé le 3 novembre lors de Fal.Con Europe 2026 à Barcelone et il est disponible via CrowdStrike Falcon Guardian. Les équipes de sécurité l'activent dans Falcon Guardian, qui ordonne aux passerelles d'IA connectées de bloquer l'accès aux modèles d'IA sur lesquels reposent les décisions et les actions des agents. L'agent ne peut alors plus demander à un modèle ce qu'il doit faire ensuite.

Falcon AI Gateway est inclus dans Falcon Guardian sans coût supplémentaire. Selon CrowdStrike, il étend la sécurité de l'IA aux applications et aux charges de travail au-delà de la couverture directe des capteurs sur les terminaux, y compris dans les environnements non gérés. Si vous utilisez déjà Falcon Guardian, la passerelle est peut-être déjà sous licence : la question qui reste ouverte est de savoir quelle part du trafic de vos agents la traverse réellement.

Le contrôle disponible aujourd'hui agit sur le chemin entre un agent et son modèle. MLQ.ai indique que la couverture indépendante n'a trouvé aucun test tiers publié montrant si le coupe-circuit atteint les agents opérant en dehors d'une passerelle contrôlée.

Disponible ou promis : décrypter le langage de la feuille de route

Le blog de CrowdStrike trace lui-même la frontière : « Prochainement, CrowdStrike étendra AI Kill Switch au-delà de l'application au niveau des passerelles afin d'offrir un confinement coordonné des agents sur l'ensemble de la plateforme Falcon. » Le compte rendu de Channel Insider concorde : l'interruption par passerelle est disponible actuellement, tandis que l'arrêt direct sur les terminaux et le confinement coordonné sur d'autres systèmes restent planifiés. Nous conseillons de ne programmer la suppression d'aucune étape manuelle sur la seule foi de la feuille de route.

L'article complémentaire de CrowdStrike sur Falcon Guardian montre pourquoi cette frontière compte. L'entreprise affirme que la sécurisation des agents d'IA exige une visibilité et un contrôle sur trois couches critiques : l'exécution au niveau du système d'exploitation, les communications réseau et les interactions des agents. C'est dans la couche d'exécution au niveau du système d'exploitation que vivent les processus lancés, et l'arrêt direct sur les terminaux figure toujours parmi les éléments planifiés.

Là où la couverture du lancement et le blog de l'éditeur divergent

L'article de CNBC sur le lancement donne la version la plus large. Il décrit un coupe-circuit conçu pour permettre aux équipes de sécurité d'arrêter les agents d'IA internes devenus incontrôlables, de les empêcher de se relancer et de couper leur accès au réseau de l'entreprise. Le blog de CrowdStrike présente l'application au niveau des passerelles comme le mécanisme disponible et le confinement coordonné sur la plateforme Falcon comme à venir prochainement. Sa phrase sur la feuille de route ne mentionne pas les redémarrages : le blocage des relances reste donc non confirmé en tant que fonctionnalité utilisable aujourd'hui.

Cet écart tient peut-être simplement à une formulation plus approximative le jour du lancement ou à un briefing plus large, mais il ne s'agit là que d'une supposition de notre part.

Faites confirmer le périmètre par écrit : demandez à votre contact chez CrowdStrike quelles actions du coupe-circuit sont généralement disponibles aujourd'hui et quelle licence ou offre chacune requiert, puis quelles preuves confirment qu'une action a pris effet et où elles sont enregistrées. Conservez la réponse datée avec le runbook.

Ce qu'un blocage des modèles n'arrête pas

L'architecture de passerelle peut interrompre les futures requêtes d'un agent vers un modèle, mais cela ne montre pas à lui seul que les commandes déjà émises ont été annulées ni que les agents et outils en aval se sont arrêtés. Cette limite, exposée dans l'analyse de MLQ.ai, compte surtout pour le travail qui n'a plus besoin d'un modèle pour se poursuivre. Channel Insider ajoute une seconde limite : bloquer l'accès aux modèles ne met pas nécessairement fin à tous les processus déjà lancés par un agent et ne révoque pas forcément les identifiants qu'il a utilisés auparavant.

Prenons un agent de test hypothétique qui lance une tâche d'export détachée juste avant le blocage. Le coupe-circuit fonctionne comme prévu et la requête suivante de l'agent vers le modèle échoue. La tâche d'export n'a jamais eu besoin du modèle : elle continue donc de s'exécuter, et le jeton qui lui a été remis reste valide jusqu'à ce que quelqu'un le révoque ou qu'il expire.

Les hooks au niveau des agents ne comblent pas cette lacune. CrowdStrike décrit des hooks pour Claude Code, OpenAI Codex, GitHub Copilot, OpenCode et Cursor qui permettent aux organisations d'inspecter les prompts et de bloquer les activités malveillantes à la source, avant l'exécution d'actions nuisibles. Comme ils agissent avant l'exécution, ils ne traitent pas le travail déjà lancé, et ils ne sont utiles que sur les agents où ils sont installés.

Qui actionne le coupe-circuit et qui rétablit l'accès

Détecter et décider sont deux tâches distinctes. Selon CNBC, le processus peut détecter l'activité des agents internes, mais c'est à un être humain de décider de couper l'agent et de rétablir l'accès. Fixez ces noms à l'avance, car le playbook ci-dessous en dépend : qui peut déclencher le coupe-circuit et sur quelles preuves, qui doit être informé (y compris les responsables métier des agents concernés), qui peut annuler ou retarder un déclenchement, qui valide la reprise et qui assure chaque rôle en dehors des heures ouvrées.

C'est pour la couverture hors des heures ouvrées qu'un service managé peut être utile. Falcon Complete for Guardian propose une surveillance, des investigations et une réponse 24/7 pour les menaces propres à l'IA, ce qui peut couvrir la surveillance et la réponse, mais votre équipe doit tout de même confirmer qui détient la décision de déclencher et de rétablir.

Convenez également au préalable de critères d'impact métier, car un blocage portant sur des modèles ou des passerelles partagés peut interrompre un travail légitime en même temps que l'agent suspect.

Les lacunes du runbook d'agents : un playbook en sept étapes

Nous avons conçu cette liste de contrôle comme un cadre de travail ; personne ne l'a évaluée par des tests comparatifs, alors adaptez-la à votre structure. L'étape 1 relève de la préparation et les étapes 2 à 7 de la réponse en direct. Les responsables indiqués sont des suggestions.

Étape 1 : clés directes et routes

Quand : avant un incident, puis à intervalles réguliers.

Responsable : ingénierie de plateforme.

Action : recensez chaque route d'agent vers un modèle qui contourne une passerelle connectée, puis effectuez la rotation de ces clés ou supprimez-les. Attribuez à chaque agent sa propre identité de service afin que l'étape 4 puisse lui imputer son activité. Cette étape vient en premier car, selon MLQ.ai, aucun test tiers publié ne montre si le coupe-circuit atteint les agents opérant en dehors d'une passerelle contrôlée. Lorsqu'un agent a réellement besoin d'un accès à l'API, un proxy d'identifiants qui tient les clés d'API hors de portée des agents d'IA est un modèle qui mérite d'être évalué.

Preuve d'exécution : un inventaire où chaque route est marquée comme liée à une passerelle, renouvelée ou supprimée.

Point de déclenchement : activer le coupe-circuit

L'activation est la première action en direct, effectuée dès que la personne désignée pour décider a tranché. Elle arrête les nouvelles décisions des modèles via les passerelles connectées pendant que l'équipe traite les étapes 2 à 7. Si une route directe apparaît à ce moment-là, désactivez-la immédiatement.

Étape 2 : jetons actifs

Quand : juste après l'activation.

Responsable : équipe chargée des identités.

Action : révoquez séparément les jetons d'accès et les jetons d'actualisation, car la révocation du jeton d'actualisation peut laisser le jeton d'accès fonctionnel.

Preuve d'exécution : les appels de test avec chaque jeton échouent auprès des services réellement utilisés par l'agent.

La RFC met également en garde contre un éventuel délai de propagation pendant lequel certains serveurs ont connaissance de l'invalidation alors que d'autres non : un jeton peut donc continuer à fonctionner sur un service après avoir été rejeté par un autre.

Étape 3 : révocations échouées

Quand : à mesure que les réponses de l'étape 2 arrivent.

Responsable : astreinte de l'équipe chargée des identités.

Action : considérez chaque révocation échouée comme inachevée : relancez-la et consignez l'état final. Lorsqu'un fournisseur ne propose pas de point de terminaison de révocation, renouvelez le secret sous-jacent ou désactivez l'identité de l'agent, et partez du principe que les jetons émis restent actifs jusqu'à leur expiration. Une réponse de révocation réussie ne prouve pas non plus la propagation : testez donc à nouveau.

Preuve d'exécution : un journal indiquant un statut final et le résultat d'un nouveau test pour chaque jeton.

Nous recommandons le même traitement pour les délais d'attente dépassés et les autres erreurs serveur 5xx. Selon notre lecture, la RFC ne s'applique qu'aux systèmes OAuth qui l'implémentent : les clés d'API et les identifiants propriétaires nécessitent donc des vérifications propres à chaque plateforme.

Étape 4 : preuves et attribution

Quand : avant tout arrêt, en parallèle des étapes 2 et 3 si nécessaire.

Responsable : opérations de sécurité.

Action : capturez les arborescences de processus, les journaux et les enregistrements de session des agents avant d'arrêter quoi que ce soit. Attribuez ensuite chaque processus à l'agent à la fois par sa filiation (la chaîne parent-enfant remontant jusqu'au runtime de l'agent) et par l'identité de service, car un processus détaché peut perdre sa filiation et un compte partagé brouille l'identité. Si un processus cause un préjudice actif, le responsable de l'incident peut autoriser un arrêt après une capture minimale, et le dossier doit le mentionner.

Preuve d'exécution : des preuves horodatées et stockées, ainsi qu'une liste de processus marquant chaque entrée comme attribuée, sans rapport ou inconnue.

Étape 5 : processus en cours d'exécution

Quand : après l'étape 4.

Responsable : opérations de sécurité.

Action : identifiez et arrêtez ce que l'agent a déjà lancé à l'aide des outils de gestion des hôtes et des charges de travail, car un blocage des modèles peut laisser ces processus actifs. Travaillez à partir de la liste de l'étape 4 et examinez tout ce qui est marqué comme inconnu. L'arrêt direct sur les terminaux n'étant encore que planifié, cette procédure reste la vôtre pour le moment.

Preuve d'exécution : une liste établie après l'arrêt, avec les mêmes vérifications, qui montre qu'il ne reste aucun processus lancé par l'agent.

Étape 6 : appels d'outils en cours

Quand : en parallèle de l'étape 5.

Responsable : le responsable applicatif de chaque outil connecté.

Action : partez du principe que l'annulation peut arriver trop tard. Vérifiez directement l'état en aval dans les systèmes touchés par ces outils et dressez la liste de tout ce qui doit être annulé. Le traçage OpenTelemetry GenAI de l'activité des LLM et des agents peut vous aider à établir cette liste, à condition d'avoir été mis en place avant l'incident.

Preuve d'exécution : un relevé vérifié de chaque appel en cours et de son résultat réel.

Étape 7 : travail en file d'attente et reprise

Quand : avant le rétablissement de l'accès.

Responsable : responsable de l'incident.

Action : videz ou suspendez les files d'attente afin que les tâches en attente ne s'exécutent pas dès le retour de l'accès. La façon dont votre runtime conserve et reprend le travail en file d'attente détermine ce que vous devez vider. Faites ensuite approuver le rétablissement de l'accès par une personne désignée, sur la base d'une liste de contrôle écrite.

Preuve d'exécution : un procès-verbal de reprise signé reliant chaque élément de la liste de contrôle à sa preuve.

Liste de contrôle de l'exercice sur table

Réalisez l'exercice dans votre environnement réel, mais sur des ressources isolées : un agent de test, une route de passerelle et un point de terminaison de modèle dédiés, qu'aucune activité de production n'utilise. Nous suggérons de vérifier d'abord jusqu'à quel point l'activation peut être circonscrite. Si elle ne peut pas être limitée à la route de test, convenez d'un créneau planifié avec les responsables métier concernés.

Réussite : chacun aboutit à un statut final consigné.

• [ ] Déclenchez le coupe-circuit sur l'agent de test. Réussite : la requête suivante vers le modèle est bloquée et enregistrée.
• [ ] Tentez un appel au modèle depuis le même agent avec une clé directe. Réussite : l'appel échoue.
• [ ] Révoquez séparément les jetons d'accès et d'actualisation, puis testez chacun d'eux. Réussite : les deux échouent sur chaque service utilisé.
• [ ] Capturez les preuves d'un processus de test lancé avant le blocage. Réussite : les enregistrements sont stockés avant l'arrêt et le processus remonte jusqu'à l'agent.
• [ ] Arrêtez ce processus et un processus enfant détaché. Réussite : il ne reste aucun processus attribué.
• [ ] Annulez un appel d'outil de longue durée. Réussite : le relevé correspond à l'état réel en aval.
• [ ] Suspendez le travail en file d'attente et interrogez l'état des tâches. Réussite : chaque tâche affiche le statut annulé et rien ne s'exécute au retour de l'accès.
• [ ] Finalisez la validation de la reprise. Réussite : l'approbateur désigné signe sur la base des preuves associées.

Réserves et points qui restent à prouver

MLQ.ai indique que la couverture indépendante n'a trouvé aucun test tiers publié montrant à quelle vitesse le coupe-circuit agit ni s'il atteint les agents opérant en dehors d'une passerelle contrôlée. Les détracteurs cités dans l'article de CNBC vont plus loin et jugent un bouton d'arrêt d'urgence bien trop compliqué à mettre en œuvre sur plusieurs systèmes, centres de données et modèles d'IA complexes. Nous nous attendons à ce que la réponse varie selon le nombre de vos agents qui passent par une passerelle connectée, le nombre d'outils qu'ils touchent et la manière dont vos runtimes gèrent l'annulation.

Ce lancement est récent et son périmètre peut évoluer : consultez la documentation actuelle de CrowdStrike avant de finaliser vos procédures.

Les recommandations relatives aux protocoles exigent elles aussi une rigueur dans le suivi des versions.