Seguridad de Fast User Switching para las acciones de agentes de IA locales

Un Mac compartido cambia el significado de la autoridad «local». Fast User Switching permite que varias sesiones de usuario permanezcan iniciadas al mismo tiempo, de modo que la persona frente al teclado, un proceso del agente, una bóveda de credenciales y un aviso de aprobación pueden pertenecer a contextos de seguridad distintos. Tratarlos como una sola identidad es la forma en que una entrega rutinaria se convierte en una llamada a producción sin revisión.

La regla práctica es sencilla: la propiedad de la cuenta, el acceso a la bóveda y la autoridad para aprobar deben permanecer vinculados a la misma sesión de usuario de macOS. Cambiar de usuario no autoriza a continuar la ejecución del agente de otra persona. Es una señal para comprobar qué proceso sigue activo, qué credenciales puede solicitar y quién puede ver o completar el siguiente aviso.

La seguridad de Fast User Switching trata de sesiones simultáneas

La seguridad de Fast User Switching importa porque macOS puede mantener iniciada la cuenta anterior mientras otra persona usa el mismo equipo. Apple describe Fast User Switching en la Guía del Usuario de macOS como una forma de cambiar de cuenta sin cerrar la sesión del otro usuario. Esa comodidad es precisamente la función. También significa que un cambio de usuario no demuestra que el trabajo anterior haya terminado.

A menudo imaginamos un portátil como una sola silla: una persona se levanta, otra se sienta y el control cambia de manos. Un Mac compartido con el cambio rápido de usuario activado se parece más a varias habitaciones dentro de un mismo edificio. El escritorio visible indica quién controla la consola en ese momento. No indica si un terminal, una extensión del editor, un servicio local o un lanzador de agentes sigue activo en otra cuenta iniciada.

La diferencia se vuelve importante cuando un agente puede llamar a una API o conectarse mediante SSH. El agente pudo iniciarse con la cuenta de Alex antes del almuerzo. Después, Sam puede cambiar a su propia cuenta y ver un escritorio limpio. El proceso de Alex puede seguir activo, su cola de trabajo puede conservar tareas y el estado de aprobación puede seguir siendo válido para esa ejecución. El Mac no transfirió esa autoridad a Sam, pero un software descuidado puede ocultar la diferencia.

No trates el bloqueo de pantalla, el cambio de usuario y la terminación de procesos como si fueran sinónimos. Resuelven problemas distintos.

• El bloqueo de pantalla impide el uso casual del escritorio visible actual.
• El cambio de usuario modifica la cuenta activa de la consola mientras conserva otra sesión iniciada.
• Cerrar sesión pide a macOS que termine la sesión gráfica de ese usuario y sus procesos.
• Revocar una ejecución del agente elimina el permiso de esa ejecución para realizar nuevas llamadas externas.

El último punto es el control que los equipos suelen olvidar. Una sesión del agente debe tener su propio ciclo de vida y su propia vía de revocación. Si solo toma prestado el ciclo de vida de una ventana de terminal o de una idea imprecisa como «el ordenador del desarrollador», se comportará mal en un Mac utilizado por varias personas.

Fast User Switching no es inseguro por sí mismo. Lo es cuando un sistema de acciones locales supone que todos los procesos activos y todas las personas que puedan tocar el equipo pertenecen a una sola persona. Esa suposición solo funciona en un Mac personal con una única cuenta activa, e incluso allí falla en cuanto otra persona conoce la contraseña de inicio de sesión o utiliza un escritorio desbloqueado.

El usuario activo de la consola no debe heredar la autoridad de otra cuenta

El usuario activo de la consola debe controlar únicamente las credenciales y aprobaciones asignadas a su propia cuenta. Una bóveda local de credenciales pertenece a una identidad, no al equipo físico. Si una aplicación hace que la bóveda sea común para todo el equipo, cualquier usuario que pueda acceder a su interfaz tiene una vía hacia la autoridad de otra persona.

Aquí es donde los equipos confunden dos afirmaciones distintas. «El secreto nunca entra en el agente» trata de la exposición del secreto. «Solo la persona correcta puede autorizar la acción» trata de la autoridad. Necesitas ambas cosas. Una separación perfecta del secreto no sirve si otro usuario con una sesión iniciada puede aprobar su uso, o si una sesión antigua sigue aprobada después de que su propietario se aleje del escritorio.

Haz explícita esta vinculación en el diseño y en las normas operativas:

1. Guarda las credenciales de cada persona bajo su cuenta de macOS, con material de bóveda separado y autenticación local independiente.
2. Exige que la cuenta propietaria de la credencial desbloquee la bóveda antes de que pueda ocurrir cualquier acción externa.
3. Haz que una aprobación se aplique a un proceso concreto del agente dentro de una cuenta concreta, y que caduque cuando el proceso termine o un operador la revoque.
4. No permitas que cambiar a otra cuenta complete un aviso originado en la primera cuenta.
5. Registra el contexto de la cuenta y el proceso de origen junto con cada autorización y cada llamada.

El caso límite incómodo es el de una persona de soporte que tiene acceso de administrador al Mac. El acceso de administrador puede cambiar muchas condiciones locales, pero no debería convertirse en una forma de usar casualmente las credenciales API de otra persona. Pregunta si el sistema obliga al propietario de la credencial a realizar una nueva autenticación y si el registro de auditoría hace visible el cambio de cuenta. Si la respuesta no está clara, el diseño tampoco lo está.

Touch ID hace que esto sea más importante, no más sencillo. Una aprobación mediante huella debe confirmar a la persona autorizada para la cuenta activa y para la acción mostrada en el aviso. No debe convertirse en una señal genérica de presencia física que cualquier persona registrada pueda usar para gastar la autoridad de otra cuenta. La autenticación local respaldada por hardware ofrece una barrera sólida solo cuando la aplicación conserva la identidad al otro lado de esa barrera.

No intentes resolverlo con una regla informal como «solo cambiamos de usuario cuando la otra persona no está». Las máquinas compartidas generan interrupciones, tareas de mantenimiento, cargadores prestados y entregas apresuradas. Los controles deben soportar el comportamiento humano normal, porque es entonces cuando la gente deja de recordar las reglas no escritas.

Un proceso oculto puede sobrevivir a la persona del escritorio

Cambiar de usuario puede dejar activo a un agente local, y debes probarlo exactamente de la forma en que tu equipo inicia los agentes. Algunos procesos se detienen cuando se cierra su terminal principal. Otros funcionan a través de un editor, un ejecutor de tareas, un elemento de inicio de sesión o un mecanismo de lanzamiento en segundo plano y continúan activos. Los límites entre cuentas de macOS restringen lo que pueden hacer, pero no garantizan que todos los procesos desaparezcan cuando otro usuario llega a la ventana de inicio de sesión.

Haz una prueba pequeña antes de permitir trabajo autónomo en hardware compartido. Usa una tarea inofensiva del agente que genere cada minuto un registro local reconocible y que no conserve ninguna credencial. Iníciala desde el mismo terminal, editor o lanzador que los desarrolladores utilizan en el trabajo real. Cambia de usuario sin cerrar sesión, espera, vuelve a cambiar y comprueba si la tarea continuó. Repite la prueba después de bloquear la pantalla y después de cerrar sesión.

Anota el resultado en términos operativos. «El agente se detiene» no basta. Registra el lanzador, la cuenta, el evento que lo detuvo y cuánto tardó. Un proceso que continúa después de un cambio de usuario puede ser aceptable para una tarea local de lint. Merece mucho más escrutinio si puede enviar una solicitud que modifique un entorno alojado.

Un fallo habitual parece inofensivo al principio. Un desarrollador inicia una ejecución autónoma de programación que puede crear comentarios en incidencias y actualizar un entorno de pruebas. Autoriza el proceso para toda la tarde. Después cambia de cuenta para que otra persona pueda usar el Mac. La ejecución de programación entra en un bucle de reintentos tras un error temporal y se reanuda más tarde. La segunda persona no la inició y quizá ni siquiera sepa que existe. Sin embargo, la ejecución conserva una aprobación válida porque el software vinculó la aprobación al calendario, al dispositivo o a una sesión de usuario amplia, en vez de vincularla al proceso de origen.

La solución no consiste solo en reducir el tiempo de espera de la aprobación. Los tiempos cortos interrumpen el trabajo real y enseñan a la gente a aceptar los avisos sin leerlos. Vincula la aprobación a una instancia del proceso. Cuando el proceso termine, termina también su concesión. Cuando alguien entregue voluntariamente el trabajo a otra persona, revoca la ejecución anterior e inicia una nueva. El proceso nuevo crea un evento de aprobación nuevo con un propietario responsable.

También necesitas una forma visible de responder a «¿qué sigue ejecutándose con mi cuenta?». La respuesta no puede depender de la memoria. Ofrece a los operadores un diario de sesiones que muestre la ejecución, indique si sigue autorizada y proporcione una acción directa para revocarla. En una máquina personal, es práctico. En un Mac compartido, forma parte de la frontera de seguridad.

Los avisos de aprobación necesitan la identidad del proceso, no una etiqueta amable

Un aviso de aprobación debe mostrar información suficiente para distinguir al autor real de una imitación. Una etiqueta como «asistente de programación» no sirve cuando dos extensiones, dos shells o un script copiado pueden usarla. El operador necesita conocer el proceso de origen y, cuando macOS lo proporcione, su autoridad de firma de código.

La autoridad de firma de código responde a una pregunta concreta pero importante: ¿qué identidad de desarrollador firmó este proceso? No demuestra que el proceso vaya a tomar buenas decisiones. Sí ayuda al operador a detectar una solicitud de una herramienta sin firma, de una compilación distinta o de un componente auxiliar inesperado. Es mucho mejor que aprobar una solicitud anónima porque apareció durante una tarde ocupada.

El aviso también debe nombrar la credencial o la categoría de acción con términos que una persona pueda valorar. «Usar la credencial X» obliga a buscar la información en una tabla mental. «Enviar una solicitud HTTP a la API de despliegue usando la credencial de publicación del entorno de pruebas» permite tomar una decisión. No llenes cada aviso con el cuerpo completo de la solicitud. Los avisos grandes generan fatiga de aprobación y exponen datos que no deberían aparecer en una notificación de escritorio. Muestra la acción, el destino, el método y la identidad de la credencial de forma fácil de revisar.

La aprobación por sesión y la aprobación por llamada resuelven problemas distintos. La aprobación por sesión dice: «Reconozco este proceso del agente y permito su ejecución limitada». La aprobación por llamada dice: «Estoy comprobando este uso concreto de esta credencial». No sustituyas la segunda por la primera solo porque la primera interrumpe menos.

Usa la aprobación por llamada cuando las consecuencias sean difíciles de revertir: una credencial que pueda modificar datos de producción, eliminar recursos, publicar contenido externamente o acceder a una interfaz administrativa amplia. Una aprobación por llamada añade fricción. Esa fricción debe aparecer justo donde una persona debería detenerse.

Usa la aprobación por sesión para trabajos cuyo proceso sea identificable y cuya credencial autorizada tenga un impacto limitado. La sesión debe terminar cuando termine el proceso. Una concesión general para «los agentes de este Mac» es una laguna de política con un nombre agradable.

La recomendación popular de desactivar las aprobaciones en una máquina local de desarrollo de confianza es equivocada para los Mac compartidos. Es popular porque los avisos interrumpen el flujo y porque los desarrolladores consideran privados los procesos locales. Fast User Switching elimina esa premisa. Una máquina local puede contener varios contextos de usuario activos, y un proceso conocido puede continuar mucho después de que su propietario abandone el teclado.

Los Mac compartidos necesitan un procedimiento de entrega que termine la autoridad

Una entrega adecuada termina la autoridad de la persona anterior antes de iniciar el trabajo de la siguiente. Pasar una pestaña del terminal, una descripción de la tarea o un mensaje de chat no transfiere la responsabilidad. La persona que llega necesita un proceso nuevo y su propia autorización para usar cualquier credencial.

Sigue este procedimiento cuando otra persona deba hacerse cargo de una tarea de un agente local:

1. Detén el agente actual si todavía está tomando decisiones. Permite que escriba sus archivos de trabajo habituales, pero no que siga llamando a sistemas externos durante la entrega.
2. Revoca la sesión del agente desde su registro de sesión. Confirma que la revocación cambia el estado de la sesión antes de que el usuario original se marche.
3. Bloquea la bóveda del usuario original o cierra la sesión de esa cuenta si el equipo permanecerá durante bastante tiempo con la siguiente persona.
4. Haz que la persona entrante cambie a su propia cuenta de macOS e inicie allí un proceso nuevo del agente.
5. Exige una autorización nueva que identifique el proceso nuevo y revisa el estado de la tarea antes de permitir acciones externas.

El procedimiento parece estricto hasta la primera vez que una entrega ambigua envía una solicitud. El coste de reiniciar un agente es pequeño comparado con averiguar después quién autorizó un cambio. Si un flujo de trabajo no puede tolerar un reinicio, necesita un diseño multiusuario deliberado, no una entrega accidental a través de un escritorio compartido.

Evita compartir una cuenta para acelerar las entregas. Un inicio de sesión compartido destruye las pruebas que necesitarás más adelante. No podrás saber qué persona desbloqueó la bóveda, qué terminal inició el proceso ni quién aprobó la llamada. Las cuentas separadas de macOS no resuelven todos los problemas, pero conservan una frontera útil y un registro aprovechable.

Los equipos también necesitan una regla para los propietarios ausentes. Si un proceso del agente se ejecuta con la cuenta de una persona que no está disponible, nadie debe mantenerlo activo haciendo clic en su cuenta. Deténlo, revócalo y reinícialo con un propietario presente. El trabajo puede esperar. Un permiso desatendido para modificar sistemas externos no debería hacerlo.

Bloquear la bóveda debe detener las acciones antes de que aparezcan los avisos

Una barrera para la bóveda debe rechazar todas las acciones mientras esté bloqueada, aunque un proceso del agente haya recibido antes una aprobación de sesión. Esta es la diferencia entre la autorización para ejecutarse y el permiso actual para usar una credencial. La primera establece qué proceso reconoce la persona. La segunda pregunta si el almacén de credenciales está disponible ahora mismo.

Sallyport utiliza este orden de forma deliberada: su barrera para la bóveda es absoluta y, en macOS, usa Secure Enclave y Touch ID; mientras está bloqueada, las acciones se rechazan. Este orden impide que una autorización antigua del agente sustituya al acceso a la bóveda después de que el usuario bloquee su sesión.

Mantén los controles separados en tu modelo mental. La barrera de la bóveda protege el acceso al material de las credenciales. La autorización de sesión reconoce una ejecución concreta del agente. La aprobación por llamada añade una revisión directa para determinadas credenciales. Si un control asume el trabajo de otro, los operadores pierden la capacidad de entender una denegación.

Por ejemplo, no hagas que los avisos por llamada sean la única protección de una credencial amplia. Una persona puede aprobar por accidente la solicitud equivocada al volver a un escritorio abarrotado después de cambiar de usuario. La bóveda bloqueada ya debería haber rechazado la acción hasta que el propietario de la credencial se autentique localmente. Después, el aviso por llamada puede plantear la pregunta más concreta: ¿este uso específico merece permiso?

Del mismo modo, no mantengas la bóveda desbloqueada permanentemente porque una tarea larga de programación quizá la necesite más tarde. Esa decisión convierte un breve descuido en un periodo durante el cual un proceso antiguo puede actuar. Desbloquéala para el trabajo supervisado y vuelve a bloquearla cuando el propietario se aleje o entregue el Mac a otra persona. Si el trabajo realmente necesita autoridad desatendida, muévelo a un entorno diseñado para identidades de servicio, credenciales limitadas y una propiedad operativa explícita. Una sesión personal compartida no es el lugar adecuado para imitar un servidor.

El término «persona en el circuito» suele ocultar la pregunta sobre la identidad. ¿Qué persona? ¿Con qué cuenta? ¿Qué proceso está aprobando? Un aviso que no pueda responder a esas preguntas no ofrece un control significativo. Solo deja constancia de que alguien pulsó un botón.

Los registros de auditoría fijan la cronología, no la decisión de permiso

Un registro de auditoría a prueba de manipulaciones permite reconstruir una ejecución del agente después de una acción discutida, pero no puede impedir una autorización incorrecta en el momento en que ocurre. Usa el registro para establecer la secuencia y la propiedad, y después corrige el control que permitió la acción. No consideres el historial de auditoría un sustituto de una bóveda bloqueada o de una frontera clara de aprobación.

El registro necesita dos vistas porque los operadores hacen dos preguntas distintas. Un diario de sesiones responde: «¿Qué ejecución del agente fue autorizada y puedo revocarla?». Un diario de actividad responde: «¿Qué llamada ocurrió, contra qué canal y cuándo?». Ambos registros deben derivarse de una única fuente de solo anexado, en lugar de dos bases de datos independientes que puedan desincronizarse.

Sallyport proyecta ambos diarios desde un registro de auditoría cifrado, encadenado mediante hashes y de escritura ciega, de modo que el historial de actividad y el historial de ejecuciones comparten una única fuente de verdad. Su comprobación sin conexión está disponible mediante este comando:

sp audit verify

Ejecuta esa comprobación cuando archives un equipo, investigues una entrega discutida o recibas un almacén de auditoría exportado. El verificador comprueba la cadena sobre el texto cifrado y no necesita la credencial de descifrado. Esta propiedad importa en los Mac compartidos: una persona investigadora puede comprobar si los registros siguen formando un historial válido sin recibir los tokens API ni el material SSH al que se refiere ese historial.

La verificación indica si la cadena ha mantenido su coherencia interna. No demuestra que todos los eventos fueran sensatos, que una persona entendiera cada aviso ni que el propio dispositivo no hubiera sido comprometido. Sé preciso con la afirmación. Una cadena verificada hace más difícil ocultar la edición silenciosa de registros anteriores. No convierte una cuenta compartida insegura en una segura.

Durante una investigación, compara el contexto de la cuenta, la identidad del proceso, la hora de autorización de la sesión, el evento de desbloqueo de la bóveda y el orden de cada llamada. Una pregunta útil no es solo «¿lo hizo un agente?». Pregunta si la misma cuenta era propietaria de la bóveda, del proceso del agente y de la aprobación. Si son distintas, has encontrado una frontera que necesita atención.

Las llamadas HTTP y SSH tienen riesgos distintos en una sesión compartida

Las acciones HTTP y SSH consumen autoridad, pero dejan huellas operativas diferentes y fallan de maneras distintas. Las credenciales HTTP suelen apuntar a un servicio remoto con un alcance de API amplio. Las credenciales SSH pueden proporcionar un shell en un host remoto, donde una conexión aceptada puede ejecutar varios comandos. No les asignes el mismo tratamiento de aprobación solo porque procedan del mismo agente local.

Para HTTP, revisa el destino, el método y el alcance de la credencial. Una solicitud de lectura a una API de desarrollo limitada merece una regla distinta de una solicitud de escritura a un endpoint de gestión de entornos. El agente debe solicitar la acción mediante una pasarela local que inyecte la credencial, para que el agente reciba el resultado y no el token portador. Esto limita la exposición del secreto, pero no reduce el impacto de una solicitud destructiva aprobada.

Para SSH, céntrate en la identidad del host, la identidad de la cuenta y la intención del comando. Una conexión a un host de desarrollo con una cuenta restringida es muy diferente de una conexión a una cuenta de producción compartida. Si la credencial concede un shell interactivo, trátala como un permiso de alto impacto aunque el primer comando parezca inofensivo. El siguiente puede no serlo.

Fast User Switching añade una condición local a ambos canales. Un proceso del agente activo en una cuenta no debe seguir emitiendo solicitudes HTTP ni abriendo sesiones SSH solo porque otro usuario haya convertido el Mac en la consola activa. La pasarela debe asociar la solicitud con el proceso de origen y exigir que el propietario de la bóveda complete la barrera. La pantalla del segundo usuario no debe convertirse en una superficie de aprobación para la ejecución del primero.

Mantén credenciales separadas para personas distintas cuando la responsabilidad sea importante. Un token de despliegue compartido dificulta distinguir un problema del proceso de un problema de entrega entre personas. Las credenciales individuales y las entradas de bóveda asociadas a cada cuenta hacen que el historial de auditoría sea útil cuando necesitas encontrar al propietario real.

Algunas cargas de trabajo no pertenecen a una estación compartida

Un Mac compartido es un lugar razonable para trabajos de desarrollo local supervisados, con credenciales limitadas y aprobaciones deliberadas. Es un mal lugar para un agente autónomo de larga duración con autoridad para modificar sistemas de producción, acceder a APIs administrativas amplias o mantener shells remotos sin una persona presente.

La diferencia no está en si el agente es inteligente. Está en si puede seguir actuando después de que su propietario responsable abandone la consola. Si puede hacerlo, usa un entorno construido para ese trabajo. Asigna a la carga una identidad de servicio dedicada, un propietario definido, credenciales limitadas y registros que el personal de operaciones pueda inspeccionar sin tomar prestada la sesión de escritorio de otra persona.

No confundas un diseño de servidor con el diseño de una aplicación local. Un servidor tiene un modelo de amenazas distinto, controles de ciclo de vida diferentes y otras expectativas sobre la ejecución desatendida. Una aplicación de barra de menús para Mac puede ofrecer a un desarrollador un control humano estricto sobre las acciones locales. No debería fingir ser un sistema de automatización sin interfaz solo porque alguien quiere que una tarea continúe durante la noche.

Para el Mac compartido que ya tienes, concreta la primera política: ningún agente conserva autoridad externa durante una entrega sin propietario. Prueba qué sobrevive a un cambio de usuario, impón el bloqueo de la bóveda cuando el propietario de la credencial se marche y revoca las ejecuciones antiguas en lugar de esperar que la siguiente persona las descubra. Ese es el punto en el que Fast User Switching deja de ser una comodidad del escritorio y empieza a recibir el tratamiento de seguridad que necesita.