Cómo revocar de forma segura el acceso de un agente de IA durante una tarea activa

Un agente de IA activo no necesita tener malas intenciones para provocar un incidente. Una instrucción incorrecta, un permiso de herramientas demasiado amplio, un archivo envenenado del repositorio o un operador confundido pueden llevarlo a un bucle destructivo mientras todavía conserva acceso. La respuesta debe detener rápidamente las acciones nuevas sin perder el registro que explica lo ocurrido.

La reacción equivocada más habitual consiste en cerrar la terminal, revocar todas las credenciales posibles y reconstruir el incidente de memoria a la mañana siguiente. Eso provoca una interrupción mayor y suele borrar la diferencia entre lo que el agente intentó hacer, lo que aceptó un servicio remoto y lo que realmente cambió. Trata un incidente de agente como un trabajo de contención con gestión de evidencias, no como una interrupción vergonzosa que haya que ocultar.

La revocación debe detener la autoridad futura antes de borrar la escena

Revocar un agente significa impedir que realice su siguiente acción privilegiada y, al mismo tiempo, conservar suficiente estado para determinar si las acciones anteriores tuvieron éxito. Cerrar una ventana de chat o de terminal visible puede no cumplir ninguno de esos objetivos. El proceso puede tener procesos hijos, el agente puede mantener abierta una conexión remota y una solicitud HTTP puede seguir ejecutándose después de que el proceso local haya desaparecido.

Separa estas cuatro cosas antes de tocar los controles:

• El proceso del agente es el programa local que genera decisiones y llamadas a herramientas.
• La sesión es la autoridad concedida a esa ejecución concreta del proceso.
• La credencial es el secreto o la identidad que acepta un sistema externo.
• La operación remota es el trabajo que una API, una cola, un host o un plano de control cloud ya aceptó.

La gente suele confundir la revocación de una sesión con la rotación de una credencial. Las consecuencias son importantes. Si rotas un token de despliegue compartido para detener a un agente, puedes romper la automatización de producción mientras la solicitud que el agente ya consiguió enviar sigue ejecutándose. Si solo terminas el proceso del agente después de que haya copiado un token en un espacio de trabajo, puedes dejar atrás un secreto reutilizable.

Por eso, la contención debe seguir el control fiable más cercano al agente. Deniega primero la ejecución activa. Después detén o cancela el trabajo que haya pasado a sistemas remotos. Recurre a la desactivación de credenciales cuando las evidencias indiquen que el secreto podría haber dejado de estar confinado o cuando no puedas confiar en el límite de la sesión.

Escribe una regla sencilla para el incidente antes de necesitarla: la persona que detecte un comportamiento sospechoso puede detener el agente inmediatamente, sin esperar una reunión. La revisión puede hacerse después. Un proceso de aprobación demorado sirve para un despliegue, no para retirar autoridad a un proceso activo.

Crea un mapa de acciones antes del primer incidente

No puedes revocar lo que no puedes identificar. Cada ejecución del agente necesita un identificador que aparezca en el registro del proceso local, en los registros de herramientas y en las solicitudes que lleguen a los sistemas remotos. Basta con un ID de ejecución aleatorio si lo transmites de forma coherente. No uses el nombre de una persona ni una etiqueta vaga como coding-agent; ambas opciones mezclan actividades independientes en el mismo grupo.

Para cada ruta por la que un agente pueda actuar, registra las respuestas a estas cinco preguntas operativas:

1. ¿Qué proceso local controla la ruta y cómo lo detenemos?
2. ¿Qué sesión o token representa a ese proceso ante la puerta de enlace de acciones?
3. ¿Qué operaciones remotas pueden seguir activas después de revocar localmente?
4. ¿Dónde registran esas operaciones los servicios independientes?
5. ¿Quién puede desactivar la ruta si su responsable habitual no está disponible?

No es burocracia por sí misma. Durante un incidente, el operador no debería tener que averiguar si una migración de base de datos pasa por un proceso hijo de shell, un trabajo de CI, una solicitud HTTP o un flujo de trabajo cloud independiente.

Usa el ID de ejecución como encabezado de solicitud siempre que una API lo permita. Para un agente con el ID de ejecución run_2025_04_18_7f3c, un envoltorio puede añadir un encabezado de correlación sin colocar un secreto en la instrucción o el entorno del agente:

export AGENT_RUN_ID="run_2025_04_18_7f3c"
curl -sS -X POST "$ACTION_ENDPOINT" \
  -H "X-Agent-Run-ID: $AGENT_RUN_ID" \
  -H "Content-Type: application/json" \
  --data @request.json

El servicio receptor debe registrar el ID de ejecución junto con el ID de solicitud habitual, la identidad del llamador, el endpoint, el estado de respuesta y la hora. Un registro útil tiene un formato parecido a este:

time=2025-04-18T14:12:09Z request_id=req_91a run_id=run_2025_04_18_7f3c caller=agent-gateway method=POST path=/deployments status=202

Un 202 es importante. Indica que el servicio aceptó el trabajo, no que el trabajo haya terminado. Aquí es donde muchas revisiones de incidentes se equivocan: los equipos toman la última salida de la herramienta del agente como resultado, aunque el sistema remoto solo haya confirmado el envío a una cola.

En SSH, relaciona la cuenta remota, los hosts de destino, los comandos forzados si los hay y el lugar donde se registran los accesos y comandos. La transcripción de una terminal local resulta útil, pero no demuestra que un comando no se ejecutara de forma remota. Los registros del host y el registro de auditoría del servicio correspondiente son los que responden a esa pregunta.

Detén la ejecución activa en un orden que conserve el control

Empieza registrando la hora y el motivo inmediato de la revocación. Después deniega las acciones nuevas y termina el agente. Los comandos exactos dependen del sistema operativo y del entorno de ejecución, pero la secuencia no debería cambiar, porque separa la contención de la limpieza.

1. Registra el ID de ejecución, el ID del proceso local, el operador, el comportamiento observado y la hora actual en el registro del incidente. Copia la transcripción actual del agente y la última llamada visible a una herramienta antes de cerrar su interfaz.
2. Revoca o bloquea la sesión activa en la puerta de enlace que autoriza las acciones. Confirma que una nueva llamada de prueba desde ese mismo proceso recibe una denegación, si existe una operación segura de solo lectura.
3. Suspende el proceso local antes de terminarlo cuando el sistema operativo lo permita. La suspensión te da un árbol de procesos y una lista de archivos abiertos estables. Termínalo solo después de capturar ese estado, salvo que su ejecución continuada vaya a causar un daño inmediato.
4. Encuentra y detén los procesos hijos, trabajos en segundo plano, contenedores y sesiones remotas conectados a esa ejecución.
5. Cancela el trabajo remoto aceptado usando el mecanismo de cancelación del propio servicio y conserva la respuesta y el estado.

En macOS o Linux, empieza con una inspección en lugar de ejecutar un kill -9 a ciegas. Sustituye el ID de proceso de ejemplo por el que hayas registrado:

ps -o pid,ppid,pgid,lstart,command -p 48192
pgrep -P 48192 -a
lsof -nP -p 48192
kill -STOP 48192

El primer comando registra la relación entre procesos y la hora de inicio. pgrep muestra los hijos directos, y lsof suele mostrar archivos del espacio de trabajo, sockets y tuberías abiertos que conviene conservar. kill -STOP congela un proceso cooperativo sin darle otra oportunidad de ejecutar un comando de limpieza. No congela un hijo ya separado, un trabajo remoto ni una solicitud API que haya cruzado el límite de red.

Después de copiar las salidas en la carpeta del incidente, enumera el grupo de procesos. Un proceso puede iniciar un hijo que cambie de grupo, así que no te detengas en un solo comando. Inspecciona los entornos de ejecución de contenedores y los gestores de trabajos en segundo plano que pueda utilizar el agente. Si el agente tiene acceso SSH, revisa también las sesiones activas en cada host de destino.

Cuando la tarea realice trabajo remoto, usa el ID de operación del sistema remoto. Por ejemplo, una API puede devolver esto al aceptar una solicitud:

{
  "operation_id": "op_4e2b7c",
  "status": "queued"
}

Guarda esa respuesta y después llama al endpoint de cancelación documentado o usa la consola del servicio bajo control humano. Registra el resultado de la cancelación. Una respuesta cancel_requested significa que todavía debes consultar la operación hasta que informe de un estado terminal como cancelled, completed u otro. No escribas «detenido» en las notas del incidente solo porque el proceso local haya desaparecido.

Conserva las evidencias antes de restablecer el espacio de trabajo

Recopila las evidencias en un directorio separado para el incidente antes de eliminar ramas, reiniciar servicios o ejecutar un script de limpieza automática. Necesitas un registro ordenado cronológicamente que otro desarrollador pueda revisar sin depender del recuerdo del operador.

Recopila el siguiente material y conserva las marcas de tiempo originales siempre que sea posible:

• La transcripción del agente, las entradas y salidas de las herramientas y la configuración utilizada en la ejecución.
• La salida de la inspección de procesos, los ID de los procesos padre e hijos, las conexiones abiertas y el historial de shell relevante.
• Los registros de sesión de la puerta de enlace y los registros de acciones, incluidas las denegaciones posteriores a la revocación.
• Los eventos de auditoría de los servicios remotos, los ID de operación, los resultados de cancelación y los identificadores de los recursos modificados.
• El estado del repositorio: commit actual, diff, archivos sin seguimiento y artefactos generados.

Calcula el hash de los archivos después de recopilarlos. Un manifiesto sencillo permite a los revisores posteriores detectar modificaciones accidentales mientras las copias pasan entre el ingeniero de guardia, el equipo de seguridad y el desarrollador responsable del sistema afectado:

mkdir -p incident-run_2025_04_18/evidence
cp agent-transcript.txt incident-run_2025_04_18/evidence/
ps -o pid,ppid,pgid,lstart,command -p 48192 > incident-run_2025_04_18/evidence/process.txt
shasum -a 256 incident-run_2025_04_18/evidence/* > incident-run_2025_04_18/SHA256SUMS.txt

El manifiesto resultante debería parecerse a esto:

8f7c...  incident-run_2025_04_18/evidence/agent-transcript.txt
30b1...  incident-run_2025_04_18/evidence/process.txt

Un hash no hace que un archivo sea veraz. Demuestra que el revisor recibió el mismo archivo cuyo hash calculaste. Contrástalo con los registros conservados por sistemas que el agente no podía editar, como el registro de auditoría de un proveedor de API o un servicio central de registros de solo adición.

La guía de gestión de incidentes de seguridad informática de NIST, SP 800-61, trata la contención, la erradicación, la recuperación y el trabajo posterior al incidente como actividades distintas. Esa separación encaja bien con los incidentes de agentes. Los equipos suelen saltar directamente a la erradicación eliminando el directorio de trabajo o rotando un token. Después descubren que la transcripción eliminada contenía el cuerpo exacto de la solicitud necesario para encontrar un recurso remoto.

No copies secretos en la carpeta del incidente solo porque estés conservando el contexto. Registra los identificadores de las credenciales, sus responsables, el alcance, la fecha de creación y los registros del último uso. Guarda los valores reales de los secretos únicamente si tu proceso de incidentes existente lo permite de forma explícita y puede protegerlos. Un archivo de incidentes debe reducir la incertidumbre, no crear otra filtración de secretos.

Un proceso padre muerto no demuestra que el trabajo se haya detenido

Supón que un agente activo puede dejar trabajo atrás hasta que demuestres lo contrario. Los casos más problemáticos no son los comandos de shell llamativos. Son acciones asíncronas corrientes que un desarrollador apenas notaría durante el trabajo normal.

Imagina un agente de programación que publica una solicitud de despliegue, inicia un comando SSH que lanza una migración en segundo plano y después espera las pruebas. El operador ve un destino de producción inesperado y detiene el agente principal. El servicio de despliegue ya aceptó la solicitud, mientras que el shell remoto ha iniciado un comando bajo nohup. Ambos continúan. La última línea de la terminal quizá solo indique que la conexión se cerró.

La revisión necesita tres comprobaciones distintas:

Inspecciona el trabajo aceptado por las API

Busca en el servicio afectado usando el ID de ejecución, el ID de solicitud, la identidad de la cuenta y el intervalo de tiempo. Determina si cada solicitud fue rechazada, puesta en cola, iniciada, completada o cancelada. Para los cambios completados, enumera los ID concretos de los recursos y compara el estado resultante con el estado solicitado.

No dependas únicamente del estado HTTP. Un 200 puede describir un cambio síncrono, un documento de estado o una respuesta de un intermediario. Un 202 suele indicar que se aceptó el procesamiento, pero la documentación del servicio define el significado final. Lee esa documentación antes de crear un procedimiento de cancelación para el servicio.

Inspecciona el trabajo separado del agente

En los sistemas de destino, revisa las sesiones de la cuenta remota, el árbol de procesos, los trabajos programados, los directorios temporales y los registros del servicio. Busca la línea de comandos registrada, el directorio de trabajo, el ID de ejecución o un archivo generado único. Si una tarea remota utiliza un programador de trabajos, cancélala mediante ese programador en lugar de matar un shell que quizá ya no la controle.

Revisa también los callbacks. Un script generado puede haber configurado un webhook, creado un flujo de trabajo de pull request o activado CI. Son actores independientes, con sus propias credenciales y horarios. Revocar el agente original no los revoca.

Por eso una puerta de enlace de acciones limitada es más segura que entregar al agente un shell general con un entorno amplio. Puedes enumerar un número acotado de canales y exigir que cada llamada privilegiada atraviese un punto de control. Un shell lleno de credenciales heredadas convierte cada subproceso en una nueva rama del incidente.

Rota las credenciales solo cuando la exposición lo justifique

Rota una credencial cuando tengas motivos para creer que el agente, sus subprocesos, sus registros o su espacio de trabajo pudieron conservar el secreto. No la rotes solo para aparentar una respuesta. Una rotación general rompe a usuarios legítimos y puede dificultar la revisión si modifica los registros que todavía necesitas inspeccionar.

Estas condiciones justifican la desactivación o rotación inmediata:

• El agente recibió un secreto en texto plano en una instrucción, variable de entorno, archivo de configuración, línea de comandos o salida de una herramienta.
• Una credencial apareció en una transcripción, diff del repositorio, archivo temporal o registro de CI con acceso fuera del equipo del incidente.
• No puedes explicar un proceso hijo, una sesión remota o una conexión saliente que pudiera haber leído el secreto.
• La credencial tiene privilegios amplios y carece de registros fiables de cada uso.
• El proveedor afectado informa de que la credencial se utilizó desde una identidad o ubicación desconocida.

La situación es muy distinta si una puerta de enlace inyectó la credencial y solo devolvió al agente el resultado de la acción. El agente pudo realizar una acción no autorizada, pero no necesariamente tuvo un secreto reutilizable. Desactiva la sesión activa y la ruta de acciones afectada, examina el registro de auditoría y rota la credencial subyacente si la revisión encuentra una ruta para superar ese límite o un problema señalado por el proveedor.

Evita recomendar la rotación de todos los secretos después de cada error de un agente. Es una sugerencia popular porque parece contundente y porque las credenciales filtradas tienen consecuencias graves. Como regla predeterminada es equivocada: confunde el uso no autorizado con la divulgación de credenciales, provoca fallos de producción evitables y enseña a los equipos a dejar de delimitar el problema. Rota con rapidez cuando la divulgación sea plausible. En caso contrario, conserva la capacidad de distinguir la ejecución comprometida de las demás.

Cuando sea necesario rotar, documenta el identificador de la credencial antigua, la hora de desactivación, los sistemas posteriores que la utilizan, el responsable de la sustituta y una prueba que demuestre que la credencial antigua ya no funciona. No pongas ninguno de los dos valores en un ticket ni en una transcripción. Un gestor de secretos o el mecanismo protegido de rotación del proveedor debe encargarse del reemplazo.

El registro del incidente debe permitir una revisión escéptica

Una revisión de incidentes debe permitir que un desarrollador que no estaba de guardia reconstruya la secuencia sin confiar en un único registro mutable. Empieza por la intención del agente y el registro del proceso local y después compara esa versión con los registros de la puerta de enlace y las evidencias del servicio remoto.

Crea una línea temporal con etiquetas explícitas de confianza. Por ejemplo, «el agente propuso la solicitud» procede de una transcripción. «La puerta de enlace ejecutó la solicitud» procede del registro de acciones de la puerta de enlace. «El proveedor aceptó la operación» procede de la entrada de auditoría del proveedor. «El recurso cambió» procede del estado final y del historial de cambios del recurso. Son afirmaciones distintas y merecen evidencias distintas.

Un registro de auditoría de solo escritura encadenado mediante hashes tiene aquí una propiedad útil: el componente que ejecuta las acciones no puede reescribir su historial en silencio después de los hechos. La verificación sobre el texto cifrado también permite comprobar la continuidad sin obtener acceso a todos los secretos o cuerpos de acción. Eso no hace que el registro sea completo. Solo recoge la actividad que atravesó la puerta de enlace, por lo que los registros de los servicios remotos siguen formando parte de la revisión.

Sallyport registra las sesiones de los agentes y las acciones individuales en un único registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify comprueba la cadena sin conexión y sin una clave de bóveda. Así, quien revise un incidente tiene una prueba clara que ejecutar sobre una copia exportada del registro:

sp audit verify /path/to/exported-audit-log

Una verificación correcta confirma la continuidad del registro cifrado que recibiste. Una verificación fallida debe detener la limpieza rutinaria y activar la gestión de evidencias, porque tendrás que determinar si la ruptura se debe a daños durante la exportación, corrupción del almacenamiento o una alteración deliberada.

La revisión debe producir respuestas, no una lista vaga de observaciones. Identifica la instrucción o entrada que activó el incidente, la autoridad concedida a la ejecución, cada acción externa confirmada, cada acción que siga siendo incierta, las credenciales que pudieron escapar y el cambio de control que habría detenido antes el incidente. Si el equipo no puede nombrar el primer control que falló, probablemente añadirá una solicitud de aprobación ruidosa en lugar de corregir la ruta expuesta.

Reanuda el desarrollo con un límite nuevo, no con una sesión reabierta

Los desarrolladores pueden continuar trabajando después de la contención, pero no deberían hacerlo mediante el mismo proceso, el mismo estado del espacio de trabajo ni la misma autorización. La ejecución interrumpida puede conservar instrucciones sin revisar en memoria, contexto obsoleto de la tarea, scripts generados o un proceso hijo que la primera respuesta no detectó.

Crea una ejecución nueva con una identidad de sesión nueva. Revisa el diff del repositorio y los archivos generados antes de exponer la nueva ejecución a credenciales o destinos de producción. Si la tarea anterior debe continuar, entrega a la nueva ejecución un resumen escrito y breve que indique qué acciones remotas se completaron, cuáles siguen canceladas y qué recursos necesitan inspección.

Usa un conjunto de permisos más limitado para la tarea reanudada. Una tarea de revisión de código rara vez necesita autoridad de despliegue. Una tarea que deba consultar producción normalmente no necesita acceso de escritura. No se trata de obligar a todos los desarrolladores a usar un lenguaje de políticas complejo. Se trata de no arrastrar una autorización amplia de ayer a una ejecución que comienza después de un incidente.

La autorización por sesión resulta especialmente útil cuando se inicia un proceso local nuevo después de un evento de detención, porque obliga a una persona a reconocer que se trata de una ejecución diferente. La aprobación por llamada encaja con acciones cuyo coste de una escritura equivocada es lo bastante alto como para justificar una interrupción. Si una tarjeta de aprobación no identifica el proceso que llama y la acción concreta, corrígela antes de confiar en ella durante un incidente.

El primer simulacro debería durar quince minutos: inicia una tarea inofensiva de un agente, revoca su sesión durante una llamada API, conserva los registros locales y remotos y confirma que la tarea no puede reanudarse con su autoridad anterior. Haz el simulacro contra un destino desechable. Encontrarás allí, cuando el coste sea bajo, los ID de solicitud que faltan, los procesos hijos separados y los problemas de acceso a los registros, en lugar de descubrirlos durante un error real en producción.

Convierte la revocación en una acción operativa normal

Un equipo que considera la revocación una emergencia excepcional dudará cuando un agente se comporte de forma extraña. Los controles deben hacer rápida la decisión segura: bloquea el límite de acciones, revoca la sesión, inspecciona lo que ya lo atravesó y deja un registro que sobreviva a la limpieza.

La decisión de diseño más importante es sencilla: separar las funciones. Los agentes pueden planificar y solicitar acciones. Un punto de control local conserva las credenciales, identifica el proceso que solicita, registra la petición y puede denegar ese proceso sin entregarle el secreto. Cuando el operador pulsa el botón de detención, la siguiente llamada privilegiada debe fallar y las anteriores deben seguir disponibles para su revisión.

Comprueba esa afirmación con las herramientas reales que utilizan tus agentes. Si el equipo no puede detener una ejecución activa sin rotar una credencial compartida, no puede relacionar una operación remota con esa ejecución o no puede verificar después su historial de acciones, el flujo de trabajo de incidentes está incompleto.