Lista de comprobación para retirar agentes de IA de forma controlada

La salida de un empleado es uno de los pocos momentos en que el control de acceso se pone a prueba contra el reloj. El procedimiento habitual para desactivar una cuenta no basta con los agentes de IA, porque el trabajo útil suele ejecutarse mediante procesos locales, tareas desatendidas, credenciales API compartidas, material SSH y configuraciones copiadas fuera de la identidad de la persona que se marcha.

Trata la salida como una transferencia controlada de autoridad, no como una tarea de limpieza informática. Hay que detener las acciones nuevas, identificar el trabajo que ya está en curso, sustituir la autoridad compartida y conservar los registros antes de que alguien borre las pruebas que explican lo ocurrido.

Desactivar una identidad no revoca todas las rutas hacia producción

Desactivar una cuenta de directorio solo detiene las rutas de acceso que consultan ese directorio en el momento de uso. No revoca un token API guardado en un archivo de configuración local, una clave privada SSH cargada en el espacio de trabajo del agente, un token de acceso a la nube emitido anteriormente ni una credencial de servicio compartida inyectada por un trabajo de CI.

Esta diferencia se difumina porque una persona, un proceso de agente y una credencial suelen aparecer bajo el nombre de un mismo empleado en un panel. Son cosas distintas y requieren acciones diferentes:

• Una identidad humana indica quién se autenticó.
• Un proceso de agente local indica qué puede hacer ahora mismo en el equipo del empleado.
• Una credencial indica qué aceptará un servicio remoto.
• Una sesión o un trabajo indica qué puede estar ejecutándose ya.
• Un registro de auditoría indica qué se podrá demostrar más adelante.

Confundir estas diferencias provoca un fallo conocido. Recursos humanos marca la salida del empleado a las 09:00. TI desactiva el inicio de sesión único a las 09:05. A las 09:20, una tarea programada del agente se ejecuta en un portátil que aún no se ha recuperado. Usa un token de despliegue compartido guardado en su entorno y cambia una configuración de producción. Todos los equipos implicados pueden afirmar con sinceridad que eliminaron la cuenta del empleado. Ninguno eliminó la autoridad que utilizó el agente.

Inicia el ticket de salida con una pregunta concreta: «¿Qué acciones podrían seguir realizándose si el inicio de sesión habitual del empleado dejara de funcionar?». No aceptes «su cuenta está desactivada» como respuesta.

NIST SP 800-53 coloca los controles relacionados en familias separadas por un motivo. AC-2 cubre la gestión de cuentas, IA-5 la gestión de autenticadores y AU-9 la protección de la información de auditoría. Los equipos que reducen los tres aspectos a una sola casilla suelen descubrir el trabajo pendiente después de un incidente.

Congela las rutas de acción antes de recoger el portátil

Detén primero la autoridad remota, porque la recogida física puede tardar horas y un portátil encendido puede seguir funcionando. La persona que gestiona la salida debe avisar al responsable de seguridad y a los responsables de los servicios. Después, debe establecer una breve suspensión de las acciones automatizadas atribuibles a la persona que se marcha o a su estación de trabajo.

La primera revisión debe cubrir estas rutas:

1. Revoca las sesiones remotas activas cuando el proveedor de identidad, la nube, el servicio de control de código fuente o el sistema de acceso privilegiado lo permitan.
2. Desactiva o aísla los ejecutores de compilación registrados, los trabajos de agentes programados y las sesiones de desarrollo remoto propiedad del empleado.
3. Retira el dispositivo de los accesos de dispositivo de confianza, VPN y gestión cuando el proceso operativo lo permita.
4. Pausa las tareas desatendidas que puedan desplegar, modificar infraestructura, enviar mensajes o escribir en sistemas de clientes.
5. Recupera la estación de trabajo o colócala bajo restricciones de red gestionadas antes de que la persona deje de estar bajo supervisión.

No empieces borrando archivos locales. Si la salida está en disputa, es inusual o relacionada con un problema de seguridad, conserva el estado del dispositivo conforme al procedimiento de incidentes. Un borrado apresurado destruye el historial de shell, las transcripciones del agente, la configuración local, las colas de trabajos y las marcas de tiempo que pueden indicar si una acción estaba autorizada.

En una salida ordinaria planificada, el responsable de seguridad puede decidir que se aplican las reglas normales de devolución y reinstalación del dispositivo. Esa decisión debe aparecer en el ticket. No debe depender de la memoria de alguien.

Un punto de control útil es el límite del proceso del agente. Registra la ruta del ejecutable, el proceso padre, el identificador del proceso, la hora de inicio, el directorio de trabajo y la autoridad de firma de código antes de terminar un agente que se esté ejecutando localmente. En macOS, un operador puede obtener una instantánea básica del proceso así:

ps -axo pid,ppid,user,lstart,command | grep -i '[a]gent'

# Output shape:
# 8421   611 alice  Tue Mar 12 09:14:22 2025 /usr/local/bin/agent-run --task release

El comando no constituye una prueba por sí solo. Proporciona a la persona investigadora una pista acotada en el tiempo y evita que la afirmación imprecisa «había un agente en ejecución» se convierta en todo el registro.

Crea un inventario de autoridades, no de programas

Una lista de herramientas de IA instaladas no indica quién puede modificar un servicio. Haz un inventario de todas las rutas de autoridad, incluidas las herramientas que quizá no consideres IA. El empleado puede haber usado un agente desde un terminal, una extensión del editor, un ejecutor de CI, un script local o un entorno remoto. Importa más la ruta que la etiqueta.

Usa una fila por cada relación entre credencial e identidad. Si un token puede acceder a tres servicios, enumera sus tres consecuencias en el campo de alcance, en lugar de ocultarlas en las notas.

La parte difícil es encontrar la autoridad compartida. Haz preguntas directas a los responsables de los servicios: ¿Conoce esta persona un token que sobreviva a su cuenta? ¿Administraba una cuenta de bot? ¿Puede su dispositivo conectarse con una clave SSH? ¿Se ejecutaba algún trabajo con una identidad genérica? ¿Quién recibirá las alertas de ese trabajo a partir de hoy?

No conviertas a la persona que se marcha en la única fuente de este inventario. Puede ayudar, pero los repositorios, almacenes de secretos, archivos authorized_keys, configuraciones de CI, registros de propiedad de los servicios y registros de auditoría deben confirmar la respuesta. La gente olvida un token creado durante una interrupción. También olvida un ejecutor de pruebas que se convirtió en infraestructura de producción dos años después.

Rota las credenciales compartidas siguiendo el orden de dependencias

Rota cualquier credencial compartida que la persona que se marcha pudiera haber leído, copiado, exportado o utilizado fuera de una ruta fiable de revocación vinculada a una identidad. Esto incluye claves API, contraseñas de autenticación básica, secretos de webhooks, tokens de despliegue, contraseñas de bases de datos, claves SSH, claves de acceso a la nube y códigos de recuperación.

La recomendación popular, pero incorrecta, es rotarlo todo simultáneamente. Parece una medida contundente y produce una lista impresionante de secretos modificados. También rompe dependencias desconocidas, vuelve caótico el diagnóstico y tienta a los equipos a restaurar el secreto anterior bajo presión. Rota las credenciales siguiendo una secuencia que mantenga abierta una ruta de reemplazo con una persona responsable.

Para cada credencial, sigue este orden:

1. Nombra al responsable del servicio y a los clientes exactos que usan la credencial.
2. Crea una credencial de reemplazo con el alcance más limitado que admita el servicio.
3. Actualiza los clientes conocidos y demuestra que funcionan con el reemplazo.
4. Revoca la credencial anterior y comprueba después que falla.
5. Registra la persona responsable del reemplazo, su hora de creación, su alcance y el resultado de la revocación.

La prueba de fallo importa. «Rotación completada» suele significar que alguien creó un token nuevo y actualizó una aplicación. No significa que el token anterior haya dejado de funcionar. Ejecuta una solicitud autenticada inocua que la credencial anterior permitiera realizar. Registra la respuesta de denegación esperada del servicio, como HTTP 401 o 403, sin pegar secretos en el ticket.

Para el acceso SSH, elimina la clave pública de la persona que se marcha de todas las fuentes authorized-keys de destino y de cualquier sistema de acceso central. Después, busca la automatización que use la misma clave privada. Si un agente utilizaba una identidad SSH compartida, emite un nuevo par de claves, sustituye la parte pública en los destinos, actualiza el cliente autorizado y retira la clave pública anterior. Eliminar una clave solo de la estación de trabajo no sirve de nada si existe una copia.

No envíes el reemplazo por chat o correo electrónico como parte de la transferencia. Da al nuevo responsable permiso para obtenerlo o utilizarlo mediante el mecanismo de secretos aprobado. El objetivo de la rotación es reducir el número de copias que no puedes contabilizar.

Las cuentas compartidas necesitan una persona responsable identificada

Una cuenta de servicio puede ser legítima, pero una cuenta compartida sin una persona operadora identificada oculta un problema de propiedad. La transferencia debe nombrar a alguien que acepte la responsabilidad del propósito, alcance, facturación, vía de recuperación y futura rotación de credenciales de la cuenta.

Separa la responsabilidad operativa de la credencial. Un bot de versiones puede tener que seguir desplegando después de que se marche un empleado. Eso no significa que la persona sustituta deba heredar el token personal del antiguo empleado ni utilizar su configuración local. Da al bot su propia identidad cuando el servicio lo permita, asígnale solo los permisos que necesita y haz responsable de él a la nueva persona encargada.

Redacta un registro breve de transferencia que responda a cinco puntos:

• ¿Qué servicio o flujo de trabajo admite la cuenta?
• ¿A qué entornos y acciones puede acceder?
• ¿Qué sistemas la utilizan hoy?
• ¿Quién puede cambiar sus credenciales o recuperarla?
• ¿Cuándo revisará alguien si todavía necesita este acceso?

Aquí también aparecen supuestos del agente disfrazados de comodidad. Una configuración local puede indicar al agente que use una identidad de despliegue genérica porque la persona desarrolladora original no tuvo tiempo de configurar una dedicada. No mantengas ese atajo en nombre de la continuidad. Sustitúyelo por una ruta de acceso con una persona responsable antes de reanudar el trabajo.

Conserva los registros antes de que los trabajos de retención los borren

Conserva los registros que permitan reconstruir la autoridad y las acciones sin depender de la explicación de la persona que se marcha. Captura el ticket de salida, el inventario de accesos, el evento de desactivación de identidad, las revocaciones de sesión, los eventos de rotación, el historial de trabajos de CI, los registros de ejecución del agente, la decisión sobre la recogida del endpoint y las exportaciones de auditoría de los servicios. Registra la zona horaria y la fuente del reloj si los sistemas difieren.

Conservar no equivale a copiar unas pocas capturas de pantalla. Una captura pierde campos, oculta filtros y rara vez se puede verificar. Exporta los registros originales en su formato nativo cuando sea posible, conserva hashes de los archivos recogidos, limita el acceso al grupo del caso y documenta quién manipuló cada copia.

La siguiente nota de recogida es lo bastante breve para usarla y lo bastante específica para auditarla:

Case: OFF-2025-041
Collected by: security-operator
Collected at: 2025-03-12T09:37:16Z
Source: build-service job history export
Range: 2025-03-01T00:00:00Z to 2025-03-12T09:37:16Z
File: build-jobs.json
SHA-256: <recorded digest>
Storage: restricted evidence repository
Reason: employee exit and agent authority review

Mantén la exportación original sin cambios. Si una persona investigadora la filtra o anota, guarda el resultado como una copia de trabajo independiente. Esta separación sencilla ha evitado más discusiones que las herramientas forenses complejas: se puede revisar el análisis sin modificar discretamente el registro de origen.

NIST SP 800-92 describe la gestión de registros como un proceso de generación, transmisión, almacenamiento, análisis y eliminación. El punto débil de la salida suele ser la eliminación. Un periodo de retención predeterminado corto puede borrar el único registro de ejecución necesario para establecer si un agente actuó antes o después del cambio de acceso. Aplica una retención preventiva a los registros que tu política permita conservar y libera después esa retención mediante el proceso habitual.

Haz que la autorización del agente se pueda revocar por proceso

La aprobación de una persona desarrolladora para un proceso de agente no debe convertirse en un permiso general para cualquier proceso que pueda aparecer en su equipo. Un proceso puede sustituirse, reiniciarse desde otro directorio de trabajo o ser invocado por una extensión del editor después de que la persona se marche. El registro de autorización necesita identificar el proceso y ofrecer una ruta de revocación inmediata.

Aquí puede ayudar una pasarela, pero solo si se niega a entregar las credenciales al agente. Sallyport mantiene las credenciales API y SSH en una bóveda local cifrada, autoriza por defecto los procesos nuevos de agentes por sesión y registra por separado las sesiones y las acciones individuales.

Durante la salida, exporta o conserva los registros de sesión y actividad pertinentes, revoca las sesiones activas y bloquea la bóveda antes de transferir el dispositivo. Ese orden establece un límite útil: el agente no puede realizar una nueva llamada externa mientras el registro de sus llamadas anteriores sigue disponible para revisión.

No confundas la aprobación por sesión con la aprobación de todas las acciones importantes. Un agente puede necesitar legítimamente una sesión para leer un repositorio, mientras que cada credencial que cambie producción puede requerir confirmación en cada uso. Aplica el control más estricto a las credenciales cuyo uso indebido obligaría a responder a un incidente, no a las llamadas inocuas de solo lectura que acabarían provocando fatiga por aprobaciones.

La fatiga por aprobaciones es un fallo de diseño. Si las personas reciben un aviso por cada solicitud rutinaria, dejan de leerlos. Si reciben un aviso que cubre silenciosamente el acceso a sistemas de producción no relacionados, el aviso es demasiado amplio. Una buena autorización crea un límite claro que un operador pueda explicar después.

Inspecciona el trabajo en ejecución y los activadores retrasados

La revocación de una cuenta no detiene de forma fiable el trabajo que un servicio remoto ya ha aceptado. Comprueba las compilaciones en cola, los shells remotos, las programaciones de automatización, los flujos de trabajo de repositorios, los trabajos de publicación de paquetes, los planes de infraestructura y las colas de mensajes que puedan iniciar trabajo más adelante.

Para cada elemento en ejecución o en cola, decide si cancelarlo, dejar que termine bajo observación o transferirlo a una nueva persona responsable. La decisión debe depender de la acción, el alcance del impacto y la posibilidad de reproducir la tarea. Puede permitirse que termine un despliegue con un cambio conocido y registrado. Una tarea que pueda modificar controles de acceso o mover datos normalmente debe detenerse hasta que su responsable confirme la intención.

Captura los identificadores antes de cancelar. Una URL de trabajo por sí sola es una prueba débil si el servicio elimina los detalles del trabajo después de un periodo de retención. Guarda el ID del trabajo, la identidad que lo activó, la referencia del commit o de la tarea, las horas de inicio y finalización, los permisos utilizados y el resultado. Si la tarea falló durante la salida, indica si el fallo fue consecuencia de tu revocación. De lo contrario, una futura investigación podría interpretar un éxito del control de acceso como un problema operativo.

Revisa también la ejecución retrasada. Las entradas de cron, los agentes de lanzamiento, las programaciones de CI, las reglas de eventos de la nube y los flujos de trabajo de repositorios pueden reanudar la actividad cuando el equipo crea que la salida ya terminó. Una tarea recurrente debe pasar a una persona responsable gestionada o desactivarse. Dejarla activa bajo una cuenta abandonada hace que el siguiente fallo sea previsible y difícil de diagnosticar.

Cierra el proceso solo cuando una persona independiente pueda verificar el resultado

La persona que realiza los cambios no debe ser la única que declare completada la salida. Pide a un compañero de seguridad, al responsable del servicio o a un manager que verifique los puntos más importantes: la antigua identidad no puede iniciar sesión, las credenciales compartidas anteriores fallan, no queda trabajo programado del agente bajo la antigua persona responsable y la recopilación de pruebas se puede leer y está protegida.

Usa una declaración de cierre que nombre hechos comprobados, no una finalización imprecisa:

Former identity: disabled and active sessions revoked
Shared credentials: 6 inventoried, 6 replacement paths tested, 6 prior credentials revoked
Agent work: 2 scheduled jobs transferred, 1 queued job canceled
Evidence: exports and collection hashes stored under case OFF-2025-041
Exceptions: none
Verified by: service owner and security reviewer

Si una credencial no puede rotarse de inmediato, mantén abierto el ticket y registra la restricción compensatoria, la persona responsable y la fecha límite. «Lo haremos más adelante» no es un control. Una restricción del firewall, un flujo de trabajo desactivado o una suspensión temporal del servicio pueden ser controles si alguien los verifica y sabe cuándo caducan.

El primer cambio útil es sencillo: añade un inventario de autoridades y una decisión sobre la retención de pruebas al ticket de salida de recursos humanos que ya existe. Esos dos campos obligan a mantener la conversación adecuada antes de que desaparezca un portátil, sobreviva un token o un trabajo de retención elimine el único registro de una acción del agente.