Rodrigo Jorge · Preparado el 12 de octubre de 2026 a las 06:04 (hora de Brasilia, UTC-3). Hora de publicación por confirmar.
En la demostración, el operador apaga al agente y la pantalla deja de recibir mensajes. Eso demuestra que la interfaz se detuvo. ¿La API todavía acepta la credencial que usaba el agente?
Este es un escenario de prueba, no el relato de un incidente. Como CISO, pediría verificarlo antes de autorizar a un agente a modificar el entorno. El objetivo del kill switch es interrumpir su capacidad de actuar. Una confirmación en el panel, por sí sola, no demuestra que eso haya ocurrido.
Sesión anterior, credencial nueva
La documentación de AWS IAM ofrece un ejemplo concreto de esa diferencia. Al revocar las sesiones de un role, AWS aplica la policy AWSRevokeOlderSessions, con un corte basado en el momento de emisión de las credenciales. Las sesiones emitidas después del corte quedan fuera de esa denegación. AWS también documenta retrasos en la propagación de los cambios de IAM.
Esto no demuestra que un agente haya fallado ni establece una regla para todas las plataformas. Es el comportamiento documentado de un mecanismo de revocación. Para un agente que lo utiliza, la inferencia operativa es directa: además de revocar las sesiones anteriores, hay que comprobar si sigue autorizado a obtener otras.
Son dos pruebas. Con la sesión ya abierta, intentar una operación que antes estaba permitida. Después, intentar obtener una nueva sesión por la vía que realmente usa la integración. Un rechazo en la primera prueba no resuelve la segunda. Estas pruebas deben usar una identidad dedicada y recursos de laboratorio, sin exponer credenciales en los logs.
La tarea puede haber salido del agente
Considera un flujo que envía un job a otro servicio. Una vez que ese servicio acepta la solicitud, detener el proceso que la envió puede dejar el job en ejecución. Aquí describimos una posibilidad de diseño de la arquitectura, no un comportamiento demostrado en todos los servicios.
Por eso, propongo observar tres cosas durante la prueba de apagado: dejan de ingresar nuevas tareas; las credenciales ya emitidas dejan de autorizar la acción prevista; las tareas aceptadas por otro servicio se identifican y se gestionan según el mecanismo de cancelación disponible.
No hace falta pedirle a un modelo que evalúe esas condiciones. La evidencia puede venir de respuestas de API, del estado de la cola y de los registros de ejecución. La persona responsable del apagado debe poder acceder a ella aunque el agente no esté disponible o esté comprometido.
Ver el diagrama: qué verificar después de activar el kill switch. Guía conceptual de prueba, sin tiempos medidos.
Qué pediría en la evaluación
Un registro con la hora exacta del comando de parada, la última acción aceptada y el primer rechazo observado. También el intento de renovación de la sesión y qué ocurrió con las tareas pendientes. Si hay propagación de una policy, el intervalo debe medirse en ese entorno; este artículo no establece un tiempo universal de apagado.
La prueba también debe revelar quién más resultó afectado. Revocar las sesiones de un role compartido puede interrumpir el trabajo de otros usuarios. Usar identidades separadas por integración ayuda a acotar ese impacto, pero no elimina la necesidad de revisar los permisos efectivos.
La decisión de autorizar la operación debe considerar qué puede seguir ocurriendo durante ese intervalo y qué ya se ejecutó. Una acción completada requiere evaluación y, cuando sea posible, recuperación. El kill switch no deshace lo que ya ocurrió.
Referencias
- AWS IAM: Revoke IAM role temporary security credentials, documentación consultada el 12 de octubre de 2026. Alcance de la revocación e impacto en los usuarios del role.
- AWS IAM: Changes that I make are not always immediately visible, documentación consultada el 12 de octubre de 2026. Propagación y verificación de los cambios.