Autoridad del agente después de la suspensión y activación del Mac

Un proceso de agente aprobado no debería heredar autoridad solo porque un Mac se activó y dejó los mismos procesos en memoria. La suspensión, el apagado de la pantalla, el bloqueo de pantalla, el cierre de la tapa y la activación son eventos distintos del sistema operativo, pero todos plantean la misma pregunta de seguridad: ¿la persona que aprobó esta ejecución sigue presente y puede intervenir?

Trata esa pregunta como una decisión de autorización, no como un detalle de gestión de energía. Si permites que un agente de programación conserve autoridad sobre una API o SSH, una aprobación obsoleta puede convertir una pausa normal para tomar un café, un trayecto o una interrupción nocturna en un uso desatendido de credenciales. La solución no es crear un laberinto de reglas. Basta con un modelo de estados pequeño, una política de caducidad clara y pruebas que fuercen las transiciones incómodas que normalmente se omiten.

La suspensión no es un solo evento

macOS distingue entre la suspensión del sistema y la suspensión de la pantalla. Esa diferencia importa porque una pantalla oscura no demuestra que el agente se haya detenido. Apple expone notificaciones NSWorkspace independientes para willSleep, didWake, screensDidSleep y screensDidWake. Las notificaciones de suspensión y activación no incluyen datos de usuario que indiquen a la aplicación por qué ocurrió la transición.

Un portátil puede atenuar o apagar la pantalla mientras una compilación, una transferencia de red o un proceso local continúan. Un Mac de sobremesa puede funcionar sin ninguna pantalla activa. Un portátil conectado a la corriente y a periféricos puede comportarse de forma distinta al mismo portátil con batería. No puedes deducir una decisión de autoridad a partir de que un píxel se vuelva negro.

Usa cuatro hechos independientes en tu diseño:

• Estado de la pantalla: indica si la pantalla entró en suspensión o se activó.
• Estado de energía: indica si el equipo se preparó para suspenderse o salió de la suspensión.
• Estado de presencia del usuario: indica si la sesión está activa, bloqueada, cerrada o apartada mediante un cambio de usuario.
• Estado de la bóveda: indica si se pueden usar secretos.

Los equipos suelen combinar los tres primeros en un booleano llamado isAwake. Ese atajo filtra autoridad. Un agente puede seguir ejecutándose mientras la pantalla está suspendida. Un equipo puede activarse y mostrar la pantalla de bloqueo. El usuario puede bloquear la pantalla sin suspender el sistema. Cada caso necesita su propio resultado esperado.

La regla predeterminada correcta es estricta, pero fácil de explicar: una acción protegida necesita una bóveda desbloqueada y una aprobación vigente que pertenezca a la época de autoridad actual. Una activación, un bloqueo, un cambio de sesión de usuario, una revocación manual o el bloqueo de la bóveda pueden avanzar esa época. Cuando avanza, las llamadas de la época anterior fallan.

El bloqueo de pantalla debe terminar la autoridad interactiva

El bloqueo de pantalla es la señal más clara de que la aprobación interactiva debe detenerse. El Mac puede seguir funcionando y un proceso de terminal de larga duración puede conservar sus sockets y su memoria, pero el usuario que aprobó la acción ha abandonado la sesión interactiva. Es difícil justificar que se sigan enviando solicitudes API o comandos SSH con un clic anterior.

Esto no significa que todos los agentes deban morir al bloquearse la pantalla. Detener el cálculo local es una decisión distinta. Un modelo puede seguir leyendo un repositorio, compilando código o preparando un parche si esas acciones no necesitan una puerta de enlace con credenciales. El límite está en la acción externa. Conserva el trabajo y retira la autoridad.

Esta distinción resulta útil porque evita una decisión de todo o nada. No tienes que elegir entre un agente congelado y un agente completamente abierto. Permite que el agente continúe con las tareas seguras de su espacio de trabajo local y haz que la siguiente llamada protegida devuelva un rechazo claro:

authorization_denied
reason: authority_epoch_changed
required: unlock_vault_and_approve_session

Un rechazo útil indica al agente qué ocurrió sin filtrar un secreto ni fingir que la solicitud falló por un problema de red. El agente puede pausarse, registrar el bloqueo y esperar al usuario en lugar de repetir el mismo comando destructivo una y otra vez.

No hagas una excepción porque el bloqueo proceda de un temporizador de inactividad. Ese es precisamente el caso en que el usuario puede haber olvidado que el agente seguía ejecutándose. Un bloqueo explícito y uno automático reflejan intenciones humanas distintas, pero ninguno demuestra que la persona siga disponible para aprobar un cambio en producción.

Hay un caso limitado en el que se puede conservar la autoridad después de un bloqueo: una tarea diseñada intencionadamente para ejecutarse sin supervisión y con una capacidad independiente y muy restringida. Debe ser un tipo de ejecución distinto, no una excepción oculta a la aprobación interactiva. Si tu automatización nocturna se comporta exactamente igual que un agente interactivo controlado por chat durante el día, no has separado los riesgos.

Una activación inicia una nueva época de autoridad

La activación debería invalidar la aprobación interactiva aunque el proceso aprobado sobreviva. Un proceso puede pausarse antes de la suspensión y reanudarse después con el mismo PID, las mismas variables de entorno y los mismos descriptores de archivo abiertos. Nada de eso demuestra que la decisión humana anterior siga siendo válida.

Una época de autoridad es un valor monotónico que marca un periodo continuo durante el cual un permiso puede ser válido. Cuando el sistema cruza un límite que te importa, incrementa la época antes de atender otra acción. El proceso no negocia este cambio. Lo descubre en su siguiente solicitud.

Un registro de autorización mínimo podría tener este aspecto:

{
  "session_nonce": "6a018d62-2e94-4d4a-9e79-1f4e4b5ca501",
  "process_id": 84172,
  "process_start_marker": "2026-07-22T14:03:18Z",
  "signing_authority": "approved-agent-binary",
  "authority_epoch": 27,
  "approved_at": "2026-07-22T14:04:01Z",
  "per_call_approval": false
}

El identificador del proceso es solo un campo. macOS puede reutilizar un PID después de que termine un proceso, por lo que un PID aislado se vuelve peligroso si la puerta de enlace olvida un registro antiguo y vuelve a ver el mismo número. Vincula la aprobación a un nonce nuevo y a una instancia de proceso observada. Usa la autoridad de firma de código como señal de identidad del ejecutable, pero exige además una aprobación nueva por sesión para cada ejecución nueva del proceso.

Cuando tu controlador de eventos reciba willSleep, registra la intención de revocar y deja inmediatamente de admitir nuevas llamadas protegidas. Apple indica que un observador puede retrasar la suspensión hasta 30 segundos, pero no uses ese margen para completar una cola de acciones pendientes. Recházalas o márcalas como interrumpidas. El usuario no autorizó una última ráfaga de trabajo mientras se cerraba la tapa.

Cuando el equipo informe de la activación, vuelve a avanzar la época si es necesario y mantén cerrada la puerta de la bóveda hasta que el usuario cumpla el requisito de desbloqueo. Así se gestionan los órdenes imperfectos de los eventos. Los eventos de energía son confusos en los extremos, y es preferible pedir una aprobación adicional e inocua a permitir que una llamada con secretos se cuele durante una transición.

El cierre de la tapa merece su propia prueba

Para una persona, cerrar la tapa de un portátil se parece a ordenar una suspensión, pero el software no debe asumir que el gesto físico se corresponde limpiamente con un único evento del sistema operativo. La fuente de alimentación, las pantallas externas, los accesorios de conexión y los ajustes pueden cambiar el comportamiento del equipo. La única respuesta honesta es probar el hardware y la configuración que utiliza realmente tu equipo.

La política de seguridad puede seguir siendo sencilla: el cierre de la tapa termina la autoridad interactiva en cuanto observes un límite relacionado y fiable. En una configuración portátil normal, willSleep ofrece la primera oportunidad para bloquear nuevas acciones. Si una configuración concreta mantiene el sistema activo después de cerrar la tapa, usa como alternativa conservadora un límite de sesión de usuario o de pantalla. No esperes una etiqueta semántica perfecta llamada lidClosed; lo que necesitas impedir es el uso desatendido de credenciales.

Haz esta prueba con un agente que tenga una capacidad inocua con credenciales, como escribir una marca en una API de prueba o ejecutar un comando inofensivo contra un host SSH desechable:

1. Inicia un proceso nuevo del agente y aprueba su sesión.
2. Confirma que una llamada protegida funciona y deja después el agente listo para hacer otra.
3. Cierra la tapa durante el tiempo suficiente para activar el comportamiento de energía esperado y vuelve a abrirla.
4. Sin desbloquear ni aprobar de nuevo, permite que el agente reintente la llamada protegida.
5. Confirma que la puerta de enlace rechaza el reintento y registra la transición de autoridad antes del rechazo.

Repite la misma prueba conectado a una base, con batería y con una pantalla externa si el equipo utiliza esos modos. Mantén inocuo el endpoint de prueba. El objetivo es observar el comportamiento de la autoridad, no descubrir si un despliegue de producción puede interrumpirse a mitad de una operación.

Un fallo aquí puede parecer engañosamente limpio: el registro de acciones no muestra ninguna llamada durante la suspensión y después indica que la primera llamada tras la activación tuvo éxito. Sigue siendo un fallo si el usuario vio una pantalla de bloqueo y nunca aprobó la ejecución reanudada. El intervalo de tiempo es precisamente el objetivo de la prueba.

La suspensión de la pantalla es un mal disparador de revocación por sí sola

Revocar solo cuando se suspende la pantalla es seguro, pero puede resultar demasiado disruptivo en un Mac de sobremesa cuya pantalla se apaga durante el trabajo normal. Mantener la autoridad durante la suspensión de la pantalla es cómodo, pero también es fácil equivocarse cuando el tiempo de espera de la pantalla sirve como señal de que el usuario se ha ausentado.

Elige una regla y explica claramente el intercambio. Para credenciales de gran impacto, revoca al bloquearse la pantalla y al suspenderse el sistema, no solo al suspenderse la pantalla. En un equipo donde la pantalla se suspende de forma fiable justo antes del bloqueo, puedes revocar también en ese momento como protección adicional, aceptando más solicitudes de aprobación. Lo importante es no presentar ninguna de las dos opciones como «obvia». Depende del entorno y de lo que pueda hacer la credencial.

Las notificaciones independientes de pantalla y sistema de Apple son un recordatorio útil de que no significan lo mismo. Supervisa ambas, registra ambas y prueba la política que asocies a cada una.

Una matriz práctica evita que esto se convierta en una cuestión de costumbre:

El usuario desbloquea el Mac para recuperar su escritorio. Esa acción no debería restaurar en silencio la autoridad anterior del agente. Desbloquear un ordenador y aprobar una acción externa están relacionados, pero responden a preguntas distintas.

Las ejecuciones nocturnas necesitan un contrato independiente

Una ejecución nocturna del agente no debería heredar los permisos de una sesión interactiva de la tarde. Las personas aprueban el trabajo interactivo mientras miran el diff, el terminal o una tarjeta de solicitud. El trabajo nocturno es una decisión explícita de dejar que algo continúe sin esa supervisión inmediata.

Haz que el contrato de la tarea sea lo bastante limitado como para explicarlo en una frase. «Ejecutar las pruebas y preparar una solicitud de cambios» se entiende. «Hacer lo que sea necesario para terminar la tarea» no es un contrato, sino un cheque en blanco.

En el trabajo sin supervisión, separa las acciones locales de las externas. Permite las primeras cuando estén contenidas: analizar el repositorio, editar una rama, ejecutar pruebas y generar artefactos. Exige una aprobación humana nueva para los efectos externos sensibles, como modificar una API de producción, hacer un despliegue, publicar un paquete, escribir en una base de datos compartida o acceder por SSH a una máquina importante.

Hay casos en los que una ejecución nocturna debe llamar a un servicio externo. Gestiónalos con una credencial específica o con un entorno de prueba cuyo alcance de impacto corresponda al trabajo. No reutilices una credencial de administrador solo porque ya esté en la bóveda. El argumento habitual es que la persona aprobó el agente antes esa misma noche. Esa aprobación cubría una ejecución visible e interactiva. No cubre lo que quede cuando la persona se duerma.

Usa un presupuesto de acciones limitado si la tarea tiene una actividad externa recurrente legítima. Limítalo por destino, método y efecto, no mediante puntuaciones de confianza imprecisas. Por ejemplo, una tarea de pruebas sin supervisión podría enviar una solicitud fija a un único endpoint de staging, pero no cambiar de host, modificar los métodos HTTP ni usar SSH. Si necesita más, debe esperar.

La autorización por sesión de Sallyport asigna a cada proceso nuevo del agente su propio límite de aprobación. Mantén el trabajo nocturno en un proceso recién iniciado y somete sus acciones protegidas al mismo control que cualquier otra ejecución sin supervisión.

Los registros deben demostrar el rechazo, no solo la actividad

Un registro que diga «el Mac se activó» no demuestra que la autoridad haya terminado. Necesitas pruebas a ambos lados del límite: el evento del sistema operativo que desencadenó el cambio de política y la siguiente acción protegida que la puerta de enlace rechazó.

macOS ofrece un buen punto de partida para investigar la parte energética:

pmset -g log | grep -E 'Sleep|Wake|DarkWake|Display'

Las líneas exactas varían según el hardware y la versión de macOS, pero la salida debería mostrar registros con marcas de tiempo y nombres de eventos como Sleep, Wake, DarkWake o transiciones de pantalla. Guarda el intervalo correspondiente de cada prueba. No lo uses como fuente de verdad para la autorización, porque no conoce tu bóveda ni la identidad de tu agente.

Tu propio diario debe responder a otro conjunto de preguntas:

14:20:16.402 session_approved process=84172 epoch=27 authority=approved-agent-binary
14:22:04.118 power_will_sleep epoch=27
14:22:04.119 authority_revoked old_epoch=27 new_epoch=28 reason=system_sleep
14:25:38.771 power_did_wake epoch=28
14:25:44.025 action_denied process=84172 request=ssh.exec reason=authority_epoch_changed

El orden importa. Si la acción aparece antes de la entrada de revocación, has encontrado una condición de carrera. Si no aparece ninguna acción rechazada porque el agente de prueba terminó silenciosamente, no has demostrado nada sobre un proceso persistente. Organiza la prueba para que el mismo proceso de larga duración intente una llamada protegida después de cada transición.

Un registro de auditoría resistente a manipulaciones aporta un segundo beneficio: permite comprobar posteriormente que la secuencia de eventos y acciones no se editó para ofrecer una historia más bonita. Sallyport proyecta sus diarios Sessions y Activity desde un registro de auditoría cifrado, encadenado mediante hashes y ciego a la escritura, y sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado. Esto resulta útil en esta prueba porque una verificación correcta indica que la secuencia registrada no se ha reescrito en silencio. No compensa una política de revocación débil.

Las condiciones de carrera aparecen en el límite

El fallo peligroso suele ser una solicitud que ya está en curso cuando el Mac comienza a suspenderse o el usuario bloquea la pantalla. Una puerta de enlace que solo comprueba la aprobación al aceptar una conexión puede permitir que el trabajo en cola se ejecute después de la transición de autoridad. Una puerta de enlace que solo comprueba después de haber inyectado una credencial puede filtrar la credencial a un asistente antes de detectar la revocación.

Comprueba la autoridad inmediatamente antes de la operación privilegiada. Eso significa hacerlo antes de inyectar la credencial, antes de abrir un asistente SSH con una clave utilizable y antes de enviar la solicitud HTTP. Si una operación tiene varias fases privilegiadas, vuelve a comprobarla en cada fase en la que el sistema pudiera cruzar de otro modo un límite de autoridad.

Una estructura sencilla sería:

receive request
identify process and session nonce
read current authority epoch
compare request grant epoch to current epoch
check vault gate
check per-call approval when required
inject credential and execute action
append result to audit log

Mantén la lectura de la época y el compromiso de ejecutar la operación privilegiada lo más cerca posible según permita tu implementación. No puedes hacer que una acción HTTP distribuida sea perfectamente reversible una vez que los bytes salen del Mac. Sí puedes impedir que un permiso obsoleto la inicie.

No intentes resolver todos los casos extremos retrasando la suspensión. La notificación willSleep permite un breve retraso para gestionar el evento, pero impedir que un portátil se suspenda para terminar acciones del agente invierte las prioridades. El equipo está abandonando un estado interactivo. Revoca el acceso, registra la interrupción y deja que el usuario decida qué se reanuda.

La aprobación por llamada es la respuesta clara para las claves que pueden causar efectos costosos o irreversibles. Hace que la suspensión y la activación sean menos relevantes porque cada uso ya solicita la aprobación del usuario en el momento de utilizarse. Eso no justifica omitir la revocación de la sesión. Es una segunda barrera para un conjunto más pequeño de credenciales.

Prueba las transiciones que las personas realizan de verdad

Un buen plan de pruebas no empieza con pruebas unitarias de un controlador de notificaciones. Esas pruebas ayudan, pero los fallos aparecen en transiciones reales de energía, pantallas de bloqueo reales y procesos de agentes que sobreviven a una ventana de terminal.

Construye un agente de prueba que pueda esperar, recibir una señal y solicitar después una acción protegida inocua. Asigna a cada prueba un identificador de ejecución nuevo. Escribe la expectativa antes de ejecutarla, porque de lo contrario un resultado inesperado se convierte en «probablemente está bien» al revisarlo después.

Prueba al menos estos casos en cada configuración de Mac compatible:

• Bloquea la pantalla mientras el agente está inactivo y vuelve a intentar una acción aprobada antes y después de desbloquearla.
• Suspende el sistema desde el menú Apple, actívalo hasta la pantalla de bloqueo y vuelve a intentarlo con el proceso original.
• Deja que la pantalla se suspenda mientras el sistema sigue activo y comprueba si el comportamiento coincide con la política de pantalla elegida.
• Cierra y vuelve a abrir la tapa de un portátil, tanto con batería como en la configuración de escritorio que utilice el equipo.
• Deja una ejecución del agente deliberadamente larga durante la noche y revisa el registro de energía, el diario de acciones y la primera llamada protegida después del regreso.

Usa una pequeña hoja de resultados para cada ejecución: época esperada, eventos de energía observados, supervivencia del proceso original, estado de bloqueo de la bóveda y resultado de la primera llamada protegida. Esa hoja detecta un error frecuente: los equipos prueban si la aplicación vio el evento, pero nunca comprueban si la capa de acciones rechazó una llamada posterior.

Prueba también los tiempos incómodos. Inicia una acción protegida, bloquea la pantalla mientras espera una respuesta de red y comprueba si un reintento o una acción posterior se ejecuta con el permiso anterior. Inicia una acción una fracción de segundo antes de la suspensión. Desconecta y vuelve a conectar una base. Reinicia el proceso del agente después de la activación y asegúrate de que no pueda tomar prestado el registro de aprobación del proceso anterior.

No necesitas un motor de políticas enorme para superar estas pruebas. Necesitas una puerta de la bóveda estricta, un registro de aprobación por proceso, una época revocable y una ruta de acciones que compruebe todo inmediatamente antes de usar una credencial.

Escribe la política en términos de resultados y después aplícala

Una buena política de autoridad cabe en una página porque describe resultados observables, no una colección de etiquetas del sistema operativo basadas en suposiciones. Indica qué ocurre con las acciones protegidas después de un bloqueo, una suspensión, una activación, un cierre de tapa, un cierre de sesión y una revocación manual. Indica si el trabajo local puede continuar. Indica qué debe hacer el usuario para reanudarlo.

Para la mayoría de los agentes interactivos de programación con IA, la política debería decir lo siguiente:

Una acción protegida necesita una bóveda desbloqueada y una aprobación para el proceso actual dentro de la época de autoridad actual. El bloqueo, la suspensión, la pérdida de la sesión de usuario, el bloqueo de la bóveda y la revocación manual terminan esa aprobación. La activación y el desbloqueo no la restauran. El agente debe solicitar una aprobación nueva antes de realizar otra acción protegida.

La regla tiene un coste: las personas deben volver a aprobar después de regresar al Mac. Acepta ese coste. La alternativa obliga al usuario a recordar todos los procesos de agente que estaban activos antes de cerrar una tapa y después confiar en que se comportarán correctamente cuando el equipo se active horas más tarde.

Ejecuta las pruebas antes de considerar seguro un agente para el trabajo sin supervisión. Si una solicitud tiene éxito después de un bloqueo o una activación sin una decisión nueva del usuario, has encontrado una autoridad que sobrevivió al momento en que fue concedida.