# Autorización de agentes después de un reinicio: permisos que caducan Reiniciar un Mac crea un límite técnico claro para los equipos. Úsalo. El proceso del agente termina, su memoria desaparece y toda aprobación relacionada con esa ejecución concreta debe terminar con ella. Intentar que el trabajo autónomo continúe de forma invisible después de un reinicio suele convertir un permiso concreto y revisable en un acceso permanente con una caducidad poco clara. Eso no significa que el reinicio deba borrarlo todo. Los equipos necesitan las pruebas que expliquen las acciones anteriores, las credenciales cifradas que permitan el trabajo futuro y suficiente contexto de la tarea para reanudarla de forma deliberada. La regla es sencilla: conserva los registros y los materiales protegidos, pero descarta la autoridad activa. Después, exige que una persona apruebe el proceso recién iniciado antes de que se comunique con el exterior. ## La autorización del agente después de un reinicio debe partir de un estado de ejecución vacío La autorización de un agente tras un reinicio debe comenzar sin permisos activos del proceso, sin una bóveda desbloqueada, sin secretos de sesión heredados y sin aprobaciones recordadas que el proceso nuevo pueda gastar. El reinicio termina el objeto que recibió la aprobación. Tratar el proceso de reemplazo como equivalente porque usa el mismo repositorio, comando o nombre de agente es un error de identidad. A menudo se dice que esto añade fricción después de una actualización del sistema o un corte de corriente. Sí, introduce una pausa intencionada. Esa pausa obliga a revisar el proceso que ahora solicita autoridad, en lugar del proceso que se aprobó horas antes bajo otras condiciones. Un límite de reinicio limpio tiene cuatro ventajas: - Borra materiales volátiles como tokens en memoria, identificadores de claves descifradas, confirmaciones pendientes e identificadores de proceso. - Impide que un agente arrastre una aprobación durante un periodo sin supervisión, cuando la persona responsable puede no estar presente. - Ofrece una marca de auditoría fiable para reconstruir si una acción ocurrió antes o después del reinicio. - Expone dependencias ocultas de cachés locales, auxiliares en segundo plano y multiplexores de conexión. No confundas un reinicio con el cierre de sesión de un usuario. Cerrar sesión también debe terminar la autoridad del agente, pero el reinicio es más fácil de probar porque termina casi todos los procesos normales. Si un permiso sobrevive, alguien lo guardó deliberadamente o creó un auxiliar que vive fuera del ciclo de vida del agente. Ambos casos requieren revisión. La regla se aplica aunque el binario del agente esté firmado y no haya cambiado. La firma de código ayuda a identificar al editor del programa, pero no demuestra que el proceso tenga las mismas instrucciones, variables de entorno, estado del repositorio, configuración de herramientas o intención de la persona operadora que en la ejecución anterior. Un proceso firmado aún puede recibir una instrucción peligrosa después del reinicio. También se aplica a una tarea planificada. Supón que un agente preparó una migración de base de datos, pidió aprobación y el Mac se reinició antes de ejecutarla. El plan puede permanecer en un directorio de trabajo. La autoridad para ejecutarlo no. Tras el reinicio, el agente debe volver a mostrar la operación prevista y la persona responsable debe decidir si sigue siendo correcta. Aquí muchos diseños se vuelven descuidados. Guardan un registro duradero que dice «aprobado» y lo llaman sesión. Ese registro se convierte en un permiso transferible porque un proceso posterior puede reclamarlo. Un permiso de sesión necesita estar vinculado a una instancia de proceso activa y tener una duración breve y definida. Cuando el proceso termina, el registro debe indicar que la autorización terminó, no quedar disponible para reutilizarse. ## Conserva las pruebas y la configuración, pero descarta los permisos activos Un equipo debe conservar los hechos que explican el trabajo y la configuración que pueda reutilizarse sin riesgo, mientras elimina o invalida todo objeto que conceda autoridad inmediata. Coloca estas categorías en almacenes y ciclos de vida diferentes. Mezclarlas produce el problema habitual: un registro de auditoría acaba funcionando accidentalmente como token de autorización. La siguiente separación funciona bien en la práctica: | Conservar después del reinicio | Caducar durante el reinicio | |---|---| | Historial de acciones de solo anexado y decisiones de aprobación | Permiso del proceso del agente y su identificador de ejecución | | Material cifrado de credenciales de API y SSH | Estado de bóveda desbloqueada y referencias a credenciales descifradas | | Definiciones de destinos, selección de credencial permitida y referencias de tareas | Tokens bearer en memoria y estado de conexiones HTTP | | Autoridad de firma del proceso registrada en ejecuciones anteriores | Sockets de control SSH y procesos auxiliares activos | | Descripción de una tarea pendiente, con su estado anterior | Diálogos de aprobación, acciones en cola y permisos de reintento | La primera columna permite mantener la continuidad. La segunda evita que esa continuidad se convierta en retención silenciosa de privilegios. Conserva el estado del trabajo interrumpido, pero haz que sea descriptivo. Un buen registro dice que la ejecución `R-1842` solicitó un comando SSH, recibió aprobación y se detuvo antes de ejecutarlo porque el host se reinició. Un mal registro dice que `R-1842` puede ejecutar las acciones restantes después del próximo inicio. El primero permite que una persona tome una decisión. El segundo la toma por adelantado, sin saber qué hará el proceso posterior. La gestión de credenciales necesita la misma precisión. Una clave de API guardada cifrada en una bóveda puede permanecer tras el reinicio. Su forma descifrada no debe seguir disponible solo porque el equipo se reinició rápidamente. Bloquear la bóveda crea un momento explícito en el que la persona frente al Mac vuelve a demostrar su presencia. Eso es distinto de decidir si un proceso concreto puede usar una credencial. Sallyport mantiene esta separación: su puerta de la bóveda bloquea toda acción mientras está cerrada y su autorización por sesión se aplica al proceso de agente recién conectado, no a una etiqueta de tarea recordada. Son dos decisiones distintas. Mezclarlas dificulta mucho la revisión de incidentes. No conserves una aprobación escondiéndola dentro de funciones de comodidad. Algunos ejemplos parecen inofensivos hasta que se combinan: - Un agente de lanzamiento reinicia un cliente MCP y le entrega el archivo de sesión anterior. - Un cliente SSH conserva un socket de control en `/tmp` o en una caché de usuario. - Un script copia un token bearer en un archivo de entorno para que los reintentos funcionen después del reinicio. - Un ejecutor de tareas detecta un trabajo incompleto y lo ejecuta antes de preguntar si el destino ha cambiado. Cada función promete conservar el progreso. Cada una puede conservar también la autoridad sin mostrar a la persona operadora quién o qué la posee ahora. Usa en su lugar un registro de interrupción. Incluye una referencia de tarea, el identificador de ejecución anterior, un resumen de la lista de acciones prevista, los nombres de los destinos y un estado como `stopped_by_reboot`. No incluyas una credencial utilizable, una cookie, un token de aprobación ni una instrucción que un lanzador pueda ejecutar. En la siguiente ejecución, muestra el registro como contexto para una persona. El contexto ayuda a revisar; la autoridad debe proceder de una decisión nueva. ## Un reinicio no es un evento de rotación de credenciales Un reinicio debe hacer caducar los permisos del agente, pero no debe rotar automáticamente las claves de API o SSH. Son controles que responden a fallos distintos. La caducidad de la autorización limita quién puede usar una credencial existente y durante cuánto tiempo. La rotación sustituye la credencial porque se sospecha una exposición, pérdida, uso indebido o cambio en la necesidad de acceso. Los equipos pierden tiempo y rompen integraciones cuando tratan cada reinicio como un evento de exposición. También crean una falsa sensación de seguridad si la rotación rutinaria oculta una credencial filtrada sin identificar dónde salió. Rotar una clave no arregla un diseño que entregó la clave a un agente, la puso en una transcripción o la escribió en el historial del shell. NIST Special Publication 800-63B separa la gestión de sesiones del ciclo de vida del autenticador. Sus directrices tratan la terminación de sesiones y la reautenticación como controles explícitos, mientras que sustituir un autenticador responde a otro problema. La distinción encaja bien con los sistemas de agentes: termina la ejecución activa del agente durante el reinicio y rota las credenciales subyacentes solo cuando lo exijan las pruebas o la política. Rota después de un reinicio cuando el propio reinicio siguió a un evento de exposición creíble. Algunos ejemplos son descubrir que un secreto llegó a un registro de instrucciones, encontrar un proceso desconocido con acceso al entorno del agente, perder un portátil o saber que una persona que dejó el equipo conserva una credencial copiada. En esos casos, el reinicio es incidental. La sospecha de fuga es lo que exige la rotación. Las credenciales bearer de larga duración requieren especial atención porque pueden funcionar en cualquier lugar al que llegue la red. Si un agente recibe alguna vez su valor en texto plano, la puerta de enlace ya ha perdido el límite limpio que hace útil la caducidad tras un reinicio. El agente puede guardar o transmitir ese valor antes de que el equipo se reinicie. Una aprobación posterior no puede recuperarlo. SSH tiene sus propias trampas. Una clave privada puede permanecer protegida en una bóveda local, pero una conexión SSH existente puede seguir ejecutando canales remotos hasta que termine. La multiplexación de conexiones SSH también puede dejar un socket de control local que use un cliente posterior. En circunstancias normales, el reinicio debería limpiar ambos elementos, pero no hagas suposiciones. Prueba las opciones reales del cliente y el comportamiento de los auxiliares que usa el equipo. La política práctica es esta: conserva las credenciales de origen cifradas, bloquea la bóveda durante el reinicio, termina todos los permisos y transportes activos y exige una nueva autorización del proceso antes de volver a usar una credencial. Añade condiciones de rotación basadas en exposición y cambios de personal, no en un evento de arranque arbitrario. Esta política también mantiene honesta la respuesta a incidentes. Si alguien dice «reiniciamos, así que el acceso se restableció», pregunta si la credencial salió alguna vez de su almacén protegido y si el proveedor remoto mantiene sesiones independientes. Un reinicio restablece el estado de ejecución local. No invalida un token en un proveedor en la nube a menos que el proveedor reciba una revocación o una rotación. ## Desbloquear el dispositivo, demostrar presencia y aprobar un proceso son hechos distintos Una reanudación segura necesita responder por separado a tres preguntas: ¿puede el Mac acceder a las credenciales protegidas?, ¿hay una persona responsable presente?, y ¿qué proceso solicita usarlas? Un diseño que emplea una sola señal para responder a las tres le atribuye demasiado significado. Desbloquear el dispositivo controla el acceso al entorno de usuario local. Puede demostrar que alguien superó la protección de inicio de sesión del Mac. En los equipos compatibles, una bóveda puede usar Secure Enclave y Touch ID para mantener los secretos inaccesibles mientras está bloqueada. Eso protege los materiales en reposo y crea un límite de acción claro, pero no dice nada específico sobre el siguiente proceso que lance un marco de agentes. La presencia humana es un momento concreto. Una confirmación biométrica o un clic pueden demostrarla para una decisión determinada. Permitir que esa comprobación apruebe silenciosamente todas las acciones externas futuras hasta el siguiente reinicio amplía demasiado lo que la persona pretendía autorizar. El riesgo crece cuando un agente de programación puede continuar durante horas, leer archivos cambiantes del repositorio o aceptar instrucciones de solicitudes de cambios y comentarios de incidencias. La aprobación del proceso responde a una pregunta más limitada: ¿autorizo a este programa recién iniciado a realizar llamadas a la puerta de enlace durante esta ejecución? La pantalla de aprobación debe identificar el proceso mediante pruebas duraderas, como la autoridad de firma de código, y no pedir que la persona interprete un título mutable. Una etiqueta como `agent` no es una identidad. Cualquiera puede elegirla. El orden importa. Primero, la bóveda debe estar disponible. Después, la puerta de enlace puede identificar el proceso. Por último, la persona puede aprobar ese proceso para la ejecución solicitada. Para las credenciales especialmente sensibles, solicita confirmación en cada uso. Así el equipo dispone de tres controles con funciones distintas, en vez de un botón demasiado amplio de «permitir agente». No uses el nombre de la cuenta del Mac como sustituto de la identidad del proceso. Una cuenta local compartida puede ejecutar varias sesiones de terminal, herramientas de compilación, editores y hosts de agentes. Si una aprobación se aplica a toda la cuenta, un comando malicioso del shell u otro agente puede gastar una autoridad destinada a un proceso distinto. La decisión de aprobación tampoco debe fingir que responde a preguntas de alcance que no puede resolver. Un permiso a nivel de proceso indica quién puede llamar a la puerta de enlace durante una ejecución concreta. No debe implicar silenciosamente permiso para toda credencial o toda acción para siempre. Combínalo con la selección de credencial y, cuando proceda, con una confirmación por llamada. Hay una tentación de resolverlo mediante un lenguaje de políticas complejo, con condiciones sobre la hora, la ruta de origen, la rama, el nombre del host, los patrones de comandos y las instrucciones. Estos sistemas pueden funcionar para equipos de seguridad especializados, pero crean otro riesgo cuando los desarrolladores normales no pueden predecir el resultado. Un conjunto pequeño de decisiones visibles es más fácil de aplicar después de un reinicio y de explicar durante una revisión. ## Reanuda una ejecución identificada, no un permiso general del equipo Los equipos pueden reanudar el trabajo interrumpido de forma segura si hacen duradero el elemento de trabajo y efímera la autorización. El agente reiniciado debe recibir suficiente contexto para continuar, pero debe obtener nueva autoridad como proceso nuevo. Una aprobación recordada para todo el proyecto es un atajo equivocado porque permite que trabajos no relacionados hereden una decisión antigua. Asigna a cada ejecución importante una referencia duradera que las personas ya comprendan. La ruta y la rama de un repositorio pueden bastar para tareas de desarrollo. Para tareas operativas puede ser mejor un número de ticket, una solicitud de cambio, un entorno o un identificador de incidente. La referencia no concede permiso. Permite comparar la ejecución reiniciada con el trabajo esperado. Una tarjeta de reanudación o un aviso de terminal útil contiene cinco datos: 1. El identificador de la ejecución anterior y el motivo de su finalización, como `stopped_by_reboot`. 2. La referencia del trabajo y la revisión del repositorio o artefacto de despliegue usados por la ejecución anterior. 3. La siguiente acción externa que propone el proceso nuevo, incluido el destino y la etiqueta de credencial. 4. Las pruebas de identidad del proceso actual, no solo del anterior. 5. La opción de aprobar esta ejecución, rechazarla o revisar el registro de acciones anterior. No restaures una cola completa de acciones sin revisarla. El mundo exterior puede haber cambiado mientras el Mac estaba apagado. Una solicitud de cambios puede haber recibido un force-push, un registro DNS puede apuntar a otro lugar, un despliegue puede haber terminado por otra vía o una ventana de mantenimiento puede haber cerrado. Que un agente formara un plan antes no hace apropiados sus efectos posteriores. Imagina un agente que actualizaba una flota mediante una API HTTP. Antes del reinicio cambió correctamente los hosts A a D y preparó llamadas para E a H. El Mac se reinicia. Al iniciarse, el agente encuentra la cola anterior e intenta continuar. Una implementación descuidada reutiliza el token y envía las llamadas para E a H. Una más segura lee el registro de interrupción, crea una ejecución nueva, solicita autorización, consulta el estado actual y muestra las llamadas pendientes. Puede descubrir que otra persona ya modificó F y G. La autorización renovada dio la oportunidad de detectarlo. El comportamiento de reintento necesita un límite claro. Si la puerta de enlace rechaza una llamada porque la bóveda está bloqueada o el proceso no tiene aprobación, el cliente debe detenerse e informar de la acción bloqueada. No debe entrar en un bucle, abrir avisos repetidos, recurrir al acceso directo a la red ni sustituir la credencial por una variable de entorno. Un reintento tras un fallo de red transitorio solo es razonable si la llamada sigue teniendo una autorización válida. Este enfoque no obliga al agente a olvidar su trabajo. Conserva el plan, la salida de comandos, la diferencia del repositorio y una nota en lenguaje claro sobre la interrupción. Trata esos elementos como pruebas para una decisión nueva. El plan guardado explica la intención; un permiso heredado ejecuta una acción sin una elección responsable nueva. Para operaciones sensibles, pide al agente reiniciado que vuelva a leer el estado actual antes de proponer la siguiente acción. Esto es especialmente útil para llamadas destructivas de API y comandos SSH cuyos efectos dependen del estado actual del host. La lectura adicional no es un permiso. Es una comprobación de que el plan anterior todavía describe la realidad. ## HTTP y SSH necesitan reglas explícitas para los reinicios Las API HTTP y SSH necesitan una autorización nueva del agente después de un reinicio, pero su estado oculto es lo bastante distinto como para que una afirmación vaga de «restablecer la sesión» deje pasar fallos. Escribe el comportamiento de restablecimiento para cada canal y prueba las rutas que usan realmente los agentes. En HTTP, distingue la credencial del token de acceso o la cookie emitidos por un servicio remoto. Una puerta de enlace puede conservar la credencial cifrada localmente e insertarla en una solicitud solo después de la aprobación. El agente debe recibir la respuesta, no la credencial bearer. Después del reinicio, descarta los tokens de acceso en caché, los encabezados guardados para reintentos, los almacenes de cookies usados por la automatización y el estado de las conexiones abiertas. Un proveedor puede conservar una sesión remota después del reinicio si el cliente presenta más tarde un token de actualización o una cookie todavía válidos. Por eso el agente no debe poseer esos elementos. Si los posee, puede llamar directamente al proveedor y eludir las reglas locales de reinicio. Coloca la inyección y la renovación de tokens en el lado de la acción, donde un proceso autorizado de nuevo las invoque. En SSH, termina las conexiones del cliente y revisa la multiplexación. OpenSSH puede reutilizar una conexión maestra mediante `ControlMaster` y `ControlPath`. Es útil para usuarios interactivos, pero puede dificultar saber qué invocación es dueña de una sesión remota. Una puerta de enlace para agentes debe usar una ruta de ejecución sin estado o un ciclo de vida que termine limpiamente cualquier auxiliar cuando finalice la ejecución del agente. No supongas que un comando remoto se detuvo porque se cerró la interfaz local. Usa esta prueba reproducible de reinicio para ambos canales: 1. Inicia una ejecución de agente y aprueba una solicitud HTTP inocua o un comando SSH contra un destino que no sea de producción. 2. Registra el identificador de ejecución, la identidad del proceso, la solicitud prevista y la hora de la última acción completada. 3. Reinicia el Mac antes de que el agente realice una segunda acción preparada de antemano. 4. Vuelve a iniciar el host del agente sin cambiar sus archivos de tareas y pídele que realice esa segunda acción. 5. Confirma que el primer intento se rechaza hasta que la bóveda esté disponible y el proceso nuevo reciba aprobación. Después, revisa el registro para comprobar que la segunda acción pertenece a otro identificador de ejecución. Para una puerta de enlace compatible con un verificador de auditoría de línea de comandos, ejecútalo antes y después de la prueba: ``` sp audit verify ``` El comando debe indicar si la cadena de auditoría cifrada se verifica, sin exigir que la bóveda esté desbloqueada. No escribas automatizaciones que analicen un texto de éxito inventado para una interfaz humana. Comprueba el estado de salida documentado y conserva la salida del comando junto con el registro de la prueba. Sallyport proyecta diarios de sesiones y de llamadas individuales desde un registro de auditoría cifrado, encadenado mediante hash y protegido contra escritura, por lo que el verificador ofrece una comprobación de integridad sin conexión después del reinicio. La prueba también debe cubrir el camino incorrecto. Prueba una variable de entorno antigua, un perfil de cliente HTTP en caché, un socket de control SSH y un segundo proceso de agente local. Si cualquiera llega al destino sin una autorización nueva, el límite de reinicio es solo decorativo. Corrige el bypass en lugar de añadir otro recordatorio para los operadores. ## Los registros de auditoría deben explicar la ejecución anterior y la nueva Después de un reinicio, el registro de auditoría debe mostrar dónde terminó una ejecución y dónde comenzó otra. La separación debe ser visible aunque continúen el mismo usuario, repositorio y marco de agente con la misma tarea. Si el registro mezcla los hechos en una sola sesión larga, no puede responder quién autorizó la acción posterior al reinicio. Guarda explícitamente el estado final de la ejecución anterior. Algunos valores útiles son salida normal, rechazo por bloqueo de la bóveda, rechazo pendiente de aprobación, apagado del host, fallo de red y revocación por parte del operador. No sobrescribas ese estado cuando empiece el proceso nuevo. El registro del reinicio debe apuntar a la ejecución anterior, no fusionarse con ella. Para la ejecución nueva, registra las pruebas de identidad presentadas durante la autorización, la hora de aprobación y la primera llamada externa. La primera llamada importa porque aprobar no siempre significa usar. Una persona puede aprobar una ejecución que termina antes de actuar. Distinguir aprobación de ejecución evita afirmar que ocurrió una acción cuando solo se permitió la posibilidad. Los registros de cada llamada deben conservar suficiente contexto para reconstruir la acción sin guardar secretos. En HTTP, registra el destino, el método, la etiqueta de credencial, la clase de resultado y una representación redactada de los metadatos de la solicitud. En SSH, registra el destino, la etiqueta de cuenta, el comando o un resumen aprobado, el estado de salida y los metadatos del resultado. El tratamiento exacto de la salida depende de su sensibilidad, pero no elimines el hecho de que la acción ocurrió. El encadenamiento mediante hash facilita detectar manipulaciones posteriores, pero no las vuelve imposibles. Es útil porque cada registro compromete los anteriores y la verificación sin conexión puede revelar una secuencia rota. No demuestra que una acción aprobada fuera sensata ni impide que una persona con autoridad la ejecute. Los equipos siguen necesitando revisión y límites de aprobación disciplinados. Mantén el verificador de auditoría fuera de la ruta normal del agente. Un agente que pueda reescribir o aprobar sus propias pruebas crea una relación de confianza circular. Los operadores deben poder verificar de forma independiente, incluso con la bóveda bloqueada. También deben probar qué ocurre si se modifica un registro en una copia de los datos de auditoría, para conocer el fallo esperado antes de necesitarlo. La revocación inmediata también necesita registrar su alcance. Si una persona revoca una sesión después del reinicio, el diario debe indicar qué ejecución perdió la autoridad y qué llamadas fueron rechazadas después. Evita una frase general como «acceso del agente desactivado» salvo que eso sea exactamente lo que ocurrió. Los registros precisos impiden adivinar si otro proceso conservaba una aprobación. ## Decide las reglas de caducidad antes de que las decida la automatización Una política segura de reinicio debe ser lo bastante breve para que cualquier desarrollador pueda expresarla correctamente: el reinicio bloquea los materiales protegidos, termina todos los permisos de procesos de agentes y conserva las pruebas junto con el contexto de tareas no ejecutable. Un proceso recién iniciado obtiene una autorización revisada de nuevo. Las credenciales solo se rotan cuando lo exigen la exposición o las reglas de ciclo de vida. Escribe la política en términos operativos y asigna una persona responsable de cada excepción. Si un equipo afirma que necesita automatización ininterrumpida durante los reinicios, pregunta qué acción continuaría, qué cuenta sería su propietaria, cómo se supervisaría y por qué no es aceptable un límite de aprobación humana. Eso puede describir una carga de trabajo de cuenta de servicio, no un agente de programación interactivo. Dale un diseño separado en lugar de convertir silenciosamente una sesión de agente en una credencial de servidor. Establece una respuesta previsible para el primer día laborable después de un reinicio inesperado. El operador verifica la integridad de la auditoría, comprueba la última llamada completada de la ejecución anterior, desbloquea los materiales protegidos si corresponde, inicia un proceso de agente nuevo, revisa la tarea reanudada y aprueba solo el trabajo que todavía pertenece a la situación actual. Es una interrupción pequeña frente a tener que revertir una acción ejecutada con una aprobación que nadie sabía que había sobrevivido. No prometas que la lógica de reinicio hará seguro el trabajo autónomo por sí sola. Solo puede crear un punto de decisión limpio. La calidad de esa decisión sigue dependiendo de una identidad de proceso clara, un uso limitado de credenciales, descripciones legibles de las acciones y registros que otra persona pueda revisar más adelante. Cuando el próximo reinicio interrumpa una tarea real, resiste la tentación de añadir un interruptor de «continuar automáticamente». Conserva el plan. Conserva las pruebas. Haz que el proceso nuevo vuelva a preguntar antes de gastar autoridad.