Revocar un agente: qué pasa con el trabajo que ya estaba en marcha

Problema

Se retira el acceso de un agente y el panel muestra que está desactivado. Sin embargo, había tareas en una cola, sesiones abiertas y trabajo delegado a otros componentes. La organización ha cambiado una credencial, pero todavía no sabe qué acciones pueden terminar.

La revocación es especialmente difícil cuando la interfaz presenta al agente como una sola entidad y su ejecución depende de varios servicios. Desactivar el nombre visible no describe necesariamente el estado de todas sus capacidades.

Tesis

Define la revocación como un procedimiento con alcance y comprobación. La autorización de MCP distingue recursos y manejo de tokens; OpenClaw documenta fronteras de confianza y permisos de herramientas. Ninguna integración debería interpretarse como un interruptor universal sin probar sus efectos.

El objetivo operativo es impedir nuevas acciones no permitidas y resolver de forma controlada las que ya estaban en curso. Algunas podrán cancelarse; otras requerirán confirmar o compensar su resultado.

Framework

Localiza las capacidades activas

Inventaría credenciales, sesiones, tareas programadas y delegaciones. Relaciona cada una con un recurso y un responsable. Un permiso concedido por otra cuenta o un proceso externo puede quedar fuera del control que ofrece el panel principal.

Distingue lectura, modificación y comunicación. El tratamiento de una tarea de análisis puede ser distinto al de una orden de envío. La prioridad depende del efecto que todavía pueda producir, no solo del estado del agente.

Establece un punto de corte

Registra cuándo se ordena revocar y qué ejecución queda afectada. Después comprueba los destinos: nuevas solicitudes rechazadas, colas detenidas y sesiones invalidadas según el mecanismo disponible. No presupongas una propagación instantánea ni idéntica en todos los proveedores.

Para operaciones ya iniciadas, consulta el estado antes de repetir o compensar. Cancelar localmente una solicitud no garantiza que el servicio remoto no la haya aplicado. La reconciliación del resultado forma parte de la revocación.

Conserva la evidencia necesaria

Guarda qué acceso se retiró y qué excepciones siguen abiertas. La investigación posterior necesita distinguir acciones anteriores y posteriores al corte. Evita eliminar registros relevantes mientras todavía se está comprobando el alcance del incidente.

El cierre debe indicar qué quedó detenido, qué terminó y quién acepta los pendientes. Una casilla de «desactivado» puede ser parte de la evidencia, pero no toda ella.

Simulacro de baja con tareas preparadas

Prepara un agente de prueba con una lectura, una escritura pendiente y una tarea programada sobre datos sintéticos. Registra su estado antes de retirar acceso. El objetivo es comprobar las capacidades reales, no limitarse a observar que desaparece una cuenta del panel.

Si una tarea sigue actuando con una cuenta de servicio, atribuye el permiso a esa cuenta. Desactivar el agente visible no revoca automáticamente las identidades ajenas. El inventario debe permitir localizar quién administra la credencial y qué otros procesos dependen de ella antes de retirarla.

El acta del simulacro necesita describir la ventana entre la orden de corte y la última acción observada. Cuando no puedas demostrar detención, conserva esa capacidad como excepción abierta y limita el destino por otro control autorizado. No marques cierre solo porque el agente dejó de contestar.

La compensación también necesita autorización propia: cancelar una reserva o retirar un documento enviado puede tener consecuencias diferentes de detener al agente. Primero determina qué ocurrió y después acuerda la corrección con el responsable del proceso.

Por qué importa ahora

Los agentes persistentes acumulan conexiones y tareas que sobreviven a una conversación. Esa continuidad aporta utilidad y también exige un procedimiento de baja comparable al que se diseña para otras identidades con acceso operativo.

Anti-ejemplo

Caso hipotético: se desactiva un agente comercial tras un cambio de equipo. Sus tareas programadas siguen llamando a una integración con una cuenta de servicio compartida. El usuario ya no puede conversar con él, pero los correos pendientes continúan saliendo.

Protocolo (3 pasos)

Relacionado

• Identidad de agente: el acceso necesita patrocinador y fecha de caducidad
• El token no se hereda: identidad y audiencia en cadenas de agentes

Fuentes consultadas

• Model Context Protocol — Authorization
• OpenClaw — Seguridad del gateway

Próximo paso

Ensaya la baja de un agente de prueba con trabajo pendiente. Documenta qué controles detienen nuevas acciones y qué operaciones requieren una comprobación adicional.