Lista de comprobación para transferir el acceso de un agente de IA durante un cambio de puesto

Un cambio de puesto es el momento en que un modelo de acceso para agentes de IA demuestra que funciona o se desmorona en silencio. Los equipos suelen transferir los permisos del repositorio y olvidar la ruta de credenciales que permite a un agente llamar a API de producción, abrir una sesión SSH o activar un despliegue. El agente sigue funcionando, pero nadie puede decir quién puede aprobarlo, quién revisa sus registros o quién puede detenerlo a las 2 de la madrugada.

Una lista de comprobación para el relevo de accesos de un agente de IA debe transferir cuatro responsabilidades distintas: la custodia de las credenciales, la autoridad para aprobar acciones, la responsabilidad de revisar la auditoría y la autoridad para actuar durante un incidente. Tratar todo eso como una idea vaga de «propiedad» es la forma de que un desarrollador que ya se ha marchado siga siendo, en la práctica, el responsable de una ruta de producción mucho después de cambiar de puesto.

Un cambio de puesto transfiere autoridad, no solo secretos

El equipo debe transferir la capacidad de autorizar y justificar las acciones del agente, aunque la credencial nunca salga de su almacenamiento seguro. Un secreto puede permanecer en la misma bóveda y, aun así, cambiar su propietario, el uso permitido, la persona que lo aprueba y quien lo revisa. Son datos distintos y cada uno necesita una respuesta registrada.

Empieza por separar a las personas que suelen quedar reducidas a un solo nombre:

• El custodio de la credencial puede rotar, desactivar o sustituir el secreto.
• El propietario del servicio decide si el agente debe conservar el acceso a ese sistema.
• La persona aprobadora acepta o rechaza una acción solicitada cuando se requiere aprobación.
• El revisor de auditoría comprueba lo que hizo realmente el agente y hace seguimiento de las excepciones.
• La persona responsable de revocar en una emergencia puede detener el acceso cuando el propietario habitual no está disponible.

En los equipos pequeños, las cinco responsabilidades suelen recaer en un mismo ingeniero. Puede ser razonable para una credencial de desarrollo limitada, pero hay que dejarlo claro y nombrar un sustituto. De lo contrario, unas vacaciones, una salida inesperada o una disputa sobre permisos convierten a una persona ausente en una dependencia operativa difícil de sustituir.

No confundas la propiedad del repositorio con la autoridad para actuar. Un desarrollador puede perder el acceso de escritura a un repositorio mientras un proceso de agente que configuró anteriormente sigue pudiendo llegar a un gestor de incidencias, una API en la nube o un host de producción. A la inversa, un nuevo responsable de equipo puede ser el propietario del repositorio, pero no tener autoridad para aprobar el uso de una credencial de lanzamiento por parte del agente. Revisa ambos planos por separado.

He visto fracasar relevos porque la persona entrante recibió una lista de nombres de API, pero no el motivo de la existencia de cada credencial. Un registro que dice «token de despliegue» no le dice casi nada al sucesor. Indica el servicio de destino, la acción permitida, el entorno, el propietario, el modo de aprobación y el método de rotación. Si nadie puede explicar en una frase para qué sirve una credencial, desactívala hasta que pueda hacerlo.

Congela los cambios antes de transferir la responsabilidad

Pausa los nuevos cambios de acceso de los agentes mientras dure el relevo. Un objetivo que se mueve produce un documento de relevo que ya era incorrecto cuando alguien lo firmó.

La congelación no significa apagar durante una semana todas las ejecuciones de agentes. Significa que nadie añade credenciales, amplía permisos, cambia la configuración de aprobación ni concede acceso a una máquina nueva sin que los propietarios saliente y entrante registren el cambio. Mantén el periodo breve y explícito. En un cambio de puesto planificado, empieza cuando se conozca la fecha y termina antes de que la persona pierda el acceso. Ante una salida repentina, revoca primero y reconstruye el inventario a partir de los registros.

Deja claro el alcance. Incluye los procesos de agentes que se ejecutan en los equipos de los desarrolladores, las automatizaciones programadas, los trabajos de CI que invocan a un agente y los entornos de prueba que contienen credenciales reales. Los equipos suelen olvidar las herramientas locales porque no aparecen en la consola de la nube. El acceso local sigue llegando a sistemas externos.

Un aviso de congelación útil responde a cuatro preguntas prácticas:

1. Qué credenciales y puntos de conexión entran en el relevo.
2. Quién puede aprobar una excepción durante la congelación.
3. Dónde se guardan el inventario actual y los registros de acciones.
4. Cuándo acepta la responsabilidad el nuevo propietario.

No aceptes un «ya lo limpiaremos» para las credenciales que tocan producción o datos de clientes. Ese «después» es el momento en que alguien descubre que un agente aún tiene un token que ningún empleado recuerda haber creado. Una congelación breve cuesta menos que una rotación de emergencia hecha sin saber qué automatizaciones dejarán de funcionar.

Aquí importa una distinción: revocar la cuenta de una persona no equivale a revocar la autoridad de un agente. Una credencial puede pertenecer a una cuenta de servicio compartida. Una aprobación puede estar vinculada a un proceso de agente local. Una clave pública SSH puede autorizar un host independientemente de la cuenta del proveedor de identidad del desarrollador saliente. El relevo debe encontrar cada ruta, no limitarse a cerrar la cuenta del empleado.

Crea un registro que describa el uso, no los valores secretos

El registro del relevo debe identificar las credenciales sin copiar material secreto en una hoja de cálculo o un ticket. La persona entrante necesita un mapa operativo, no otra bóveda menos protegida llena de tokens.

Usa un identificador opaco, una huella digital o el nombre del registro en la bóveda. Para el material SSH, registra la huella de la clave pública y los hosts autorizados. El equipo puede inspeccionar una huella pública sin exponer la clave privada:

ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)

La huella exacta será distinta. Lo importante es que el registro incluya el identificador resultante, la cuenta del host y el motivo por el que existe la clave. No pegues nunca una clave privada ni un token bearer en el documento del relevo para que quede «completo». Eso crea un nuevo punto de fuga y dificulta comprobar la rotación.

Copia esta estructura en la documentación operativa protegida del equipo para cada credencial o ruta de acceso:

access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08

Las fechas y los nombres anteriores son ejemplos. Sustitúyelos por personas y fechas reales y protege el registro como metadatos operativos. No contiene un secreto, pero indica a un atacante dónde reside la autoridad.

Incluye el alcance, no solo una etiqueta. «Token de la nube» puede significar acceso de lectura a una cuenta de prueba o acceso de administrador a varias cuentas de producción. Pide al propietario del servicio que confirme el alcance en lugar de aceptar la memoria del desarrollador saliente. Las consolas de los proveedores cambian, las integraciones antiguas permanecen y el nombre que alguien dio a una credencial hace dos años suele tener poca relación con lo que puede hacer ahora.

El registro también necesita una decisión explícita: conservar, rotar, reducir el alcance o revocar. «Transferir» no es una decisión final. Si una credencial ya no se usa, revócala. Los equipos mantienen accesos inactivos porque la rotación parece arriesgada. El acceso inactivo es más difícil de supervisar y más fácil de olvidar.

Las expectativas de aprobación necesitan una decisión humana concreta

Una configuración de aprobación solo ofrece control cuando el equipo acuerda qué responsabilidad asume la persona que aprueba. «Alguien hará clic en permitir» no es una expectativa. Es un vacío que espera a una persona con prisa.

Define si el agente necesita permiso una vez por ejecución o en cada uso de la credencial. Una aprobación de sesión dice: «Reconozco este proceso de agente y le permito realizar durante esta ejecución la clase de acciones que se le ha concedido». Una aprobación por llamada dice: «He revisado ahora este intento concreto de uso». Responden a riesgos distintos.

Usa la aprobación de sesión para trabajos delimitados en los que las solicitudes repetidas podrían enseñar a las personas a aprobar sin mirar. Por ejemplo, un agente que repara una suite de pruebas puede necesitar varias llamadas de lectura y escritura a un servicio de desarrollo. La persona aprobadora debe saber qué proceso solicitó el acceso y cuándo termina la autorización.

Usa la aprobación por llamada cuando una acción individual pueda tener consecuencias importantes: desplegar en producción, eliminar datos, cambiar permisos, enviar mensajes fuera de la organización o usar una credencial de amplio alcance. La pausa adicional es intencionada. Si una acción es demasiado rutinaria para merecer una decisión humana, reduce el alcance de la credencial o mueve la operación a una automatización revisada. No resuelvas la fatiga de las solicitudes dando una aprobación de sesión amplia a todas las credenciales sensibles.

Durante el relevo, registra estas expectativas con un lenguaje sencillo:

• La persona o el rol que puede aprobar cada clase de acción.
• Las situaciones que requieren aprobación por llamada.
• Las pruebas que debe revisar la persona aprobadora antes de permitirla.
• La condición de caducidad de una autorización de sesión.
• La persona aprobadora sustituta cuando el propietario habitual esté ausente.

Las pruebas pueden ser sencillas, pero deben ser concretas: entorno de destino, operación solicitada, identidad de la credencial, proceso de agente de origen y resultado esperado. Una persona aprobadora no puede decidir bien a partir de un mensaje genérico que solo diga que un agente quiere acceso.

Una recomendación habitual y equivocada dice que hay que desactivar las aprobaciones cuando el equipo ya «confía» en el agente. Es popular porque las solicitudes interrumpen el trabajo. Es incorrecta porque confiar en el código que genera un agente no le concede autoridad para usar todas las credenciales externas. Reduce las aprobaciones cuando la ruta de acción tiene un alcance limitado y buenas pruebas. Manténlas cuando las consecuencias requieran a una persona capaz de explicar por qué lo permitió.

La revisión de auditoría corresponde a una persona y a un horario

Los registros no crean responsabilidad por el mero hecho de existir. El relevo debe indicar quién revisa la actividad del agente, qué busca y qué hace cuando una entrada no tiene sentido.

NIST Special Publication 800-53 separa la gestión de cuentas en el control AC-2 de la revisión de auditoría en AU-6. Esta separación encaja bien con el acceso de los agentes. La persona que gestiona una credencial puede no ser la adecuada para juzgar si el uso que hizo el agente coincidía con el trabajo aprobado. Una revisión independiente detecta errores y suposiciones convenientes.

Establece una frecuencia de revisión que corresponda al acceso. Una credencial de producción usada para lanzamientos puede requerir una revisión después de cada lanzamiento y de cualquier intento fallido o rechazado. Una integración de desarrollo de bajo impacto puede revisarse con una periodicidad programada. No escribas «periódicamente». Esa palabra sobrevive a todas las reuniones perdidas porque no promete nada.

El revisor debe responder a un conjunto breve de preguntas a partir del registro de acciones:

• Qué proceso de agente hizo la solicitud y quién autorizó esa ejecución.
• Qué credencial o ruta de acceso utilizó.
• A qué destino llegó y qué resultado recibió.
• Si la solicitud encajaba en una tarea o registro de cambios concreto.
• Si alguna acción rechazada, repetida o inesperada necesitaba investigación.

Exige que el revisor registre una decisión para los eventos inusuales: esperado, corregido, escalado o sin resolver. El equipo no necesita un informe ceremonial por cada lectura inofensiva de una API. Sí necesita una decisión visible cuando un agente llega a producción fuera de una ventana planificada o solicita repetidamente una credencial que no debería necesitar.

Conserva los registros antes de rotar o revocar si existe la posibilidad de un incidente. La rotación corrige la exposición futura, pero no explica las acciones pasadas. Asegúrate de que el nuevo revisor conozca la ubicación de conservación, quién puede exportar los registros y cómo comprobar su integridad. Un rastro de auditoría que solo un ingeniero saliente puede interpretar es un diario privado, no un registro operativo.

Ensaya la revocación antes de la fecha de salida

Un plan de revocación no está completo hasta que el equipo lo prueba con una solicitud inofensiva. El primer intento no debe producirse durante un incidente, cuando todos intentan adivinar si un rechazo significa que el control funcionó o que el servicio está averiado.

Repasa un fallo frecuente. Un desarrollador cambia de equipo y pierde el acceso al control de código fuente. Su configuración antigua del agente sigue ejecutándose en un portátil gestionado con una credencial de despliegue compartida. La credencial sigue siendo válida porque pertenece a la cuenta de servicio de lanzamiento, no al desarrollador. Un compañero pide al agente que «compruebe el estado del lanzamiento» y el agente todavía puede llamar al endpoint de producción. El equipo creyó que la baja se había completado porque se desactivó la cuenta del empleado. No había cerrado la ruta compartida.

Prueba la ruta real. El propietario del servicio puede organizar una solicitud no destructiva, como leer el estado de un destino de prueba, con la autorización saliente. Después revoca la autorización antigua, desactiva la credencial o elimina la ruta permitida según lo que requiera el relevo. Repite la solicitud y confirma tres hechos: el acceso falla, el fallo tiene el motivo esperado y el registro de auditoría identifica el intento.

Esta prueba descubre algo más que una credencial olvidada. Detecta configuraciones locales obsoletas, una segunda copia de una autorización SSH, automatizaciones que usan una cuenta de servicio inesperada y un revisor que no encuentra el registro correspondiente.

Mantén la prueba acotada. No necesitas ejecutar operaciones destructivas para demostrar la revocación. Una llamada de estado rechazada o un intento de conexión denegado aportan pruebas suficientes si la pasarela de acceso lo registra correctamente. Documenta el comando o la solicitud utilizada, el resultado esperado, el resultado real y la persona que presenció la prueba.

Si la prueba falla, no cierres el relevo con la promesa de investigarlo. Trata esa credencial como activa y con una responsabilidad poco clara. Escala el caso a la persona responsable de revocar en una emergencia, restringe la ruta de acceso e identifica todos los lugares que almacenaron en caché o reutilizaron la autorización. La prueba fallida cumple su función al descubrir la ruta mientras la persona saliente aún puede responder preguntas.

Los contactos de emergencia necesitan autoridad y una vía activa

Los contactos de emergencia no son un campo de directorio. Son las personas que pueden tomar una decisión urgente cuando un agente intenta realizar una acción insegura o cuando el propietario habitual no responde.

Nombra un contacto principal y uno sustituto para cada grupo de acceso sensible. Incluye la vía para contactar con ellos durante un incidente, el alcance que pueden revocar y el propietario del servicio que decide si el acceso se restaura después. No incluyas un buzón general del equipo como único contacto de emergencia. Los buzones reciben mensajes, pero no asumen responsabilidades.

Define las condiciones de activación en términos operativos. Algunos ejemplos son una acción del agente fuera de un cambio aprobado, autorizaciones fallidas repetidas, un proceso nuevo e inesperado que solicita una credencial de producción o un registro de auditoría que no puede asociarse con ningún trabajo. El contacto debe saber si tiene que pausar todas las acciones de los agentes, revocar una sola credencial, desactivar una cuenta de host concreta o llamar al propietario del servicio.

Un buen relevo también contempla el caso incómodo en que la persona responsable de revocar en una emergencia sea quien cambia de puesto. Transfiere esa capacidad antes de que el cambio sea efectivo y prueba después que la persona sustituta puede actuar. Evita compartir un secreto de «romper el cristal» por el chat. Eso destruye la atribución y suele permanecer en el historial de alguien mucho después de terminar la emergencia.

Escribe también la regla de restauración. La revocación de emergencia debe ser sencilla; la restauración debe exigir que el propietario del servicio confirme el alcance, que el revisor de auditoría examine el evento y que el nuevo custodio acepte la credencial. Los equipos que omiten esta regla suelen restaurar un acceso amplio solo para que desaparezca una tarea bloqueada.

Una pasarela debe hacer visible el relevo

Una pasarela de acciones local puede reducir el número de puntos en los que falla este relevo, pero no sustituye las decisiones sobre responsabilidades. Sallyport mantiene las credenciales en una bóveda cifrada, exige que la bóveda esté abierta antes de ejecutar acciones y registra tanto las ejecuciones de los agentes como las llamadas individuales, lo que ofrece al revisor del relevo lugares concretos que inspeccionar.

Su distinción entre autorización de sesión y aprobación por llamada resulta útil al redactar las expectativas anteriores. La persona entrante debe decidir qué credenciales necesitan una nueva decisión humana en cada uso, en lugar de heredar la configuración cómoda que eligió el desarrollador saliente.

Para su registro de auditoría cifrado y encadenado mediante hashes, el nuevo revisor puede ejecutar este comando de verificación sin conexión:

sp audit verify

Un resultado correcto debe indicar que la verificación se completó correctamente; un resultado fallido debe indicar que la verificación falló, en lugar de tratar el registro como fiable sin avisar. Ejecútalo como parte de las pruebas del relevo y guarda el resultado junto con el registro. El comando verifica la cadena sobre el texto cifrado y no necesita la clave de la bóveda, lo que resulta útil cuando el revisor debe comprobar los registros sin recibir acceso a las credenciales.

No conviertas la pasarela en un proyecto general de políticas. Un documento extenso de reglas, con excepciones para cada equipo, envejecerá mal y hará más difíciles los relevos. Mantén claros los puntos de decisión: ¿puede la bóveda permitir alguna acción?, ¿tiene autorización esta ejecución del agente?, ¿esta credencial requiere una persona en cada uso? Después, asegúrate de que personas concretas sean responsables de las respuestas.

La aprobación final debe demostrar que el equipo puede operar sin la persona saliente

Cierra el relevo solo después de que el equipo entrante haya demostrado que controla cada ruta activa. Un documento firmado sin una prueba de revocación, un revisor nombrado y una vía de escalado operativa es papeleo, no una prueba.

Usa esta lista final para cada grupo de credenciales incluido en el alcance:

1. El registro identifica el servicio, el alcance, el custodio, la persona aprobadora, el revisor, el sustituto y la persona responsable de revocar en una emergencia.
2. El propietario del servicio eligió conservar, rotar, reducir el alcance o revocar, y el equipo registró el resultado.
3. La persona aprobadora entrante aceptó por escrito las expectativas de aprobación de sesión y por llamada.
4. El revisor de auditoría localizó registros recientes de acciones y verificó el control de integridad cuando estaba disponible.
5. El equipo probó la revocación o la denegación con una solicitud inofensiva y registró el resultado.

Haz que el desarrollador saliente firme solo para confirmar la exactitud de lo que comunicó, no para asumir acciones futuras después de que termine su puesto. Haz que el nuevo custodio y el propietario del servicio acepten sus responsabilidades por separado. Esta división importa cuando un incidente posterior descubre una ruta de acceso obsoleta: el equipo puede ver si el fallo se debió a una credencial no comunicada, a una rotación no realizada o a un propietario que nunca aceptó el trabajo.

La prueba final es sencilla. Pide a las personas entrantes que respondan, sin llamar al desarrollador saliente: ¿qué agente puede llegar a este servicio?, ¿quién puede aprobarlo?, ¿quién lee el registro? y ¿quién puede detenerlo esta noche? Si alguna respuesta es vaga, el relevo sigue abierto.