Cómo cambia el bloqueo de la bóveda frente al bloqueo de pantalla una prueba de agentes

Una pantalla bloqueada y una bóveda bloqueada son controles distintos. Tratarlos como si fueran el mismo control produce una prueba que prácticamente no aporta información. El bloqueo de pantalla de macOS limita el acceso interactivo a una sesión de usuario. El bloqueo de la bóveda debe detener las acciones protegidas justo cuando se usarían las credenciales, incluso si la acción la solicita un proceso que ya había sido aprobado antes de que apartaras la vista.

La diferencia importa especialmente con los agentes de programación autónomos. Un agente puede mantener un proceso activo, conservar el contexto, programar tareas y volver a intentar una solicitud fallida. Una prueba que solo confirma que una persona no puede escribir en el escritorio no demuestra si ese proceso todavía puede llamar a una API o abrir una conexión SSH. Prueba ambos estados por separado y después prueba cómo se combinan.

He visto equipos llamar a esto una prueba de «ordenador bloqueado», tomar una captura de la pantalla de bloqueo y dar el trabajo por terminado. Eso demuestra que hay una pantalla de bloqueo. No demuestra que exista un límite absoluto de denegación alrededor de las credenciales.

Una pantalla bloqueada no decide si un proceso puede actuar

El bloqueo de pantalla de macOS protege la sesión de consola frente a quien tenga acceso físico al teclado y la pantalla. Por sí solo, no describe todos los procesos que ya se ejecutan bajo esa sesión, todas las conexiones de red que poseen ni todos los almacenes de credenciales que puede usar una aplicación.

La documentación de seguridad de plataforma de Apple separa la autenticación del usuario y la protección de la sesión de la protección de secretos, como los elementos del llavero. Esa separación resulta útil aquí, aunque tu implementación concreta tenga menos componentes de los que cubre la documentación de Apple. «¿La pantalla estaba bloqueada?» y «¿podía el agente usar una credencial?» son preguntas distintas y requieren pruebas distintas.

Un agente puede ser inofensivo con la pantalla desbloqueada y seguir siendo peligroso después de recibir un token portador en su propio entorno. También puede ejecutarse durante una sesión bloqueada y no poder hacer una solicitud protegida porque la credencial nunca entró en su memoria y la puerta de acciones la rechaza. El estado de la pantalla no te dice cuál de los dos diseños tienes.

Usa esta definición práctica durante la revisión:

• El bloqueo de pantalla controla el uso interactivo del Mac.
• El bloqueo de la bóveda controla si puede ejecutarse la acción protegida.
• La autorización de sesión controla si ese proceso concreto del agente puede solicitar acciones protegidas durante su ciclo de vida.
• Una clave por llamada controla si una persona debe aprobar ese uso concreto de la credencial.

Estos controles pueden coincidir en una demostración agradable. En producción, no deberían depender de que coincidan.

La puerta de la bóveda necesita una prueba de denegación absoluta

Una puerta de bóveda absoluta significa que una bóveda bloqueada deniega cualquier acción que usaría una credencial almacenada. La denegación debe producirse antes de inyectar las credenciales HTTP y antes de que el asistente SSH se autentique. Debe aplicarse también a un proceso que antes tuvo éxito, no solo a un proceso nuevo que nunca haya sido de confianza.

Sallyport hace explícito este límite: mientras la bóveda está bloqueada, todas las acciones se deniegan. En el hardware compatible con macOS, la puerta de la bóveda está controlada por hardware mediante Secure Enclave y Touch ID. Es una protección más sólida y clara que una convención como «el agente no debería llamar a esta herramienta mientras estoy fuera».

La prueba más reveladora empieza con un resultado correcto. Configura un endpoint de bajo impacto que controles, como un endpoint HTTP que solo registre el método de la solicitud y un identificador opaco, o un servidor SSH con un comando que imprima una palabra fija. No empieces con un endpoint de producción. Necesitas un objetivo cuyos registros puedas inspeccionar sin exponer un secreto activo ni cambiar nada importante.

Después, mantén activo el proceso del agente, bloquea la bóveda desde la aplicación y solicita de nuevo la misma acción. El resultado correcto tiene tres partes:

1. El emisor recibe una denegación clara, no un tiempo de espera agotado ni un error de red genérico.
2. El diario de actividad registra el intento como denegado, con contexto suficiente para identificar la sesión y la ruta de la credencial sin revelar la credencial.
3. Tu endpoint controlado o servidor SSH no recibe ninguna solicitud ni comando nuevo.

La tercera parte detecta el fallo que las interfaces pulidas pueden ocultar. Una puerta puede mostrar una denegación después de haber enviado una solicitud autenticada porque la comprobación estaba situada en la capa equivocada. El registro remoto es el testigo que importa.

En SSH, evita una prueba como ssh host true si tu servidor de prueba acepta otras identidades de tu entorno habitual. Usa el canal que emplearía el agente, apunta a una cuenta aislada y asígnale un comando cuya aparición en los registros del servidor sea inconfundible. Si no puedes demostrar qué identidad realizó la conexión, estás probando la configuración de tu shell, no el límite de la bóveda.

Una aprobación previa no debe sobrevivir a la puerta

La autorización por sesión responde a una pregunta más concreta que la puerta de la bóveda: ¿puede este proceso del agente usar acciones protegidas durante esta ejecución? No es una concesión permanente y no puede invalidar una bóveda bloqueada.

Aquí es donde los equipos suelen confundir comodidad con autoridad. Autorizan un agente, ven que varias llamadas tienen éxito, bloquean la bóveda y después la desbloquean. Si el proceso retoma el trabajo, suponen que la aprobación anterior debería conservarse o desaparecer según lo que parezca más cómodo. Decide este comportamiento a partir del modelo de control real y pruébalo. La secuencia de decisiones documentada por la aplicación coloca primero la puerta de la bóveda. Una puerta cerrada prevalece.

Ejecuta esta secuencia sin reiniciar el agente:

1. Inicia un proceso de agente nuevo y realiza una llamada protegida. Aprueba su sesión cuando se solicite.
2. Realiza una segunda llamada protegida con la misma credencial normal. Confirma que tiene éxito sin otra tarjeta de sesión.
3. Bloquea la bóveda mientras el proceso sigue activo. Repite la llamada y confirma la denegación antes de que el objetivo remoto la reciba.
4. Desbloquea la bóveda mediante la interacción local requerida. Repite la llamada y registra si la sesión establecida continúa según las reglas documentadas.
5. Sal del proceso del agente, inicia otro proceso nuevo y realiza la misma llamada. Confirma que la nueva ejecución recibe su propia tarjeta de autorización.

El paso cuatro no es un detalle cosmético. Revela si el producto ha tratado por accidente «la bóveda se abrió» como «todo el código que sigue activo vuelve a ser de confianza». El paso cinco muestra si un identificador de proceso, un proceso padre de terminal o una etiqueta de cliente poco precisa se ha convertido en una concesión no intencionada y de larga duración.

La tarjeta de aprobación debe mostrar primero la autoridad de firma del código del proceso. Un nombre de proceso se puede copiar fácilmente. Una ruta puede inducir a error. La autoridad de firma del código ofrece al operador un dato más estable para evaluar cuando el proceso del agente solicita usar un secreto. Registra lo que mostró la tarjeta durante la prueba, incluido lo que habrías visto si una copia no confiable del cliente hubiera realizado la misma solicitud.

La prueba de bloqueo de pantalla tiene otro objetivo

Prueba el bloqueo de pantalla de macOS después de establecer el comportamiento de la bóveda, porque su objetivo es responder a otra pregunta operativa: ¿qué puede continuar mientras no hay nadie ante la consola y cómo recuperas el control?

Primero, deja la bóveda en el estado disponible previsto e inicia una sesión que ya esté autorizada. Activa una acción protegida inofensiva, bloquea la pantalla de macOS, espera el tiempo suficiente para representar tu preocupación habitual por el trabajo desatendido y comprueba si la acción pudo continuar. No des por sentada la respuesta. La configuración de energía del Mac, el estado de la red, el ciclo de vida del proceso y la propia puerta de la aplicación influyen en ella.

Después, repite el experimento con la bóveda bloqueada explícitamente antes de bloquear la pantalla. El resultado debería ser más sencillo: los intentos de realizar acciones protegidas se deniegan. Si un agente puede seguir generando texto o editando archivos locales, eso queda fuera de esta afirmación concreta. La afirmación es que no puede convertir una clave API o SSH almacenada en una acción externa.

Este par de pruebas separa una decisión de política incómoda pero legítima de un fallo de seguridad. Algunos desarrolladores permiten deliberadamente que un agente ya autorizado continúe con tareas de bajo riesgo mientras la pantalla está bloqueada. Otros exigen que cada ausencia bloquee la bóveda. Son decisiones operativas. Permitir que un agente use credenciales después de bloquearse la bóveda es un fallo del límite de seguridad.

No hagas esta prueba observando una pantalla bloqueada desde el otro lado de la habitación. Captura las marcas de tiempo de la solicitud del agente, del endpoint controlado y del diario de actividad. Una solicitud que empezó antes de bloquearse la pantalla puede terminar después. Eso no demuestra que empezara después del bloqueo. El orden de los eventos importa.

La aprobación por llamada es para acciones que lamentarías aprobar en bloque

Una clave por llamada requiere aprobación humana cada vez que se usa esa credencial. Debe situarse por encima de una sesión aprobada, no sustituir la comprobación de sesión ni debilitar la puerta de la bóveda.

Incluye una credencial de este tipo en el plan de pruebas, aunque la mayoría de las claves utilicen una aprobación normal por sesión. Elige una acción con un efecto visible y reversible, como un endpoint de prueba que incremente un contador desechable o un comando SSH que cree un archivo en un directorio temporal. El objetivo es demostrar que la aplicación vuelve a preguntar antes del segundo uso y que rechazar la solicitud impide la acción externa.

Ejecuta la siguiente prueba con la pantalla desbloqueada para separar el comportamiento de la solicitud del estado de la sesión:

• Inicia un proceso de agente nuevo y aprueba su sesión.
• Usa la credencial por llamada y aprueba esa llamada. Verifica un evento remoto.
• Invoca de nuevo la misma credencial y rechaza la aprobación. Verifica que no haya un segundo evento remoto.
• Bloquea la bóveda e invócala una vez más. La denegación de la bóveda debe producirse sin presentar una opción significativa para aprobar una acción que la puerta no puede permitir.

La recomendación popular de marcar todas las credenciales para aprobación por llamada parece prudente porque convierte cada acción en una decisión visible. En la práctica, acostumbra a las personas a aprobar tarjetas repetidas sin leerlas. Resérvala para credenciales cuyo uso individual cambie dinero, acceso, el estado de una publicación u otra consecuencia que necesites observar. Para las llamadas rutinarias, una aprobación de sesión significativa junto con una bóveda bloqueable ofrece al operador menos decisiones y más claras.

Un registro remoto detecta la denegación que una prueba local no ve

Un mensaje de error local solo demuestra que el emisor vio un error. No demuestra que una solicitud autenticada no saliera del equipo ni dice nada sobre los reintentos que llegaron más tarde.

Crea un objetivo de prueba que informe de un identificador breve elegido por ti. La acción del agente puede enviar una cabecera o un campo inofensivo en el cuerpo de la solicitud, como test_run=screen-vault-01, siempre que la ruta de credenciales configurada en tu puerta permita ese formato. En el receptor, registra la hora de llegada, el método, la información de origen que normalmente tengas y ese identificador. Mantén el objetivo aislado de los datos de producción.

Tu registro de pruebas debería contener una tabla pequeña como esta:

La palabra «depende» en la fila C es intencionada. No ocultes una decisión de política dentro de una columna de aprobado o suspendido. Indica si en tu entorno se permite que un proceso aprobado siga trabajando mientras la pantalla está bloqueada y haz que el resultado esperado coincida con esa decisión.

En HTTP, inspecciona los registros de la aplicación, no solo los registros de acceso, si un proxy inverso puede rechazar o reintentar solicitudes antes de que la aplicación las vea. En SSH, inspecciona los registros de autenticación del servidor y de comandos de la cuenta aislada. Asigna un identificador nuevo a cada intento de prueba. Reutilizar una misma etiqueta crea una discusión sobre entregas tardías justo cuando necesitas un resultado claro.

El registro de auditoría debe explicar el cambio de estado

Un buen registro de auditoría permite al revisor reconstruir quién ejecutó el agente, qué acciones intentó y si la puerta las denegó o las ejecutó. No debería obligarlo a adivinar si la ausencia de un evento remoto se debió al bloqueo de la bóveda, a una pérdida de red o a que el agente nunca hizo la solicitud.

La aplicación mantiene un diario de sesiones para las ejecuciones de los agentes y un diario de actividad para las llamadas individuales. Ambos proceden de un único registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura, por lo que son dos vistas del mismo registro subyacente, no registros enfrentados con historias diferentes. Si una prueba revela una discrepancia entre los diarios, trátala como un fallo de la prueba hasta que puedas explicarla.

Después de cada ejecución, conserva estas observaciones en tus notas de prueba:

• La identidad de la sesión mostrada durante la autorización y la hora a la que la aprobaste o rechazaste.
• La hora exacta en la que cambiaste el estado de la bóveda y de la pantalla.
• El resultado de éxito o denegación del emisor para cada acción intentada.
• Las entradas correspondientes de los diarios de actividad y de sesiones.
• Las pruebas del objetivo controlado de que recibió o no recibió la acción.

Después, verifica la cadena sin conexión con:

sp audit verify

Una ejecución correcta debería indicar que la verificación se superó, aunque el texto exacto puede variar según la versión. Lo importante es que la verificación funcione sobre el texto cifrado y no requiera abrir la bóveda. Así puedes entregar un artefacto de auditoría protegido a un revisor que necesite comprobar si hubo manipulación, sin darle las credenciales ni la capacidad de ejecutar acciones.

No exageres lo que demuestra este comando. Una cadena de hashes válida indica que la secuencia registrada conserva su integridad según el modelo del verificador. No puede demostrar que elegiste el registro remoto correcto, que tu reloj sea preciso ni que un objetivo de prueba no tuviera otra vía de acceso. Combínala con las pruebas remotas.

El ciclo de vida del proceso es el límite que la gente suele omitir

La autorización de una sesión debe terminar cuando sale el proceso del agente. Pruébalo explícitamente, porque «abrí un terminal nuevo» no equivale a «el proceso anterior terminó», y un supervisor en segundo plano puede mantener activo un proceso hijo después de que desaparezca su interfaz.

Empieza desde una base limpia. Sal del proceso del agente, confirma mediante tu método habitual de inspección de procesos que ha desaparecido y después inicia otro proceso usando la misma ruta del cliente. Su primera llamada protegida debe crear una sesión nueva y solicitar autorización. Si hereda la aprobación en silencio, averigua qué identidad transmitió esa concesión. Puede ser una función deliberada, pero implica una autoridad mucho más amplia de lo que sugiere una autorización por sesión.

Prueba también un inicio fallido y un cliente copiado. Si un proceso cliente se inicia, solicita aprobación, sale antes de llamar a una acción y un proceso sustituto puede usar esa aprobación, has encontrado un fallo de ciclo de vida. Si un proceso firmado de otra forma muestra el mismo nombre amigable, la interfaz de aprobación debe ofrecer al operador suficiente información de autoridad para distinguirlo.

Esto no es una cuestión hipotética de registro. Las herramientas de agentes evolucionan rápido, y los envoltorios crean asistentes, reconectan transportes y se recuperan de fallos. El proceso que realiza la llamada protegida es el objeto que debes autorizar. El nombre de un proyecto o una transcripción de chat no es una identidad de ejecución.

Trata el reposo, el reinicio y la pérdida de red como experimentos separados

El bloqueo de pantalla suele probarse en un portátil activo y después se supone que el resultado también cubre el reposo, el reinicio y una caída de red. No es así. Cada evento cambia partes diferentes del sistema.

Para el reposo, registra si el proceso del agente sigue activo, si el Mac permite la ruta de red que usas y si cambia el estado de la bóveda. Para un reinicio, trata cada ejecución del agente como nueva y exige un desbloqueo local antes de permitir acciones protegidas. Para una pérdida de red, verifica que una llamada fallida no provoque un reintento inseguro después de bloquearse la bóveda o de salir el proceso original.

Mantén pequeños estos experimentos. Una prueba de reintento útil usa un identificador de solicitud y un receptor que pueda indicar si recibió cero, una o varias llegadas. Inicia la solicitud, interrumpe la ruta de red en un momento controlado, bloquea la bóveda, restablece la ruta de red y observa si se produce una entrega tardía. Si la solicitud tiene efectos secundarios, usa un receptor desechable. Reintentar una lectura normal es distinto de reintentar una operación que cambia el estado.

No conviertas esto en un motor de políticas general dentro del documento de pruebas. La pregunta es más concreta: ¿la secuencia fija de decisiones sigue produciendo el estado de denegación esperado cuando acontecimientos normales del ordenador interrumpen a un agente? Las pruebas claras valen más que una matriz enorme de reglas imaginadas.

El plan terminado debe dejar una afirmación inequívoca

Tu plan terminado debe permitirte afirmar, con pruebas, que la pantalla de macOS bloqueada y la bóveda bloqueada se probaron por separado. También debe mostrar si un proceso aprobado podía actuar sin supervisión, si la aprobación por llamada bloqueó un segundo uso y si una llamada denegada se mantuvo fuera del sistema remoto.

Escribe la afirmación final en lenguaje sencillo: «Cuando la bóveda estaba bloqueada, el agente no podía usar la credencial HTTP o SSH configurada, tanto si la pantalla de macOS estaba bloqueada como si estaba desbloqueada». Adjunta el registro del objetivo remoto y el resultado de la verificación de auditoría. Después añade tu decisión operativa independiente sobre lo que puede hacer un agente aprobado mientras solo está bloqueada la pantalla.

Esa última frase evita la confusión habitual durante la revisión de un incidente. Alguien puede no estar de acuerdo con tu política de trabajo desatendido. No debería poder confundirla con una prueba de que la puerta de la bóveda funcionó.