Macs de desarrollo compartidos: controla el acceso de los agentes a las herramientas

Un Mac de desarrollo compartido puede servir a un equipo, pero no puede ejecutar agentes autónomos de forma segura si todas las personas y todos los procesos locales heredan el mismo conjunto de credenciales. El problema suele empezar por comodidad: un token del proyecto en un archivo del shell, una clave SSH cargada una vez, un editor iniciado desde un terminal antiguo y un agente al que se le pide «solo haz el despliegue». Al poco tiempo, nadie puede decir qué persona autorizó la acción ni qué proceso conserva el acceso.

Trata la identidad, la custodia de credenciales, la autorización y las pruebas como tareas distintas. El inicio de sesión de macOS te dice qué usuario es dueño de un proceso. No demuestra quién es dueño de un token en la nube, si un agente debe usarlo ni si un proceso que sobrevivió a la pausa del almuerzo debe conservar el acceso. Los equipos que mezclan esas responsabilidades sufren una forma muy silenciosa de acumulación de privilegios.

Las máquinas compartidas necesitan identidades separadas

Una estación de trabajo compartida solo funciona cuando cada persona, cada credencial y cada ejecución de agente tienen una identidad distinta que puedas inspeccionar y revocar. El inicio de sesión de la máquina es el primer límite, no todo el diseño.

No crees una única cuenta «dev» para todo el grupo solo porque parezca más fácil de mantener. Esa cuenta convierte en comunes la propiedad de los archivos, el historial del shell, las sesiones del navegador, las entradas del llavero y los procesos activos. Cuando un despliegue sale mal, el registro de auditoría solo dice que lo hizo la cuenta compartida. Eso no es responsabilidad individual. Es un callejón sin salida.

Da a cada desarrollador una cuenta de macOS separada y utiliza una identidad de servicio independiente para el trabajo desatendido cuando realmente la necesite. Una identidad de servicio debe tener una persona responsable, un propósito declarado, un conjunto limitado de credenciales y un plan de retirada. No debe convertirse en una cuenta de equipo encubierta que la gente use cuando su propia configuración resulta incómoda.

La diferencia importa especialmente con un agente. Un agente de programación puede iniciar subprocesos, leer su directorio de trabajo, inspeccionar el entorno que heredó y llamar a herramientas aprobadas. Si dos personas ejecutan agentes mediante la misma cuenta local, el entorno antiguo o el proceso auxiliar de una de ellas puede convertirse en una autoridad accidental para la otra.

Apple Platform Security describe las protecciones de las cuentas de macOS en torno a los datos de cada usuario y los servicios del sistema. Esas protecciones importan, pero no deciden si un token copiado en un repositorio, un directorio compartido o el entorno de un proceso es apropiado para el proceso que lo encuentra. Los permisos de archivos limitan una clase de errores. No establecen la intención.

Usa un registro sencillo de responsables para cada credencial que pueda modificar sistemas de producción, el control de código fuente, la publicación de paquetes o los datos de clientes:

• Nombra a una persona responsable y un contacto de respaldo.
• Indica el servicio, las operaciones permitidas y los entornos.
• Registra dónde se guarda el secreto y cómo se rota.
• Establece una fecha de revisión y una condición de retirada.

No pongas el secreto literal en el registro. El objetivo es hacer visible la responsabilidad, no crear otra copia de una credencial.

Tener una persona responsable no significa que deba realizar manualmente cada acción. Significa que alguien puede responder una pregunta directa: ¿por qué existe esta credencial, quién puede autorizarla y qué se rompe si la revocamos ahora? Si nadie puede responder, revócala durante una ventana segura y reconstruye el acceso con un propósito más claro.

Una cuenta Unix no contiene un secreto copiado

Los límites de las cuentas de macOS protegen los datos solo mientras la credencial permanezca dentro de ese límite y no se ofrezca por otra vía. Los equipos suelen proteger el directorio de inicio y después dejan el mismo token en archivos del proyecto, el historial del terminal, los ajustes del editor, las variables exportadas por CI o un proceso de agente de larga duración.

Empieza con un inventario que compruebe los lugares que los desarrolladores usan de verdad. Hazlo con permiso y cuidado: imprimir un secreto activo en el historial visible de un terminal compartido crea precisamente el problema que intentas encontrar.

# Search filenames and likely configuration references, not secret values.
find "$HOME" -maxdepth 3 \( -name '.env' -o -name '.netrc' -o -name 'credentials*' \) -print

# Show environment variable names for the current shell only.
env | cut -d= -f1 | grep -E 'TOKEN|SECRET|KEY|PASSWORD' || true

# Show loaded SSH identities without printing private key material.
ssh-add -l

El último comando normalmente muestra una línea por identidad, con una huella digital, el algoritmo y un comentario. Si muestra The agent has no identities., es un resultado útil. Si muestra una huella que no puedes explicar, deja de considerar que la máquina está limpia y averigua qué flujo de trabajo la cargó.

No ejecutes env dentro de una transcripción del agente ni pegues el resultado en una incidencia. Los agentes, terminales, registros de editores y tickets de soporte son malos lugares para guardar secretos. Busca primero nombres de variables y ubicaciones de archivos. Rota una credencial si tienes motivos para creer que su valor entró en una transcripción o en el historial de un repositorio.

Una recomendación habitual que falla dice: «Pon los secretos en un archivo .env local y exclúyelo de Git». Es popular porque funciona en cinco minutos. También convierte cada programa iniciado desde ese directorio en un posible lector de credenciales. Una entrada en .gitignore evita una confirmación. No impide que un agente local lea el archivo, que una herramienta de archivado lo recopile o que un desarrollador lo copie en el siguiente proyecto.

Usa archivos .env solo para ajustes locales de bajo impacto o trabajos temporales de migración con una fecha de limpieza definida. Para las credenciales que pueden modificar sistemas compartidos, guarda el valor en un almacén local protegido y expón al agente una operación, no el valor sin procesar.

La herencia entre procesos merece la misma desconfianza. Un terminal exporta DEPLOY_TOKEN; un editor se inicia desde ese terminal; una extensión inicia un servidor de lenguaje; un agente invoca una herramienta a través del editor. Es posible que el desarrollador original haya olvidado el token hace horas, pero cada proceso hijo aún puede leerlo. Los permisos de macOS hicieron exactamente lo que se les pidió. Fue el equipo quien entregó el secreto a demasiados procesos.

La custodia de credenciales y la autoridad de acción son distintas

Una credencial responde a «¿quién puede autenticarse?». La autorización responde a «¿puede este proceso realizar esta acción ahora?». Los equipos suelen tratar la posesión de la primera como prueba de la segunda, sobre todo con los tokens de API.

No entregues un token bearer a un agente solo porque necesite hacer una llamada de API. Un token bearer actúa como la persona que lo posee dentro del alcance que incluye. Cuando el token aparece en el contexto del agente, en un argumento de herramienta, en el entorno de un proceso hijo o en una salida de depuración, debes suponer que cualquier sistema capaz de leer ese material puede reutilizarlo.

En su lugar, define un contrato de acción. El agente solicita una operación con nombre y entradas estructuradas. Un componente local de confianza conserva la credencial, valida el destino permitido y la forma de la solicitud, realiza la llamada y devuelve el resultado. El agente nunca recibe un marcador vacío que pueda completar más tarde desde otra fuente. No recibe ninguna credencial.

Por ejemplo, un agente de lanzamientos puede necesitar crear un registro de despliegue. Su solicitud podría ser así:

{
  "action": "create_deployment",
  "environment": "staging",
  "revision": "7c31f4a",
  "summary": "Fix request timeout handling"
}

El componente de confianza puede asignar create_deployment a un endpoint aprobado y a una credencial almacenada. Debe rechazar una entrada que intente proporcionar un host, una ruta, un encabezado de autorización o un cuerpo de solicitud arbitrario. Si el contrato de acción permite URLs y encabezados arbitrarios, habrás recreado el acceso general a la red con más formalidades.

Mantén el alcance de la credencial lo bastante pequeño como para que un error tenga un resultado limitado. Separa el acceso de lectura del de escritura. Separa staging de producción. Prefiere credenciales de corta duración cuando el servicio de origen las admita, pero no consideres que una vida corta soluciona un alcance demasiado amplio. Un token que dura poco aún puede realizar una llamada irreversible durante su primer segundo.

La misma diferencia se aplica a SSH. Una clave privada SSH demuestra el control de una identidad. No explica por qué un agente local debería ejecutar un comando en un host en este momento. Incluye la selección del comando y del host en la decisión de autorización. No entregues a un agente una vía de shell genérica esperando que las instrucciones del repositorio lo contengan.

Los procesos locales pueden tomar más autoridad de la prevista

Un proceso local puede heredar autoridad mediante variables de entorno, descriptores de archivos abiertos, sockets Unix, sesiones del navegador y servicios auxiliares. El proceso arriesgado a menudo no es malicioso. Está obsoleto, mal configurado o lo inició alguien que no sabía qué había concedido ya su proceso padre.

Inspecciona un proceso sospechoso antes de terminarlo. En macOS, estos comandos ofrecen pistas útiles sin exponer valores de credenciales:

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[c]laude\|[n]ode\|[p]ython'
lsof -nP -p <PID> | grep -E 'cwd|unix|TCP|IPv4|IPv6'

El primer comando muestra el identificador del proceso, el identificador del proceso padre, la cuenta y el comando de inicio. El segundo suele mostrar el directorio de trabajo actual, las rutas de sockets Unix y las conexiones de red abiertas. Un directorio de trabajo dentro de un proyecto antiguo y un terminal padre de una sesión anterior explican más incidentes que un malware exótico.

No supongas que un proceso terminó porque desapareció su ventana. Los editores mantienen servidores de lenguaje activos. Los multiplexores de terminal conservan los shells. Las herramientas de compilación inician procesos de vigilancia. Un cliente MCP local puede mantener una conexión mucho después de que el desarrollador haya dejado de prestarle atención.

Haz que finalizar el acceso sea una acción deliberada. Cierra el cliente del agente, detén la sesión de terminal que lo inició y elimina cualquier autorización temporal concedida para esa ejecución. Si un asistente debe permanecer activo, registra su propósito y haz que la identidad de su proceso sea visible para la persona que aprueba el acceso.

Una prueba práctica de cambio de usuario detecta los problemas pronto. El desarrollador A ejecuta un agente con acceso a una acción de staging y después cierra el agente y la sesión. El desarrollador B inicia sesión en su propia cuenta y realiza una solicitud inofensiva. B no debería encontrar el directorio del proyecto de A, sus variables de entorno, su socket SSH, su sesión del navegador ni su autorización activa. Si puede acceder a alguno de ellos, el equipo tiene estado compartido que debe eliminar.

No resuelvas esto convirtiendo a los desarrolladores en administradores. Los privilegios de administrador pueden ser necesarios para gestionar el sistema, pero amplían el radio de impacto de un instalador descuidado o un script local. Usa una cuenta estándar para el trabajo diario con agentes salvo que una tarea concreta requiera elevación. En ese caso, eleva los privilegios para esa tarea y vuelve después al uso normal.

Los agentes SSH necesitan el mismo control que las claves privadas

Un agente SSH mantiene la autoridad de firma detrás de un socket local, por lo que un proceso que pueda acceder a ese socket puede solicitar firmas sin leer el archivo de la clave privada. Esto es mejor que dispersar claves privadas por el disco, pero no da carta blanca a todos los procesos de la estación de trabajo.

OpenSSH documenta SSH_AUTH_SOCK como la ruta al socket del agente. Trata esa variable de entorno como información sensible de enrutamiento. Si un agente la hereda, puede ser capaz de pedir firmas de las identidades cargadas en ese momento. La clave privada permanece oculta, pero el riesgo operativo sigue existiendo.

Ejecuta esto antes de usar automatización contra un sistema remoto:

printf '%s\n' "${SSH_AUTH_SOCK:-SSH_AUTH_SOCK is unset}"
ssh-add -l
ssh -G [email protected] | grep -E '^(hostname|user|identityfile|forwardagent) '

ssh -G muestra la configuración efectiva del cliente OpenSSH. La salida incluye líneas como user deploy, identityfile ... y forwardagent no. Comprueba con atención la última línea. El reenvío del agente permite que un host remoto use tu agente local mediante la conexión reenviada. Debe permanecer desactivado salvo que puedas explicar exactamente cuál es el salto remoto y por qué lo necesita.

El manual de ssh_config de OpenSSH describe ForwardAgent y advierte que el reenvío puede exponer el agente local a usuarios con suficiente acceso en el host remoto. Los equipos siguen activándolo de forma general porque evita copiar claves y hace que un host de salto resulte cómodo. La comodidad es real. También lo es el hecho de que un entorno remoto comprometido o con permisos excesivos puede solicitar firmas mientras exista la sesión reenviada.

Usa identidades separadas para clases de acceso separadas. Una identidad de despliegue en producción no debe estar junto a una identidad personal de control de código fuente en el mismo agente solo porque ambas sean útiles durante el desarrollo. Elimina las identidades después de la tarea cuando sea práctico:

ssh-add -d ~/.ssh/id_staging_deploy
# Or clear every identity after a short, dedicated session.
ssh-add -D

Eliminar todas las identidades puede interrumpir otro trabajo legítimo, así que hazlo al final de una sesión breve y dedicada, no en una pestaña de shell compartida de la que dependa otra persona. El patrón más seguro es evitar por completo los shells compartidos.

Evita poner rutas de claves privadas, alias de hosts y reglas permisivas de reenvío en una configuración del repositorio que todos los desarrolladores adopten sin revisarla. El repositorio puede documentar el host y la cuenta esperados. Cada desarrollador debe decidir qué identidad local puede acceder a ellos.

La aprobación debe identificar el proceso y la acción

Una solicitud de aprobación solo ayuda cuando una persona puede identificar quién llama, entender la operación solicitada y revocar el permiso cuando termina el trabajo. Un aviso que dice «permitir acceso» enseña a aprobar el ruido.

La aprobación por sesión encaja con el trabajo habitual de desarrollo. La primera llamada de un proceso de agente recién iniciado muestra la identidad del solicitante y el usuario decide si esa ejecución puede utilizar un canal de acción. La autorización debe terminar cuando el proceso se cierra, no permanecer como una preferencia invisible.

La aprobación por llamada es adecuada para acciones con consecuencias desiguales: borrar datos en producción, publicar un paquete, cambiar un ajuste de pagos o ejecutar un comando en un host sensible. Añade fricción intencionadamente. No la apliques a una simple consulta de estado de solo lectura para crear un ritual tranquilizador. La gente terminará aprobándola sin leerla.

La tarjeta de aprobación debe responder estas preguntas en lenguaje claro:

• ¿Qué proceso local solicitó el acceso, incluida su autoridad de firma cuando esté disponible?
• ¿Qué credencial almacenada o categoría de acción utilizará?
• ¿Qué destino, host o entorno recibirá la solicitud?
• ¿Qué operación se realizará y qué entradas cambian de forma significativa su efecto?
• ¿La aprobación dura solo para esta llamada o hasta que termine el proceso?

No aceptes un sistema de aprobación que identifique al solicitante únicamente como «terminal» o «agente». Una máquina local puede ejecutar varios terminales y procesos de agente. La persona que aprueba necesita suficiente información para distinguir una ejecución de trabajo recién iniciada de un proceso antiguo que sigue activo.

Sallyport usa una secuencia fija de decisiones: una bóveda bloqueada deniega todas las acciones, un proceso de agente nuevo requiere autorización de sesión de forma predeterminada y determinadas credenciales pueden exigir aprobación en cada uso. Este modelo limitado es preferible a un lenguaje de políticas local complejo en el portátil de un desarrollador, donde las reglas poco claras envejecen mal y nadie puede predecir con confianza cuál prevalecerá.

La aprobación no sustituye al alcance. Una persona puede aprobar algo equivocado. Limita primero los destinos, las credenciales y las formas de acción. Después solicita aprobación cuando el criterio humano aporte un control útil.

Un registro debe responder a las preguntas de responsabilidad después del hecho

Un registro de auditoría útil permite a un ingeniero reconstruir quién ejecutó qué, qué proceso local recibió autoridad, qué acción externa ocurrió y cuándo se retiró el acceso. El historial de un terminal no cumple ese estándar porque los usuarios pueden modificarlo, los shells lo rotan y los procesos separados desaparecen dentro de un único archivo histórico.

Mantén dos vistas del mismo flujo de eventos. Una registra las sesiones: identidad del proceso de agente, hora de inicio y finalización, aprobaciones y revocaciones. La otra registra las acciones: marca de tiempo, destino, método o comando, referencia de la credencial, resultado y error. Únelas mediante un identificador de sesión, pero conserva la información comprensible sin obligar a realizar una excavación arqueológica en una base de datos.

La evidencia de manipulación cambia la calidad de la conversación después de un incidente. Una secuencia de solo escritura con hashes encadenados hace detectables las modificaciones silenciosas. No demuestra que todas las acciones registradas fueran acertadas ni recupera los registros que no recopilaste. Sí hace más fácil cuestionar la afirmación de que «alguien limpió el registro».

Verifica el registro de auditoría de forma independiente. Sallyport proyecta sus diarios de sesiones y actividad desde un registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify comprueba la cadena sin conexión y sin acceder a las claves de la bóveda. Esta separación importa porque el comando de verificación no debería necesitar el mismo almacén secreto cuyo uso estás investigando.

Los registros también deben proteger los secretos. Registra una referencia de credencial, el nombre de la acción, el destino y el resultado. No registres tokens bearer, encabezados de autorización de solicitudes, material de claves privadas ni argumentos de comandos que incluyan contraseñas. Un registro completo que reproduce todos los secretos es otra bóveda de credenciales, con un control de acceso peor.

Revisa las acciones fallidas, no solo las correctas. Las denegaciones repetidas pueden revelar que un agente intenta usar un contrato de acción obsoleto, que un desarrollador utiliza la cuenta equivocada o que un proceso en segundo plano sobrevivió a su tarea. Una acción correcta sin explicación merece atención, pero los fallos muestran los límites donde los controles no coinciden con el trabajo real.

Un modelo operativo viable para un Mac del equipo

Los equipos pueden ejecutar agentes locales de forma suficientemente segura para trabajos importantes si hacen que el hardware compartido sea menos relevante que la identidad individual y la autoridad explícita sobre las acciones. El modelo operativo necesita hábitos diarios, no un documento de seguridad que solo aparece durante la incorporación.

Usa esta secuencia cuando añadas un flujo de trabajo con agentes a una máquina compartida de la oficina:

1. Asigna la persona responsable, el servicio permitido, el entorno y la condición de retirada de cada credencial.
2. Crea un contrato de acción específico para el agente en lugar de exponer un token general o una sesión de shell.
3. Inicia el agente desde la cuenta del desarrollador prevista, con un entorno de credenciales vacío o mínimo.
4. Aprueba el proceso nuevo solo después de comprobar su identidad y el destino solicitado.
5. Termina la ejecución, revócala si hace falta y confirma que sus procesos auxiliares y sus identidades SSH han desaparecido.

Esta secuencia es deliberadamente menos cómoda que poner un token de producción en un perfil de shell popular. Ese atajo parece eficiente hasta que un contratista usa la máquina, un editor hereda el entorno o un proceso antiguo permanece activo durante el siguiente turno.

Define el acceso de emergencia antes de que ocurra una interrupción. El equipo necesita una persona documentada que pueda aprobar una acción de emergencia, una credencial separada con un alcance limitado para emergencias y un registro que explique por qué se utilizó. No dejes un token potente en una carpeta compartida «por si acaso». Se convertirá en acceso normal simplemente porque está disponible.

Para el trabajo que requiere una puerta de acciones local, mantén la puerta en la cuenta del propio desarrollador y haz visible el límite del proceso. Un Mac compartido puede alojar a varios usuarios a lo largo del tiempo. No debe alojar un único conjunto indiferenciado de autoridades.

Prueba la revocación mientras el agente sigue activo

La revocación solo es creíble si bloquea la siguiente acción de un proceso que ya tenía permiso. Probarla después de cerrar todos los clientes demuestra muy poco.

Configura una acción de staging inofensiva que devuelva una respuesta conocida. Inicia un proceso de agente, autorízalo para la sesión y realiza la acción una vez. Después revoca la sesión o bloquea el almacén de credenciales mientras el proceso sigue activo. Solicita de nuevo la misma acción.

El resultado esperado es una denegación vinculada al proceso activo o al estado bloqueado. El agente no debe recurrir a un token de su entorno, a un socket SSH existente ni a una sesión en caché del navegador. Si la acción tiene éxito, inspecciona la vía que utilizó antes de añadir más avisos o políticas.

Repite la prueba después de que un desarrollador cierre la sesión y otro inicie la suya. Hazlo también después de que la máquina entre en reposo y se reactive, porque las conexiones auxiliares locales y los agentes SSH a veces revelan supuestos que solo aparecen tras una jornada larga. Conserva un registro breve de los resultados, incluida la identidad exacta del proceso y la acción probada.

El cambio inicial más útil no es un gestor de secretos más grande ni una lista de aprobación más larga. Retira una credencial amplia del alcance de un agente, sustitúyela por una vía de acción limitada y demuestra que la revocación detiene un proceso que sigue activo. Esa prueba te dice si el equipo controla el acceso o simplemente lo documenta.