Puertas de enlace de agentes locales con MDM para macOS

Una puerta de enlace de agentes local debe desplegarse como una aplicación de escritorio sensible para la seguridad, no como un sistema para distribuir secretos compartidos. MDM controla la aplicación firmada, su versión, su estado de inicio y su eliminación. El desarrollador controla las credenciales que guarda en un almacén local y las aprobaciones que permiten al agente actuar con ellas.

Esta separación es mucho más que una administración ordenada. Cuando TI distribuye claves de API a través de MDM, cada compromiso del plano de gestión, de una exportación del inventario, de un script de despliegue o de un perfil de configuración puede exponer secretos. Cuando un agente recibe la clave, cada registro, transcripción de herramientas, historial del shell y límite de instrucciones pasa a formar parte de la superficie de ataque del secreto. Una puerta de enlace existe para mantener esa credencial fuera del proceso del agente. No deshagas ese diseño durante el despliegue.

Este es el modelo operativo que usaría para una flota de Macs gestionados: distribuir un único paquete de aplicación verificable, iniciarlo en el contexto de usuario correcto, mover las versiones por anillos, hacer que cada desarrollador inscriba sus propias credenciales localmente y retirar los dispositivos mediante una secuencia que elimine primero el acceso y después borre el hardware.

MDM debe distribuir la puerta de enlace, no la autoridad del desarrollador

MDM debe saber qué Mac tiene la aplicación aprobada y qué versión ejecuta. No debe convertirse en un almacén de tokens de API personales, claves privadas SSH ni archivos de credenciales pegados.

A menudo se mezclan dos cosas distintas porque ambas se llaman «configuración». Instalar una aplicación es configuración de la flota. Dar a una persona o a un agente permiso para llamar a una API de producción es autoridad delegada. Lo primero pertenece a MDM. Lo segundo pertenece a un almacén local controlado por el usuario, con un límite de aprobación claro.

Esta distinción tiene una consecuencia práctica durante la incorporación. El flujo de MDM puede instalar la puerta de enlace antes de que el desarrollador abra su editor. El flujo de primer inicio del desarrollador aún debe pedirle que cree o desbloquee su propio almacén y que añada solo las credenciales que está autorizado a usar. TI puede documentar los tipos de credenciales aprobados y las cuentas de servicio necesarias, pero no debe recopilar el material secreto para volver a distribuirlo después.

Esto también hace más honesta la baja de usuarios. Eliminar una aplicación gestionada no revoca un token de nube que se copió en un perfil meses atrás. Un almacén local permite que el usuario elimine directamente una credencial, mientras el responsable del servicio puede revocar el token en su origen. Así dispones de dos formas independientes de terminar el acceso, en lugar de un único script de limpieza frágil.

En Sallyport, esta división es intencionada: la aplicación mantiene las claves de API y SSH en su almacén local cifrado y ejecuta las acciones HTTP o SSH por sí misma, en lugar de pasar las credenciales al agente conectado. El diseño del despliegue debe conservar esta propiedad.

Un registro MDM razonable para la puerta de enlace contiene únicamente datos operativos:

• número de serie del dispositivo o identificador de gestión
• anillo de despliegue asignado y versión de la aplicación
• recibo del paquete y resultado de la instalación
• responsable principal de soporte y fecha de caducidad de la excepción
• si la aplicación es obligatoria, opcional o está pendiente de eliminación

No añadas a ese campo del inventario nombres de secretos, valores de tokens, rutas de claves privadas ni historial de aprobaciones. Esos datos pueden exponer contexto sensible o crear la impresión engañosa de que MDM puede reconstruir el acceso de trabajo de un usuario.

El paquete es el contrato de despliegue

Un paquete instalador firmado es el artefacto que hace repetible el despliegue en una flota. Una imagen de disco compartida por chat, un zip extraído en Descargas o un script que copia un paquete de aplicación en /Applications no constituyen un contrato de despliegue.

La documentación de despliegue de Apple indica que los paquetes instalados mediante la gestión de dispositivos deben llevar una firma que el dispositivo pueda verificar. También recomienda aplicaciones autocontenidas, lo que evita scripts de instalación personalizados para el despliegue normal de aplicaciones. Es un buen consejo en este caso. Los scripts multiplican los puntos de fallo, se ejecutan con privilegios confusos y suelen sobrevivir mucho tiempo después de que cambie la estructura de la aplicación.

Crea un artefacto de lanzamiento para cada versión publicada. Dale un nombre de archivo versionado, conserva su suma de comprobación en el registro de lanzamiento y exige el mismo paquete en todos los anillos. Un anillo debe probar la exposición a la misma compilación, no una variación imposible de rastrear creada para cada grupo.

Antes de subir un paquete a MDM, verifica tanto el paquete como la aplicación instalada en un Mac de prueba limpio. Estos comandos ofrecen una comprobación mínima útil:

pkgutil --check-signature Sallyport.pkg
spctl -a -vv -t install Sallyport.pkg

El primer comando debe identificar un instalador firmado y una cadena de firma válida. El segundo debe evaluar el paquete para su instalación. Después del despliegue, inspecciona también el paquete de la aplicación:

codesign --verify --deep --strict --verbose=2 /Applications/Sallyport.app
spctl -a -vv /Applications/Sallyport.app

No aceptes un estado correcto de MDM como prueba de que el binario adecuado está listo. MDM puede informar de que el paquete se instaló aunque un elemento de inicio posterior, un ayudante en segundo plano, un entitlement o un requisito de la sesión del usuario impida que la aplicación haga un trabajo útil. La verificación del paquete y las pruebas funcionales responden a preguntas distintas.

Mantén el paquete sencillo. Debe instalar la aplicación en la ubicación prevista, evitar descargar un segundo ejecutable durante el postinstall y evitar escribir credenciales o ajustes por usuario. Si un paquete necesita un script postinstall elaborado para que el producto funcione, detente y pregunta si el diseño de la aplicación o el límite del paquete son incorrectos. Pagarás el coste de ese script durante cada actualización de macOS y cada revisión de respuesta a incidentes.

La aplicación instalada debe poder eliminarse como una aplicación, no mediante una investigación forense. Apple señala que un paquete puede colocar un paquete de aplicación en /Applications para que el servicio de gestión de dispositivos lo gestione y elimine individualmente. Esa es una razón más para evitar dispersar archivos esenciales en directorios arbitrarios.

Inicia la aplicación en la sesión del desarrollador

Una puerta de enlace que pide aprobación local o necesita acceder a un almacén protegido por el usuario debe ejecutarse en el contexto del usuario que ha iniciado sesión. Un demonio root no sustituye ese contexto.

Aquí es donde los equipos cometen un error predecible. Ven «siempre en ejecución» y recurren a un LaunchDaemon porque se inicia antes del login y sobrevive al cierre de sesión. Después descubren que el demonio no puede mostrar honestamente una solicitud de aprobación del usuario, no puede usar el llavero de usuario esperado ni la ruta de autorización biométrica y ha acumulado más privilegios de los necesarios.

Apple marca claramente el límite. Un elemento de inicio de sesión se inicia cuando el usuario inicia sesión y se ejecuta en su sesión. Un LaunchAgent también se ejecuta para el usuario que ha iniciado sesión. Un LaunchDaemon funciona a nivel del sistema, puede ejecutarse antes del inicio de sesión y se ejecuta como root. Apple también describe los elementos de inicio de sesión como apropiados para una aplicación orientada al usuario que debe permanecer activa durante su sesión.

Para una puerta de enlace en la barra de menús, la opción normal es un elemento de inicio de sesión gestionado o el mecanismo de inicio de sesión compatible de la propia aplicación. Debe iniciarse después de que el usuario llegue al escritorio, permanecer suficientemente visible para que el desarrollador sepa que está activa y detenerse cuando cierre sesión. No ocultes un límite de seguridad en un proceso que los usuarios no pueden inspeccionar ni cerrar.

Si MDM debe imponer el comportamiento de inicio, utiliza la carga útil de elementos de inicio de sesión gestionados de Apple en lugar de inventar un plist que copie un script. La carga útil com.apple.loginitems.managed puede especificar la ruta de una aplicación y si debe estar oculta. La referencia de gestión de dispositivos de Apple proporciona la estructura de la carga útil y la admite en macOS.

Una carga útil representativa tiene este aspecto. Sustituye los identificadores y la ruta por tus propios valores publicados y genera los UUID mediante las herramientas habituales de perfiles.

<dict>
  <key>PayloadType</key>
  <string>com.apple.loginitems.managed</string>
  <key>PayloadIdentifier</key>
  <string>dev.example.agent-gateway.login-item</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-UUID</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <key>AutoLaunchedApplicationDictionary-managed</key>
  <array>
    <dict>
      <key>Path</key>
      <string>/Applications/Sallyport.app</string>
      <key>Hide</key>
      <false/>
    </dict>
  </array>
</dict>

El fallo que esto evita es sencillo, pero costoso: el paquete se instala, la aplicación aparece en /Applications y el desarrollador supone que la puerta de enlace está protegiendo su agente. En realidad, nunca se inició después del login, así que el puente MCP no puede completar una solicitud o el usuario nunca ve la tarjeta de aprobación. Las comprobaciones de inscripción deben probar un inicio de sesión real del usuario, no solo la instalación mediante el agente de MDM.

Un LaunchDaemon aún tiene usos legítimos, pero mantenlo fuera de la ruta del almacén. Úsalo solo cuando puedas explicar por qué el trabajo debe ejecutarse sin una sesión gráfica y por qué necesita root. «Queríamos que fuera fiable» no es una respuesta. Una aplicación de sesión de usuario puede ser fiable sin fingir que es un servicio de máquina.

Los anillos de actualización deben probar el trabajo real de los desarrolladores

Los anillos de actualización funcionan cuando cada uno responde a una pregunta operativa distinta. Fallan cuando se convierten en una forma educada de retrasar todas las actualizaciones indefinidamente.

Empieza con un anillo interno pequeño. Incluye a las personas que empaquetan la aplicación, administran la configuración de MDM y solucionan problemas en las estaciones de trabajo de los desarrolladores. Su trabajo es detectar fallos de instalación, problemas de inicio, solicitudes de permisos inesperadas y rutas de actualización desde la versión anterior de producción.

El anillo siguiente debe incluir desarrolladores que usen herramientas y patrones de acceso distintos. Incluye a alguien que use APIs HTTP mediante un agente, a alguien que use SSH, a alguien que cambie de red con frecuencia y a alguien que trabaje con una cuenta gestionada normal en lugar de privilegios de administrador local. Buscas diferencias en el uso real, no una colección de entusiastas que perdonen cualquier problema.

Producción es el anillo en el que la versión se convierte en la predeterminada. Conserva un pequeño grupo de emergencia en espera solo por una razón concreta, con responsable y fecha de caducidad. «Esta persona está ocupada» no es una política de despliegue. Así es como las versiones sin soporte se vuelven permanentes.

Trata el despliegue como una máquina de estados, no como un ritual del calendario:

1. Instala el paquete firmado en el anillo interno y confirma la evaluación del paquete y de la aplicación.
2. Haz que cada usuario de prueba cierre y vuelva a iniciar sesión, y confirma que la puerta de enlace se inicia en su sesión.
3. Ejecuta acciones reales e inocuas a través del agente, incluida una solicitud HTTP y un comando SSH si esos canales están dentro del alcance.
4. Pasa el paquete idéntico al anillo piloto después de revisar los fallos, los tickets de soporte y las necesidades de reversión.
5. Promuévelo a producción solo después de comprobar que funciona la ruta de actualización desde la versión anterior, no únicamente la instalación desde cero.

No definas el éxito como «la consola de MDM dice instalado». Defínelo como una cadena de eventos observables: el recibo del paquete está presente, la aplicación firmada supera la evaluación, la aplicación se inicia después del login, el desarrollador puede desbloquear su propio almacén, el agente llega al puente local y una acción permitida devuelve un resultado.

Haz explícita la reversión antes del despliegue. Para una actualización normal, revertir debe significar volver a desplegar el paquete firmado anterior, restaurar la asignación de la versión requerida anterior y comprobar que la aplicación anterior puede leer su estado local de forma segura. No debe significar pedir a los desarrolladores que arrastren aplicaciones dentro y fuera de carpetas mientras soporte intenta adivinar qué compilación tienen.

La gestión declarativa de aplicaciones y paquetes de Apple puede definir paquetes como obligatorios u opcionales en Macs supervisados compatibles, y la gestión declarativa de aplicaciones tiene prioridad sobre un comando de instalación que se solape. No envíes dos mecanismos de gestión al mismo objetivo esperando que el dispositivo elija el que pretendes. Escoge el método que controla cada anillo y regístralo.

Un almacén independiente cambia la incorporación y la recuperación

Un almacén por desarrollador convierte la primera ejecución en un proceso de seguridad, no en un defecto de automatización. El usuario debe decidir qué credenciales pertenecen a ese Mac y el dispositivo debe demostrar que el usuario puede desbloquearlas.

Ese es precisamente el objetivo. La puerta de enlace de agentes local puede recibir una solicitud de Claude Code u otro agente compatible con MCP, pero el agente nunca debe recibir la credencial en texto plano ni como un marcador falso que pueda reutilizar después. La puerta de enlace debe ejecutar la acción HTTP o SSH y devolver el resultado.

En Sallyport, la secuencia fija de decisiones resulta útil porque evita un lenguaje de políticas que todos los equipos tendrían que aprender y auditar. Un almacén bloqueado deniega todas las acciones. Un proceso de agente nuevo recibe autorización de sesión de forma predeterminada, y una credencial marcada para aprobación por llamada pregunta cada vez que se usa. Son controles distintos, así que forma a los desarrolladores para emplearlos en situaciones distintas.

Usa el bloqueo del almacén cuando el portátil esté desatendido o el desarrollador haya terminado de trabajar. Usa la autorización de sesión para identificar una ejecución de agente recién iniciada antes de concederle un margen amplio. Usa la aprobación por llamada para credenciales cuyo uso merezca atención humana, como un token de administración de producción o una identidad SSH sensible.

No digas a los desarrolladores que pongan todas las credenciales bajo aprobación por llamada porque parezca más seguro. Las solicitudes repetidas hacen que las personas aprueben sin leer. Coloca la fricción donde una solicitud equivocada tendría consecuencias y deja las credenciales de desarrollo comunes y de bajo riesgo bajo el límite de sesión. La fatiga de aprobación es un fallo de diseño, no una prueba de que el equipo se toma la seguridad en serio.

La recuperación necesita límites igual de claros. TI puede reinstalar la aplicación de puerta de enlace y reparar su estado de inicio gestionado. TI no puede ni debe restaurar el contenido del almacén de un desarrollador desde un registro de MDM. Si se sustituye un Mac, el desarrollador debe obtener credenciales nuevas mediante el sistema de origen o seguir el proceso aprobado de migración de credenciales de la organización. Puede resultar incómodo. Aun así, es más seguro que tratar una base de datos de gestión de flotas como copia de seguridad de tokens de producción.

Documenta la tabla de responsabilidades antes del despliegue:

Esta tabla evita la peor llamada de soporte del despliegue: un desarrollador dice «mi agente perdió el acceso», soporte de dispositivos dice «la aplicación está instalada» y el responsable del servicio supone que alguien restauró un secreto que nunca debía estar en manos de nadie más.

El inventario y las evidencias de las acciones responden a preguntas distintas

El inventario de MDM indica si la aplicación gestionada llegó a un dispositivo. No puede demostrar qué solicitó un agente de IA después de la instalación, qué autoridad lo aprobó ni qué llamada a una API se ejecutó.

Mantén esos registros separados y relaciónalos cuando sea necesario. El registro de MDM debe proporcionar la identidad del hardware, el estado de gestión, la versión asignada de la aplicación, la marca de tiempo de instalación y el estado de eliminación. El registro de auditoría de la puerta de enlace debe proporcionar la sesión, la acción individual y el resultado de la verificación. Si los mezclas en una sola hoja de cálculo, expondrás demasiado detalle operativo al personal de dispositivos o dejarás a los investigadores de incidentes sin las evidencias que necesitan.

Sallyport registra las ejecuciones de los agentes en un diario de sesiones y las acciones individuales en un diario de actividad, ambos proyectados desde un único registro de auditoría cifrado y encadenado mediante hashes. Su comando sp audit verify comprueba la cadena sin conexión sobre el texto cifrado y no necesita la clave del almacén. Así, un investigador puede comprobar si el registro ha sido alterado sin abrir los secretos del usuario.

Usa un procedimiento sencillo de recopilación para un incidente o una revisión de lanzamiento:

sp audit verify

Un resultado útil tiene una forma clara de aprobación o fallo seguida del intervalo comprobado, por ejemplo:

Audit chain: valid
Records checked: 184
First record: 2026-07-01T14:22:09Z
Last record: 2026-07-22T09:15:44Z

Los campos exactos dependen de la versión instalada del comando, así que guarda la salida sin modificar junto con la versión de la aplicación y el identificador del dispositivo. No copies el contenido del almacén de un desarrollador, la transcripción de instrucciones del agente ni el historial de terminal no relacionado solo porque estés recopilando un resultado de auditoría.

Esta separación también mejora el soporte habitual. Si la consola de MDM muestra la versión esperada pero el desarrollador dice que una acción fue denegada, inspecciona el estado local de la puerta de enlace y la ruta de aprobación. Si el registro de auditoría muestra una acción pero MDM no tiene un registro de instalación actual, investiga un registro de dispositivo obsoleto, un Mac retirado recientemente o una instalación no gestionada. Cada sistema tiene un trabajo concreto. Deja que lo haga bien.

La retirada del dispositivo empieza por el acceso, no por el borrado

Cuando un Mac cambia de manos, se pierde o abandona la empresa, termina primero su relación de acceso antes de borrarlo o liberarlo de la propiedad de la organización. Borrar limpia el disco. No demuestra que las credenciales de nube, las sesiones activas de los agentes o las asignaciones del dispositivo se hayan gestionado correctamente.

Para una devolución corporativa normal, sigue este orden:

1. Identifica el dispositivo, su último usuario asignado, su registro de MDM y si todavía se conecta.
2. Revoca las sesiones activas de la puerta de enlace y pide al responsable del servicio que rote o revoque las credenciales que puedan seguir siendo útiles en otro lugar.
3. Elimina la aplicación gestionada o márcala para su eliminación si el Mac permanece conectado el tiempo suficiente para recibir el comando.
4. Conserva las evidencias mínimas de gestión y auditoría exigidas por las reglas de conservación.
5. Borra el Mac mediante el flujo aprobado de devolución o reasignación de la organización.

No liberes el Mac de Apple Business Manager solo porque un empleado abandone la empresa. La liberación es una decisión de propiedad para hardware vendido, perdido sin posibilidad razonable de recuperación o que ya no pertenece a tu organización. Apple advierte que liberar un dispositivo es irreversible mediante la ruta habitual de asignación, impide futuras asignaciones de MDM y requiere borrar y restaurar el dispositivo después de la liberación. También advierte que no se debe liberar un dispositivo enviado a reparación, porque un reemplazo podría no volver a Apple Business Manager.

Para un Mac corporativo reasignado, conserva la inscripción de la organización, bórralo e inscribe al siguiente usuario mediante el flujo habitual. Para un dispositivo de propiedad personal bajo un modelo de inscripción de usuario, elimina la gestión según la política acordada, confirma qué aplicaciones y ajustes gestionados desaparecerán y haz que el desarrollador elimine sus propias credenciales antes de entregarlo. Apple señala que la baja puede eliminar aplicaciones y contenido gestionados, mientras que las aplicaciones y los ajustes personales permanecen en los dispositivos inscritos por el usuario.

Un Mac perdido necesita una ruta más rápida. Revoca primero las credenciales y las sesiones porque el equipo quizá nunca vuelva a conectarse. Después usa los controles de gestión de dispositivos y el proceso de revocación del responsable del servicio. Esperar a que llegue un comando de eliminación de la aplicación no es contención.

El despliegue funciona cuando sigue siendo aburrido

El mejor despliegue de una puerta de enlace local genera poco drama porque cada límite está definido. El equipo de MDM distribuye una aplicación firmada y controla su ciclo de vida. El desarrollador mantiene las credenciales en un almacén local y puede ver cuándo un agente solicita autoridad. El responsable del servicio concede y revoca el acceso en el origen. El registro de auditoría documenta las acciones sin convertirse en un volcado de secretos.

Empieza con la prueba que revela más suposiciones erróneas: inscribe un Mac gestionado limpio, inicia sesión como un desarrollador normal, instala el paquete de producción mediante MDM, cierra y vuelve a iniciar sesión, añade localmente una credencial no crítica, ejecuta una acción inocua del agente, verifica su registro de auditoría, elimina la aplicación y repite todo desde una inscripción nueva. Si esa secuencia necesita trabajo manual no documentado, un script root oculto o un archivo de credenciales copiado, corrige el despliegue antes de añadir otros cien dispositivos.