El responsable de operaciones retira a un agente el permiso para liberar pagos. El proceso principal del agente termina. Un pago sigue en una cola, una tarea delegada sigue en ejecución y un proceso de trabajo puede reintentar una solicitud cuyo resultado es incierto. Cada uno de esos elementos necesita una resolución con un responsable asignado antes de que el responsable del incidente pueda decir qué se ha detenido.
El escenario es ilustrativo. Sirve para plantear una pregunta de investigación: ¿qué observaciones respaldan la afirmación de que la autoridad retirada a un agente ya no puede provocar una acción, dentro de un alcance declarado? Este artículo revisa investigación reciente y especificaciones de protocolos, presenta una pequeña reproducción de un verificador de cierre publicado y ofrece una hoja de trabajo que el responsable del incidente puede rellenar. Este artículo forma parte de una serie de investigación en tres partes sobre la autoridad de los agentes, publicada el 26 de octubre de 2026: evidencia de detención, políticas en la memoria del agente y estándares de control de agentes.
Defina primero el alcance de la afirmación
La investigación reciente separa etapas que un único estado de «revocado» puede ocultar. Revocation Is Not Complete at Receipt, un preprint de octubre de 2026 de Lifei Liu, Haoran Yu y Danping Zhang, distingue entre registrar de forma duradera una revocación y entregarla, aplicarla en las pasarelas e impedir los efectos protegidos durante una ventana de observación. Sus experimentos usan una única topología de entrega particionada a propósito, y los autores no dan ninguna tasa de fallo para el conjunto del sector. Leer el artículo.
Un preprint de septiembre de 2026 de Genliang Zhu y Chu Wang aborda la autoridad que continúa a través de la delegación y del trabajo asíncrono. Su protocolo registra de dónde procede la autoridad y cómo cambia el estado de autorización, y realiza comprobaciones en el punto donde una acción surte efecto. También contempla el trabajo que continúa bajo otra autoridad válida e independiente. Ambos artículos son preprints; los resultados que presentan dependen de los supuestos que declaran. Leer el protocolo y la evaluación.
El paso práctico consiste en redactar la afirmación antes de reunir la evidencia que la respalde. Identifique la autoridad retirada, las acciones afectadas, las rutas de aplicación y la ventana de observación. Registre las exclusiones de forma explícita. Una declaración sobre la liberación de pagos debe indicar si cubre trabajos programados, reintentos, procesos de trabajo delegados y solicitudes que un proveedor de pagos ya había aceptado.
La entrega y la cancelación tienen límites definidos
Los protocolos existentes ya cubren partes de este problema. La especificación de revocación de tokens de OAuth trata el retardo de propagación, y la especificación de introspección de tokens describe el coste en seguridad de almacenar en caché las respuestas de introspección. Ambas son relevantes cuando los procesos de trabajo de un agente consultan copias distintas del estado de autorización. RFC 7009, RFC 7662.
Las especificaciones finales OpenID CAEP 1.0 y Shared Signals Framework 1.0 definen contratos de eventos y de entrega que pueden coordinar un cambio entre sistemas. El responsable del incidente sigue necesitando evidencia de lo que cada receptor y cada punto de aplicación posterior hicieron con la señal. CAEP 1.0, Shared Signals Framework 1.0.
La cancelación tiene sus propios límites. La especificación del Model Context Protocol con fecha 2025-06-18 hace opcionales las notificaciones de cancelación y reconoce que el procesamiento puede haber terminado ya o ser imposible de cancelar. Un informe sobre el resultado de un flujo de trabajo debe tener en cuenta esas condiciones de carrera. Cancelación en MCP.
Lo que comprobamos de forma independiente
RISU Research publica un verificador de cierre independiente, bounded-agent-closure. Se cita en los trabajos relacionados y es distinto de los dos preprints anteriores. Ejecutamos su conjunto de pruebas sin modificar en el commit ef07236 (paquete 0.3.1, Node 20): pasaron las 75 pruebas. Después enviamos al verificador los ocho paquetes de evidencia sintéticos que incluye y conservamos las decisiones que devolvió. Repositorio original fijado.
- Una vista ausente es una carencia. Cuando faltaba la vista del planificador, el verificador devolvió UNKNOWN.
- Una tarea que sigue programada es trabajo sin terminar. Una tarea aún programada dio como resultado INCOMPLETE, aunque el paquete declarara éxito.
- El historial puede conservarse. La evidencia histórica conservada era compatible con CLOSED en este perfil.
- Los sucesores son explícitos. Una transferencia a un sucesor se cerró en las condiciones que codifica el caso de prueba.
| Caso de prueba incluido | Resultado observado |
|---|---|
| Tarea directa que sobrevive | INCOMPLETE |
| Tarea transitiva que sobrevive | INCOMPLETE |
| Compromiso pendiente | INCOMPLETE |
| Evidencia conservada | CLOSED |
| Transferencia a un sucesor | CLOSED |
| Cobertura ausente | UNKNOWN |
| Éxito declarado con una tarea que sigue programada | INCOMPLETE |
| Cierre ordenado completado con exploraciones finales estables | CLOSED |
Lo que la reproducción no demuestra
El verificador evalúa la evidencia que recibe. Nuestra ejecución no inició ningún agente, cola ni pago, no buscó colas ocultas y no demuestra que un recolector real informe de todo con veracidad. El conjunto de pruebas y la reproducción de los casos de prueba se solapan, por lo que los ocho casos de prueba no constituyen ocho validaciones independientes adicionales. El resultado de un verificador solo tiene el valor que le dan el alcance de la evidencia y el proceso de recogida que lo respaldan.
No reprodujimos ninguno de los dos preprints. El primer artículo informa de 112 efectos protegidos en 225 intentos con su topología particionada; el segundo informa de 17 casos aceptados y 44 mutaciones rechazadas por su comprobador. Ambas cifras son de los propios autores. El punto de acceso a los artefactos del primer artículo no devolvió contenido utilizable con nuestras herramientas.
Entregue al responsable del incidente un registro de evidencia
Convertimos la investigación en una hoja de trabajo de evidencia de detención (en inglés). Pide la autoridad retirada, el trabajo posterior, los puntos que aplican la retirada, los efectos consumados y las observaciones sin resolver. Incluye espacio para el trabajo de un sucesor bajo una autoridad independiente y para la persona responsable de la conciliación.
Piense en un proceso de trabajo que envió una solicitud de pago antes de la revocación y recibe el justificante después. El justificante forma parte del registro del incidente. La siguiente acción del proceso de trabajo necesita su propia comprobación de autorización vigente. Un efecto ya consumado puede requerir una respuesta de negocio aparte, como una conciliación o una retrocesión autorizada. La hoja de trabajo registra esas responsabilidades y no presupone que ningún efecto pueda deshacerse por defecto.
| Campo | Qué registrar |
|---|---|
| Autoridad retirada | Identificadores raíz y de delegación; identificadores de la solicitud de revocación y del cambio registrado de forma duradera |
| Ventana de observación | Fuentes de reloj, incertidumbre, inicio y fin |
| Alcance | Acciones y destinos de los efectos incluidos; rutas excluidas y el motivo de cada una |
| Rutas de aplicación | La última versión de autorización observada en cada ruta |
| Trabajo pendiente | Entradas en cola, reintentos, trabajo delegado y compromisos pendientes |
| Resolución por elemento | Impedido, completado antes, transferido, pendiente o desconocido |
| Después del corte | Intentos y efectos consumados; justificantes tardíos y acciones de conciliación |
| Carencias | Recolectores ausentes, vistas desactualizadas o evidencia contradictoria |
| Responsables | Acciones pendientes, responsables y fecha de la próxima revisión |
Redacte la declaración de detención con sus límites
La hoja de trabajo termina con una declaración que el responsable del incidente puede reutilizar: «Para [autoridad] y [rutas declaradas], las observaciones de [inicio] a [fin] muestran [resultado]. [Elementos] siguen sin resolver por [carencia concreta de evidencia]. [Responsable] se encarga de la conciliación.»
Conserve las precisiones sobre el período y el alcance cuando copie la declaración en un resumen del incidente. La declaración indica entonces qué acciones se impidieron, cuáles ya se habían consumado, qué tareas se transfirieron y qué observaciones no están disponibles. Los responsables de operaciones, ingeniería y riesgos pueden revisar un único registro en el que la palabra «detenido» tiene un significado claro.
Cómo se relaciona la ruta de detención de KLA con la hoja de trabajo
Los agentes que actúan a través de la ingesta de acciones de agentes de KLA trabajan bajo un mandato de agente. Revocar el mandato bloquea las propuestas abiertas vinculadas a él con el código de motivo mandate_revoked, cancela sus Solicitudes de decisión pendientes y rechaza la siguiente acción que proponga el agente. Una acción ya admitida puede completarse, por lo que corresponde a las filas «completado antes» o «después del corte» de la hoja de trabajo.
La investigación de este artículo no probó KLA. La guía de arquitectura del interruptor de apagado describe la ruta de detención completa de KLA, incluida la congelación por incidente, y el manual de respuesta a incidentes cubre el resto del registro del incidente.
Preguntas frecuentes
¿Cómo se demuestra que un agente de IA se ha detenido?
Formule primero la afirmación: la autoridad retirada, las rutas cubiertas y la ventana de observación. Después registre la última versión de autorización observada en cada ruta de aplicación, la resolución de cada elemento en cola, reintentado o delegado, los efectos consumados después del corte y la evidencia que falta. La afirmación solo es válida dentro de ese alcance y esa ventana.
¿Revocar el token de un agente detiene el trabajo que ya está en curso?
No necesariamente. La revocación de OAuth puede tardar en propagarse y la introspección almacenada en caché puede estar desactualizada. El trabajo que ya está en cola, delegado o aceptado por un sistema posterior puede llegar a completarse, y la cancelación en MCP es opcional y puede competir con la finalización. Cada elemento necesita su propia resolución registrada.
¿Se pueden deshacer las acciones completadas de un agente revocado?
La revocación detiene las acciones nuevas. Un efecto ya consumado sigue consumado: un pago, por ejemplo, necesita una respuesta de negocio aparte, como una conciliación o una retrocesión autorizada, registrada con su responsable.
¿Qué mostró la reproducción del verificador de cierre?
En el commit ef07236 pasaron las 75 pruebas originales, y los ocho paquetes sintéticos incluidos devolvieron tres CLOSED, cuatro INCOMPLETE y un UNKNOWN. La ejecución evaluó únicamente la evidencia suministrada. No inició ningún agente ni cola y no dice nada sobre la exhaustividad de un recolector real.
Conclusiones clave
Un agente se ha detenido solo dentro de un alcance que alguien ha dejado por escrito: la autoridad, las rutas y la ventana temporal. Reúna la evidencia para ese alcance, asigne una resolución a cada elemento abierto e identifique las carencias y sus responsables. Empiece por la hoja de trabajo de evidencia de detención y lea la arquitectura del interruptor de apagado para conocer los controles que producen la evidencia.
Las fuentes se comprobaron el 26 de octubre de 2026. Los dos preprints no se han reproducido de forma independiente. Nuestras observaciones usan casos de prueba sintéticos publicados y no contienen ningún resultado de producción de KLA.