CrowdStrike AI Kill Switch: qué detiene hoy y qué debe cubrir aún tu runbook de agentes

El AI Kill Switch de CrowdStrike ofrece a los equipos de seguridad una forma de aislar a los agentes de IA de los modelos de los que dependen, al ordenar a los gateways de IA conectados que bloqueen ese acceso. Bloquear ese acceso no demuestra que se haya detenido el trabajo que el agente ya había iniciado. Un agente con su propia clave de API podría seguir recibiendo respuestas del modelo después de activar el interruptor, hasta donde muestran las fuentes publicadas.

Qué hace hoy el AI Kill Switch de CrowdStrike

Los detalles siguientes proceden principalmente de la publicación de lanzamiento de CrowdStrike y del informe de Channel Insider.

El AI Kill Switch se anunció el 3 de noviembre en Fal.Con Europe 2026, en Barcelona, y está disponible a través de CrowdStrike Falcon Guardian. Los equipos de seguridad lo activan en Falcon Guardian, que ordena a los gateways de IA conectados bloquear el acceso a los modelos de IA que impulsan las decisiones y acciones de los agentes. El agente ya no puede preguntar a un modelo qué hacer a continuación.

Falcon AI Gateway se incluye con Falcon Guardian sin coste adicional. CrowdStrike afirma que extiende la seguridad de la IA a aplicaciones y cargas de trabajo más allá de la cobertura directa del sensor de endpoint, incluidos los entornos no gestionados. Si ya utilizas Falcon Guardian, es posible que el gateway ya esté licenciado, de modo que la cuestión pendiente es qué parte del tráfico de tus agentes pasa realmente por él.

El control disponible hoy actúa sobre la ruta entre un agente y su modelo. MLQ.ai informa de que la cobertura independiente no encontró ninguna prueba de terceros publicada que muestre si el interruptor alcanza a los agentes que operan fuera de un gateway controlado.

Lo disponible frente a lo prometido: cómo leer el lenguaje de la hoja de ruta

El propio blog de CrowdStrike traza el límite: "Próximamente, CrowdStrike ampliará AI Kill Switch más allá de la aplicación en el gateway para ofrecer una contención coordinada de agentes en toda la plataforma Falcon". El informe de Channel Insider coincide: la interrupción basada en gateway está disponible actualmente, mientras que la terminación directa en el endpoint y la contención coordinada en otros sistemas siguen planificadas. Te sugerimos no programar la retirada de ningún paso manual basándote solo en la hoja de ruta.

La publicación complementaria de CrowdStrike sobre Falcon Guardian muestra por qué importa este límite. La empresa afirma que proteger a los agentes de IA requiere visibilidad y control en tres capas críticas: la ejecución en tiempo de ejecución a nivel del sistema operativo, las comunicaciones de red y las interacciones de los agentes. La capa de ejecución a nivel del sistema operativo es donde residen los procesos lanzados, y la terminación directa en el endpoint sigue en la lista de lo planificado.

Dónde divergen la cobertura del lanzamiento y el blog del fabricante

La noticia de CNBC sobre el lanzamiento ofrece la versión más amplia. Según ella, se trata de un interruptor de emergencia diseñado para que los equipos de seguridad detengan a los agentes de IA internos que se descontrolen, impidan que se relancen y corten su acceso a la red empresarial. El blog de CrowdStrike describe la aplicación en el gateway como el mecanismo disponible y la contención coordinada en la plataforma Falcon como algo próximo. Su frase sobre la hoja de ruta no menciona los reinicios, por lo que el bloqueo de relanzamientos sigue sin confirmarse como función que puedas usar hoy.

La diferencia puede deberse simplemente a una redacción más laxa el día del lanzamiento o a una sesión informativa más amplia, pero eso es especulación nuestra.

Consigue el alcance por escrito: pregunta a tu contacto de CrowdStrike qué acciones del interruptor están disponibles de forma general hoy y qué licencia o paquete requiere cada una, y después qué evidencia confirma que una acción ha surtido efecto y dónde queda registrada. Guarda la respuesta fechada junto con el runbook.

Qué no detiene un bloqueo del modelo

La arquitectura de gateway puede interrumpir las futuras solicitudes de un agente a un modelo, pero esto por sí solo no demuestra que se hayan revertido los comandos ya emitidos ni que se hayan detenido los agentes y herramientas posteriores. Ese límite, expuesto en el análisis de MLQ.ai, importa sobre todo en el trabajo que ya no necesita un modelo para continuar. Channel Insider añade un segundo límite: bloquear el acceso al modelo no termina necesariamente todos los procesos que un agente ya ha lanzado ni revoca las credenciales que utilizó anteriormente.

Imagina un agente de prueba hipotético que lanza un trabajo de exportación independiente justo antes del bloqueo. El interruptor funciona como se describe y la siguiente solicitud del agente al modelo falla. El trabajo de exportación nunca necesitó el modelo, así que sigue en marcha, y el token que recibió sigue siendo válido hasta que alguien lo revoque o caduque.

Los hooks a nivel de agente no cierran esa brecha. CrowdStrike describe hooks para Claude Code, OpenAI Codex, GitHub Copilot, OpenCode y Cursor que permiten a las organizaciones inspeccionar los prompts y bloquear la actividad maliciosa en el origen, antes de que se ejecuten acciones dañinas. Como actúan antes de la ejecución, no abordan el trabajo ya lanzado, y solo ayudan en los agentes donde están instalados.

Quién activa el interruptor y quién restablece el acceso

Detectar y decidir son trabajos distintos. Según CNBC, el proceso puede detectar la actividad de los agentes internos, pero una persona tiene que decidir aislar al agente y restablecer el acceso. Fija estos nombres con antelación, porque el playbook siguiente depende de ellos: quién puede activar el interruptor y con qué evidencia, a quién hay que informar (incluidos los responsables de negocio de los agentes afectados), quién puede anular o retrasar una activación, quién aprueba la recuperación y quién ocupa cada función fuera del horario laboral.

La cobertura fuera de horario es donde un servicio gestionado puede ayudar. Falcon Complete for Guardian ofrece supervisión, investigación y respuesta 24/7 frente a amenazas específicas de la IA, lo que puede cubrir la supervisión y la respuesta, pero tu equipo debe confirmar igualmente quién tiene la decisión de activar y restablecer.

Acordad también de antemano los criterios de impacto en el negocio, ya que un bloqueo de modelos o gateways compartidos puede interrumpir trabajo legítimo además del agente sospechoso.

Lista de carencias del runbook de agentes: un playbook de siete pasos

Creamos esta lista de comprobación como marco de trabajo; nadie la ha sometido a evaluación comparativa, así que adáptala a tu estructura. El Paso 1 es de preparación y los Pasos 2 a 7 son de respuesta en vivo. Los responsables indicados son sugerencias.

Paso 1: Claves y rutas directas

Cuándo: Antes de un incidente y, después, de forma periódica.

Responsable: Ingeniería de plataforma.

Acción: Inventaría todas las rutas de agente a un modelo que eviten un gateway conectado y después rota o elimina esas claves. Asigna a cada agente su propia identidad de servicio para que el Paso 4 pueda atribuirle su actividad. Este paso va primero porque, según informa MLQ.ai, ninguna prueba de terceros publicada muestra si el interruptor alcanza a los agentes que operan fuera de un gateway controlado. Cuando un agente necesite realmente acceso a la API, un proxy de credenciales que mantenga las claves de API fuera de los agentes de IA es un patrón que merece la pena evaluar.

Prueba de finalización: Un inventario con cada ruta marcada como vinculada al gateway, rotada o eliminada.

Punto de activación: acciona el interruptor

La activación es la primera acción en vivo y se realiza en cuanto la persona designada para decidir da la orden. Detiene las nuevas decisiones del modelo a través de los gateways conectados mientras el equipo avanza por los Pasos 2 a 7. Si aparece una ruta directa en este momento, desactívala de inmediato.

Paso 2: Tokens activos

Cuándo: Justo después de la activación.

Responsable: Equipo de identidad.

Acción: Revoca por separado los tokens de acceso y los tokens de actualización, porque revocar el token de actualización puede dejar operativo el token de acceso.

Prueba de finalización: Las llamadas de prueba con cada token fallan en los servicios que el agente utilizó realmente.

El RFC también advierte de un posible retraso de propagación durante el cual algunos servidores conocen la invalidación y otros no, de modo que un token puede seguir funcionando en un servicio después de que otro lo haya rechazado.

Paso 3: Revocaciones fallidas

Cuándo: A medida que lleguen las respuestas del Paso 2.

Responsable: Guardia de identidad.

Acción: Considera inacabada toda revocación fallida: reinténtala y registra el estado final. Cuando un proveedor no tenga endpoint de revocación, rota el secreto subyacente o desactiva la identidad del agente, y da por hecho que los tokens emitidos siguen activos hasta que caduquen. Una respuesta de revocación correcta tampoco demuestra la propagación, así que vuelve a comprobarlo.

Prueba de finalización: Un registro que muestre el estado final y el resultado de la nueva comprobación de cada token.

Recomendamos el mismo tratamiento para los tiempos de espera agotados y otros errores de servidor 5xx. Según nuestra lectura, el RFC solo se aplica a los sistemas OAuth que lo implementan, por lo que las claves de API y las credenciales propietarias requieren comprobaciones específicas de cada plataforma.

Paso 4: Evidencia y atribución

Cuándo: Antes de cualquier terminación, junto con los Pasos 2 y 3 si es necesario.

Responsable: Operaciones de seguridad.

Acción: Captura los árboles de procesos, los registros y los registros de sesión del agente antes de detener nada. Después, atribuye cada proceso al agente tanto por el linaje del proceso (la cadena de procesos padre e hijo hasta el entorno de ejecución del agente) como por la identidad de servicio, ya que un proceso independiente puede perder su linaje y una cuenta compartida difumina la identidad. Si un proceso está causando daños activos, el responsable del incidente puede autorizar su detención tras una captura mínima, y el registro debe indicarlo.

Prueba de finalización: Evidencia con marca de tiempo en el almacenamiento, además de una lista de procesos en la que cada entrada figure como atribuida, no relacionada o desconocida.

Paso 5: Procesos en ejecución

Cuándo: Después del Paso 4.

Responsable: Operaciones de seguridad.

Acción: Localiza y detén lo que el agente ya haya lanzado mediante herramientas de hosts y cargas de trabajo, porque un bloqueo del modelo puede dejar esos procesos en marcha. Parte de la lista del Paso 4 e investiga todo lo marcado como desconocido. La terminación directa en el endpoint sigue estando solo planificada, así que por ahora este sigue siendo tu procedimiento.

Prueba de finalización: Un listado obtenido después de la detención, con las mismas comprobaciones, que muestre que no queda ningún proceso lanzado por el agente.

Paso 6: Llamadas a herramientas en curso

Cuándo: Junto con el Paso 5.

Responsable: El responsable de la aplicación de cada herramienta conectada.

Acción: Da por hecho que la cancelación puede llegar demasiado tarde. Comprueba directamente el estado posterior en los sistemas que tocan esas herramientas y enumera todo lo que deba revertirse. El rastreo GenAI de OpenTelemetry para la actividad de LLM y agentes puede ayudarte a elaborar esa lista, siempre que estuviera implantado antes del incidente.

Prueba de finalización: Un registro revisado de cada llamada en curso y su resultado real.

Paso 7: Trabajo en cola y recuperación

Cuándo: Antes de que se restablezca el acceso.

Responsable: Responsable del incidente.

Acción: Vacía o retén las colas para que el trabajo pendiente no se ejecute en cuanto se restablezca el acceso. La forma en que tu entorno de ejecución conserva y reanuda el trabajo en cola determina qué tienes que vaciar. Después, haz que una persona designada apruebe el restablecimiento del acceso conforme a una lista de comprobación escrita.

Prueba de finalización: Un registro de recuperación firmado que vincule cada elemento de la lista con su evidencia.

Lista de comprobación del ejercicio de simulación

Realiza el ejercicio en tu tenant real, pero con recursos aislados: un agente de prueba, una ruta de gateway y un endpoint de modelo dedicados que ningún trabajo de producción utilice. Te sugerimos confirmar primero con qué precisión se puede acotar la activación. Si no se puede limitar a la ruta de prueba, acuerda una ventana programada con los responsables de negocio afectados.

Superado: cada uno termina con un estado final registrado.

• [ ] Activa el interruptor contra el agente de prueba. Superado: la siguiente solicitud al modelo se bloquea y queda registrada.
• [ ] Intenta una llamada al modelo desde el mismo agente con cualquier clave directa. Superado: la llamada falla.
• [ ] Revoca por separado los tokens de acceso y de actualización y prueba cada uno. Superado: ambos fallan en todos los servicios utilizados.
• [ ] Captura evidencia de un proceso de prueba lanzado antes del bloqueo. Superado: los registros se almacenan antes de la terminación y el proceso se puede rastrear hasta el agente.
• [ ] Detén ese proceso y un proceso hijo independiente. Superado: no queda ningún proceso atribuido.
• [ ] Cancela una llamada a una herramienta de larga duración. Superado: el registro coincide con el estado posterior real.
• [ ] Retén el trabajo en cola y consulta el estado de las tareas. Superado: todas las tareas muestran el estado cancelado y nada se ejecuta cuando se restablece el acceso.
• [ ] Completa la aprobación de la recuperación. Superado: la persona designada para aprobar firma con la evidencia vinculada.

Advertencias y lo que sigue sin demostrarse

MLQ.ai informa de que la cobertura independiente no encontró ninguna prueba de terceros publicada que muestre con qué rapidez actúa el interruptor ni si alcanza a los agentes que operan fuera de un gateway controlado. Los críticos citados en la noticia de CNBC van más allá y consideran que un botón de parada de emergencia es demasiado complicado de implementar en múltiples sistemas, centros de datos y modelos de IA complejos. Cabe esperar que la respuesta varíe según cuántos de tus agentes funcionen a través de un gateway conectado, cuántas herramientas toquen y cómo gestionen la cancelación tus entornos de ejecución.

Se trata de un lanzamiento reciente y su alcance puede cambiar, así que consulta la documentación actual de CrowdStrike antes de cerrar los procedimientos.

Las indicaciones sobre el protocolo también requieren disciplina de versiones.