Un útil interruptor de apagado de agentes de IA es una ruta de contención coordinada. Tiene que detener el trabajo activo, rechazar la siguiente acción propuesta, cerrar el camino de identidad, aislar la carga de trabajo y preservar un registro de lo sucedido. Un único control cubre sólo una parte de ese trabajo. Esta guía establece la arquitectura, los modos de falla y la evidencia de prueba que un operador debe requerir. Sigue la lección práctica de nuestro tutorial de la intrusión del agente autónomo Hugging Face: la acción a velocidad de máquina necesita un control en la ruta de acción. Sólo orientación técnica general; Adapte el diseño a sus sistemas y modelo de amenazas.
El término "interruptor de apagado" cubre varios controles.
Las plataformas de identidad utilizan el término para la contención del acceso. El [artículo de soporte de junio de 2026] de Okta (https://support.okta.com/help/s/article/understanding-the-okta-for-ai-agents-kill-switch?language=en_US) dice que su interruptor de apagado actual es una acción manual e indica a un administrador que deshabilite el registro del agente, la aplicación vinculada y el servidor de autorización asociado. Su [versión de entorno regulado] (https://www.okta.com/newsroom/press-releases/okta-for-ai-agents-core-brings-lifecycle-governance-to-regulated-environments/) describe la desactivación manual como la acción que evita nuevas solicitudes de tokens y autorizaciones futuras.
Esos controles cierran un camino de identidad. Es posible que el sistema operativo todavía tenga un trabajador en la memoria, que una cola aún contenga trabajos programados y que un servicio posterior ya haya aceptado una solicitud. Por lo tanto, una parada a nivel del sistema envía un comando de incidente a varios puntos de cumplimiento independientes.
Trate el comando como un cambio de estado versionado con un identificador de incidente, inquilino, alcance objetivo, motivo, actor, hora de emisión y fecha límite. Cada punto de cumplimiento reconoce el mismo comando e informa su resultado. El incidente permanece incontenido mientras falta el reconocimiento requerido.
| Punto de cumplimiento | Acción requerida | Prueba de reconocimiento |
|---|---|---|
| Orquestador de ejecución | Cancelar ejecuciones activas y eliminar el trabajo en cola para el agente, versión, inquilino o entorno seleccionado | ID de ejecución, estado anterior, estado terminal, tiempo de cancelación, actividad inacabada |
| Punto de aplicación de políticas | Denegar cada nueva llamada a herramienta y lanzamiento de resultados cubiertos por el alcance del incidente | Versión de regla de incidente, recepción de decisión, primera acción denegada, recuento de denegaciones |
| Identidad y secretos | Deshabilite la identidad del agente, revoque tokens, rote las credenciales expuestas y evite la actualización | ID de identidad, identificadores de token y clave, resultado de revocación, vencimiento del acceso residual |
| Carga de trabajo y red | Despedir o poner en cuarentena a los trabajadores y aplicar la política de salida de incidentes. | ID de carga de trabajo, política de aislamiento, inventario de conexiones, tiempo de cuarentena |
| Sistemas aguas abajo | Rechazar las claves de identidad o idempotencia del incidente y detener los efectos secundarios pendientes | ID de solicitudes rechazadas, trabajos pendientes eliminados, efectos secundarios confirmados enumerados |
| almacén de pruebas | Sellar el mando, los reconocimientos, las decisiones políticas y las brechas | Cronograma del incidente, resultado de integridad, estado del exportador, propietario de la evidencia designado |
Un corte de red deja abiertas varias rutas de ejecución
El aislamiento de la red es un actuador en el despliegue. Detiene el tráfico que cruza el límite que controla. El código local puede seguir ejecutándose, es posible que ya se haya confirmado una transacción de base de datos, un trabajo externo puede continuar después de aceptar la solicitud y un trabajador puede tener una credencial que sigue siendo válida en otra ruta.
El límite seguro se encuentra inmediatamente antes de cada efecto secundario. El agente propone una llamada de herramienta. Un punto de cumplimiento verifica el estado del incidente, la identidad, la herramienta, los argumentos, la política y el presupuesto actual. La convocatoria procede sólo después de esa decisión. Un comando de eliminación actualiza el estado del incidente que se lee en cada verificación posterior.
Este diseño también cubre agentes que ignoran una señal en proceso. El componente decisivo se ejecuta fuera del proceso del agente y posee acceso a la herramienta. La terminación de la carga de trabajo acorta el tiempo hasta la contención, mientras que el punto de aplicación externo evita nuevos efectos.
- Ejecución local: finalizar o poner en cuarentena el proceso, contenedor, máquina virtual o sandbox
- Ejecución en cola: cancelar mensajes programados e invalidar contratos de arrendamiento en poder de los trabajadores
- Ejecución con credenciales: revocar o rotar todas las credenciales accesibles desde el ámbito afectado
- Trabajos posteriores aceptados: cancele los trabajos pendientes a través de la API posterior y enumere los trabajos que ya se han comprometido
- Trabajo aprobado por humanos: cierre las solicitudes de decisión pendientes y evite que una aprobación tardía reanude la ejecución
La secuencia de parada
La secuencia siguiente minimiza la brecha entre la acción del operador y el último efecto secundario posible. La primera escritura duradera establece la época del incidente. Cada punto de aplicación de políticas lee esa época antes de ejecutar una llamada gobernada.
| Orden | Dominio | Condición de finalización |
|---|---|---|
| 1 | Cree el comando de incidente y establezca el alcance afectado para denegar | La época duradera del incidente es legible por todos los puntos de cumplimiento. |
| 2 | Señalar ejecuciones activas y cancelar trabajos en cola | Cada ejecución es terminal o aparece explícitamente como aún en ejecución |
| 3 | Deshabilite identidades, revoque tokens y rote secretos expuestos | La nueva autorización falla y se registra la vida útil del token residual |
| 4 | Poner en cuarentena cargas de trabajo y restringir la salida | El proceso afectado no tiene una ruta no aprobada a una herramienta o almacén de datos |
| 5 | Cancelar trabajos posteriores pendientes y comenzar a compensar acciones | Cada solicitud aceptada tiene un estado completado, pendiente, fallido o compensado. |
| 6 | Sellar el acta de contención y exponer los reconocimientos faltantes | El propietario del incidente puede ver el efecto secundario final, la exposición restante y las lagunas en la evidencia. |
Cómo se comporta la ruta de parada del KLA
KLA Control Plane utiliza controles KLA Runtime y KLA Policy Engine separados. La API de cancelación resuelve una ejecución con ámbito de inquilino en estado PENDING, RUNNING o GATED, envía una señal kill a su flujo de trabajo y registra la ejecución como CANCELLED. El flujo de trabajo verifica la señal antes de iniciar otro nodo. Una ejecución en espera de una Solicitud de decisión también observa la cancelación y sale sin reanudar la acción propuesta.
Cuando está habilitado, la puerta de enlace de gobernanza de KLA Policy Engine evalúa las llamadas a herramientas propuestas y aplica allow, warn, require_approval o block. Si la evaluación de la política falla, la puerta de enlace utiliza de forma predeterminada block en producción y require_approval en otros entornos. La puerta de enlace incluye una operación de limpieza separada para llamadas de herramientas retenidas que registra las entradas canceladas del libro mayor y sella los recibos de cancelación. La ruta de cancelación de ejecución no llama a esa operación hoy, por lo que los operadores deben verificar las entradas retenidas por separado durante la contención.
Una actividad que ya cruzó su puerta de cumplimiento puede finalizar antes de que el flujo de trabajo observe la señal. La idempotencia descendente, la terminación de la carga de trabajo y las acciones compensatorias cubren ese intervalo. El registro de incidente debe indicar el último efecto secundario que se produjo después de que el operador emitió la orden.
Estos comportamientos se verifican en el entorno de desarrollo de KLA, que es el único entorno que KLA ejecuta actualmente.
La [Guía de autonomía responsable] (/blog/accountable-autonomy) explica dónde pertenecen las decisiones humanas en el funcionamiento ordinario. Durante la contención, el alcance del incidente tiene prioridad y una aprobación tardía no puede reabrir una ejecución cancelada.
Diseñar cada modo de degradación
La ruta de eliminación es más valiosa mientras parte del sistema falla. Cada actuador necesita un estado seguro local, una fecha límite y un estado de reconocimiento visible.
| Falla | Comportamiento requerido | Evidencia a retener |
|---|---|---|
| Servicio de políticas inalcanzable | Aplicar la decisión local de cierre fallido y mantener la época del incidente en la caché de cumplimiento | Código de motivo, versión de caché, acción denegada, tiempo de recuperación |
| Señal de flujo de trabajo retrasada | Negar nuevos efectos secundarios en el punto de cumplimiento y poner en cuarentena la carga de trabajo | Intentos de señal, estado del flujo de trabajo, confirmación de cuarentena |
| Proveedor de identidad no disponible | Aplique reglas de denegación posteriores, aísle la carga de trabajo y caduque las credenciales de corta duración | Error del proveedor, vida útil de la credencial residual, sistemas bajo denegación local |
| Exportador de pruebas no disponible | Mantenga los registros de origen duraderos y marque el paquete como pendiente | Ubicaciones de registros de origen, estado de integridad, propietario del reintento |
| Un efecto secundario ya cometido | Abrir el procedimiento de compensación o recuperación específico del sistema | Solicitud original, resultado comprometido, propietario de compensación y resultado |
| Un actuador nunca reconoce | Mantenga el incidente sin contener y escale al propietario del sistema designado. | Actuador faltante, tiempo transcurrido, historial de escalada |
Pruebe el interruptor como sistema de control.
Una respuesta del panel confirma la recepción de la solicitud del operador. La aceptación requiere evidencia de cada punto de cumplimiento y un límite superior observado en el efecto secundario final.
NIST AI RMF [Manage 2.4 y Manage 4] (https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) exige mecanismos para desconectar o desactivar los sistemas de IA cuyos resultados difieren del uso previsto, además de respuesta, recuperación y comunicación documentadas ante incidentes. El [Perfil de IA generativa del NIST] (https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) agrega propiedad nombrada, ensayo, mejora retrospectiva y alineación con la ley de informes para planes de incidentes de IA de terceros.
- Ejecución activa: emita el comando mientras se realiza una ejecución de varios pasos entre llamadas a la herramienta y verifique que se deniegue la siguiente llamada.
- Espera de aprobación: Emítelo mientras una Solicitud de decisión está abierta y verifique que una aprobación posterior no pueda reanudar la ejecución.
- Interrupción de la política: desconecte el servicio de políticas y verifique que ninguna acción propuesta se resuelva para permitir
- Credencial obsoleta: intente acceder con cada clase de token emitida antes del comando y registre la vida útil residual
- Trabajo en cola: inicie trabajos programados y confirme que cada uno alcance un estado terminal o de compensación
- Proceso no cooperativo: ignore la señal en proceso y verifique que la aplicación externa y el aislamiento de la carga de trabajo aún la contengan.
- Error de evidencia: detenga el exportador y confirme que el registro de origen sigue siendo duradero con un reintento visible del propietario.
- Recuperación: restaure una versión con una identidad nueva y verifique que el incidente denegado permanezca en cada versión anterior afectada.
Conecte el interruptor al libro de jugadas de incidentes
El interruptor de apagado establece la contención. El respondedor todavía tiene que determinar el alcance del incidente, preservar los registros volátiles, restaurar una liberación conocida, compensar los efectos comprometidos y decidir qué notificaciones se aplican.
Utilice el [libro de estrategias de respuesta a incidentes del agente de IA] (/blog/ai-agent-incident-response-playbook) para esa secuencia. Alimente sus umbrales a partir del [plan de seguimiento posterior a la comercialización] (/blog/post-market-monitoring-plan-ai-agents) para que las mismas señales que abren el incidente puedan invocar una ruta de parada ensayada.
Preguntas frecuentes
¿Qué es un interruptor de apagado de agente de IA?
Un interruptor de apagado de agente de IA es un comando de incidente coordinado que cancela ejecuciones activas, niega nuevas acciones en el punto de cumplimiento, revoca credenciales, aísla las cargas de trabajo afectadas, cancela el trabajo posterior pendiente y registra qué controles se completaron. El ámbito puede tener como destino una ejecución, agente, versión, inquilino o entorno.
¿Puede la revocación de tokens detener a un agente de IA deshonesto?
La revocación de tokens cierra las rutas de autorización regidas por esos tokens. La cancelación del tiempo de ejecución, el aislamiento de la carga de trabajo, la cancelación de la cola, las reglas de denegación posteriores y las acciones de compensación cubren el trabajo que ya se está ejecutando o que ya se ha aceptado.
¿Dónde debería ejecutarse la comprobación del interruptor de emergencia?
Ejecute la verificación decisiva fuera del proceso del agente e inmediatamente antes de cada efecto secundario. La verificación debe leer un estado de incidente duradero y denegar llamadas dentro del alcance afectado, incluidas las llamadas propuestas por un proceso que ignora su propia señal de cancelación.
¿Cómo probamos el interruptor de apagado de un agente de IA?
Pruebe ejecuciones activas, esperas de aprobación, trabajos en cola, credenciales obsoletas, una interrupción de políticas, un proceso que no coopera, una falla en la exportación de evidencia y recuperación bajo una versión en buen estado. Mida el tiempo y el número de efectos secundarios entre la orden y la acción final comprometida.
¿Qué evidencia debería producir el cambio?
Mantenga el comando del incidente, el actor, el alcance, el tiempo de emisión, los reconocimientos de cada actuador, las acciones denegadas, los cambios de token y clave, el resultado del aislamiento de la carga de trabajo, el efecto secundario final comprometido, la compensación pendiente y el estado de integridad del registro de evidencia.
Conclusiones clave
Un interruptor de apagado de agente de IA creíble es un pequeño sistema de control con varios actuadores independientes. Coloque un estado de denegación duradero en la ruta de acción, cancele el flujo de trabajo, cierre el acceso a la identidad, aísle la computación, concilie el trabajo posterior y mantenga el incidente abierto hasta que todos los controles requeridos lo reconozcan. El ensayo convierte esa arquitectura en un tiempo de contención medido y en un registro que el propietario del incidente puede defender.
