Las bóvedas de agentes de Migration Assistant necesitan un arranque en frío

Una transferencia de Mac no es un traslado inocuo cuando los agentes autónomos pueden acceder a API y hosts SSH. Crea una máquina nueva, una frontera de seguridad de hardware nueva, procesos en ejecución nuevos y un momento nuevo en el que alguien debe decidir qué autoridad sigue estando justificada. Si los agentes recuperan el acceso externo porque el escritorio parece familiar, la migración ha omitido la única parte que importa.

Migration Assistant puede transferir documentos, aplicaciones, cuentas de usuario y ajustes desde otro Mac, PC o copia de seguridad. Eso resulta útil para volver a trabajar. No significa que todas las propiedades de seguridad de la máquina original deban sobrevivir. Apple documenta expresamente que las claves del Secure Enclave y los elementos del llavero marcados como ThisDeviceOnly no migran a otro dispositivo.

La regla de operación segura es sencilla: transfiere lo que ayude a investigar y reconstruir, y después exige pruebas nuevas antes de que cualquier agente pueda usar una credencial o abrir una sesión remota. Una bóveda que se niega a abrirse después de una transferencia quizá esté haciendo exactamente aquello para lo que la contrataste.

Un Mac transferido es un endpoint nuevo

Un Mac nuevo puede tener el mismo nombre de usuario, la misma ruta del directorio personal, las mismas aplicaciones y la misma copia del proyecto. Ninguno de esos datos lo convierte en el mismo endpoint de seguridad. Han cambiado el procesador, el Secure Enclave, el registro biométrico, el contexto del cifrado del disco, el estado del sistema instalado, la conexión de red y el historial de procesos locales.

Los equipos suelen hacer la comparación equivocada. Preguntan si la máquina de destino tiene los mismos archivos. Deberían preguntar si el destino puede demostrar que posee la misma autoridad sin copiar una autoridad que debía permanecer en local. Cuando la bóveda usa protección vinculada al dispositivo, esos objetivos se contradicen.

La documentación de seguridad de Apple marca claramente el límite. Una clave privada del Secure Enclave se crea dentro del enclave, no puede importar una clave privada preexistente y solo puede usarla el enclave que la creó. Apple también indica que un elemento del llavero que use kSecAttrAccessibleWhenUnlockedThisDeviceOnly no migra a un dispositivo nuevo.

Este comportamiento puede parecer incómodo al sustituir un portátil con prisa. Evita que un contenedor de aplicación copiado, una copia de seguridad o una transferencia de migración se conviertan en un token portador transportable para el acceso externo. No esquives el fallo exportando secretos a un archivo de notas, una variable de entorno, el historial del shell o una entrada genérica de un gestor de contraseñas. Sustituirías una frontera de hardware deliberada por un archivo que puede propagarse mucho más lejos de lo que jamás podría el portátil antiguo.

Define las expectativas del cambio antes de tocar Migration Assistant:

• El Mac antiguo sigue siendo la fuente autorizada del acceso existente hasta que el destino supere las pruebas.
• El Mac nuevo empieza con la ejecución de agentes bloqueada o desconectada de las credenciales de producción.
• Un archivo transferido es una prueba que hay que inspeccionar, no un permiso para actuar.
• Cada aprobación y cada vínculo de credencial necesita un resultado esperado explícito.

Esto es una reinscripción controlada, aunque la mayor parte de los datos de la aplicación se copie correctamente. Llamarlo transferencia no cambia el trabajo de seguridad.

Cuatro tipos de estado fallan de formas distintas

Los datos de la aplicación, las aprobaciones, los registros de auditoría y los vínculos de credenciales suelen almacenarse cerca unos de otros. No deben tratarse como una sola cosa. Cada uno responde a una pregunta diferente y una migración puede producir un resultado distinto para cada uno.

Los datos de la aplicación son el estado local ordinario: preferencias, definiciones de endpoints, etiquetas, metadatos no secretos y, posiblemente, blobs de bóveda cifrados. Pueden transferirse intactos. Su presencia solo demuestra que la operación de copia los encontró.

Las aprobaciones son decisiones limitadas en el tiempo sobre un proceso de agente concreto. Responden a la pregunta: «¿Puede este proceso actuar durante esta ejecución?». Una aprobación que siga visible en una base de datos local después de la transferencia no debe autorizar un proceso en un Mac nuevo. El proceso tiene una cadena de procesos padre nueva, una ubicación nueva del ejecutable, un entorno nuevo y quizá un estado de firma distinto.

Los registros de auditoría son pruebas de lo ocurrido. Pueden y deben sobrevivir si la transferencia conserva los archivos cifrados relevantes. Deben mantener sus propiedades de orden e integridad, no limitarse a seguir siendo legibles en una vista de diario.

Los vínculos de credenciales indican si el hardware de destino puede usar la protección criptográfica que rodea un secreto. El blob cifrado puede copiarse aunque la capacidad local para desenvolverlo no lo haga. Esta es la distinción que confunde incluso a ingenieros cuidadosos: que el texto cifrado esté disponible no significa que la credencial esté disponible.

Escribe estos cuatro estados en una hoja de trabajo de migración antes de la transferencia. No registres un resultado impreciso como «bóveda migrada». Registra un resultado por estado:

El caso incómodo es el éxito parcial. La aplicación se inicia, aparecen los ajustes, está presente el historial de auditoría antiguo y la bóveda no puede desbloquearse. Eso no es una migración fallida. Es una migración que conservó las pruebas y la configuración, pero se negó a transferir la autoridad vinculada al dispositivo. Acepta el resultado y vuelve a inscribir las credenciales.

Congela el acceso de los agentes antes de copiar nada

No empieces con Migration Assistant. Empieza asegurándote de que ningún agente pueda emitir una solicitud mientras no tengas claro qué Mac posee la autoridad.

Primero, detén las ejecuciones activas de los agentes en el Mac original. Si el agente lo gestiona un multiplexor de terminal, una extensión del editor, una tarea en segundo plano o un lanzador local similar a CI, detén cada punto de entrada. Cierra las sesiones de terminal que los iniciaron. Cerrar una ventana no demuestra que haya terminado un proceso hijo.

Segundo, registra el estado de origen fuera de la aplicación. Anota la fecha y la hora, el número de serie o la identidad interna del activo del Mac original, la cuenta de usuario, los procesos de agentes que estaban activos y los nombres de los sistemas remotos a los que podían conectarse. No pongas secretos en este registro. Necesitas una cronología que explique las pruebas posteriores, no una copia de la bóveda.

Tercero, desconecta el destino de las redes importantes hasta su primera prueba controlada. Eso puede significar retirar un perfil VPN de producción durante la configuración inicial, denegar una regla del firewall o simplemente mantener el Mac nuevo fuera de la red hasta completar las comprobaciones locales. Un portátil que no puede llegar a una API externa no puede demostrar accidentalmente que se aceptó una autorización antigua.

Cuarto, decide quién tiene autoridad para aceptar aprobaciones nuevas. Esto importa más de lo que los equipos suelen admitir. Una migración a menudo ocurre mientras otra persona configura la máquina nueva, restaura copias de seguridad o arregla un portátil dañado. Quien pulse una tarjeta de aprobación debe saber qué binario de agente está aprobando y por qué necesita esa capacidad.

Usa un registro breve de entrega como este:

Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator

La fecha mostrada es un formato de ejemplo, no un identificador mágico. Lo importante es que más adelante puedas relacionar la cola de auditoría de origen, la primera aprobación del destino y la primera acción correcta con un único registro del cambio.

Los archivos de la aplicación pueden moverse sin mover la confianza

Inspecciona el estado de la aplicación en dos pasadas: primero para comprobar que está completo y después para comprobar la autoridad. No las mezcles. La integridad te dice qué debes restaurar. La autoridad te dice qué debes rechazar o reconstruir.

Después de la transferencia, inicia la aplicación mientras el destino siga sin poder acceder a los servicios de producción. Confirma que su configuración visible sea coherente: nombres de endpoints, etiquetas, detalles de enrutamiento no secretos y cualquier vista local del diario que esperes. Compáralos con el Mac original mientras siga disponible. Si falta un endpoint, reconstrúyelo deliberadamente. Si aparece uno que nadie reconoce, elimínalo y averigua de dónde salió.

Después busca cualquier estado que pueda provocar acciones automáticas. Algunos ejemplos son integraciones de agentes que se inician automáticamente, entradas del perfil del shell que lanzan un conector, tareas del editor, launch agents, plantillas de comandos guardadas y preferencias de la aplicación que vuelven a abrir sesiones anteriores. Una migración puede conservar ajustes de comodidad que son inofensivos para un editor de texto y peligrosos para un agente capaz de llamar a API de producción.

Apple afirma que Migration Assistant transfiere aplicaciones, cuentas, documentos y ajustes. Esa categoría amplia explica por qué necesitas esta revisión en lugar de suponer que solo se movieron archivos personales.

No uses la presencia de un directorio como condición de aprobación. Un diseño de seguridad puede transferir deliberadamente un archivo de bóveda cifrado y dejar atrás el material necesario para desenvolverlo. Una bóveda que parece vacía también puede ser correcta si la aplicación decide no copiar el estado de seguridad local. La única pregunta útil es si el resultado coincide con el diseño que esperas.

En Sallyport, la bóveda está cifrada dentro de la aplicación y la barrera de la bóveda es absoluta. En los Mac con la ruta de hardware compatible, la barrera usa Secure Enclave y Touch ID, y bloqueado significa que se deniega toda acción. Por tanto, una carga útil de bóveda copiada no demuestra que el destino pueda usar la autoridad del Mac original.

Documenta cada resultado observado con un lenguaje exacto. Escribe «estado cifrado presente; la barrera del destino sigue bloqueada» en lugar de «la migración ha fallado». Escribe «lanzador del agente desactivado antes de la primera ejecución» en lugar de «probablemente detenido». Estos detalles evitan que un operador posterior trate una prueba incompleta como un cambio realizado correctamente.

Las aprobaciones antiguas no deben autorizar un proceso nuevo

La aprobación de sesión y el acceso a credenciales son controles separados. Un Mac nuevo debe superar ambos, en el orden correcto. La barrera de la bóveda determina si es posible realizar alguna acción. La autorización de sesión determina si esta ejecución concreta del agente puede hacer llamadas. Un requisito por llamada determina si una credencial concreta exige otra decisión humana en cada uso.

Es fácil confundir estas capas porque el usuario ve que una acción tiene éxito o falla. No aceptes esa ambigüedad durante la migración. Pruébalo deliberadamente.

Inicia un proceso de agente nuevo solo después de que la bóveda del destino esté en el estado de bloqueo o desbloqueo previsto. Pídele una acción inocua con una credencial que no pueda modificar sistemas de producción. El resultado esperado para la sesión es una solicitud de aprobación nueva. Inspecciona la identidad del proceso y la autoridad de firma que muestra la interfaz de aprobación, y aprueba únicamente la ejecución que acabas de iniciar.

Si un proceso de agente realiza una acción en el destino sin un evento de autorización nuevo, detente. No te felicites porque la transferencia te haya ahorrado tiempo. Encuentra el camino que concedió la autoridad. Puede ser un proceso superviviente, una base de datos de sesiones restaurada, una integración que se inicia fuera del intermediario previsto o un modelo de aprobación que no vincula la autoridad con suficiente precisión al ciclo de vida del proceso.

La autorización de sesiones de Sallyport está activada de forma predeterminada y muestra la primera llamada de un proceso de agente nuevo como una tarjeta de aprobación que presenta primero la autoridad de firma del proceso. Una aprobación dura solo durante esa ejecución, hasta que termina, así que un proceso nuevo iniciado en el destino es el lugar correcto para exigir una decisión nueva.

Prueba las credenciales por llamada por separado. Marca una credencial de prueba inocua para que requiera aprobación en cada uso. Haz dos llamadas desde la misma ejecución aprobada del agente. Deberías ver una decisión en cada uso de esa credencial, mientras que la decisión de sesión no debería repetirse simplemente porque el mismo proceso siga ejecutándose. Así sabrás si probaste la capa de sesión o la capa por llamada, en vez de adivinarlo a partir de una sola ventana emergente.

Una tabla de pruebas razonable es pequeña:

No hagas esta prueba con un despliegue de producción porque no solo estás probando una ventana emergente. Estás comprobando si el endpoint nuevo reconoce correctamente el ciclo de vida del proceso y la política de credenciales.

El historial de auditoría necesita verificación, no una revisión visual

Una vista del diario que contiene las entradas de ayer resulta útil, pero no demuestra que el registro transferido siga completo. Una migración puede omitir un archivo, copiar una instantánea antigua, interrumpir una actualización o mostrarte un índice almacenado en caché. Las pruebas de auditoría necesitan una comprobación de integridad.

Conserva el Mac original antes de ejecutar la primera acción en el destino. Captura la marca de tiempo final del origen y registra cuántas sesiones y llamadas esperas ver alrededor del cambio. Después compara la vista histórica del destino. Buscas continuidad, no una colocación idéntica en pantalla ni el mismo orden de presentación.

Sallyport proyecta sus diarios de Sessions y Activity a partir de un registro de auditoría cifrado, encadenado mediante hashes y de escritura ciega. Su verificador puede comprobar la cadena sin conexión sobre el texto cifrado, sin una clave de bóveda. Ese diseño ofrece a las pruebas de migración un punto concreto de aprobación o fallo, en lugar de pedir al operador que revise visualmente una lista de acciones antiguas.

Ejecuta el verificador en el origen antes del traslado si puedes y vuelve a ejecutarlo en el destino antes de permitir cualquier acción del agente. Guarda la salida estándar y el código de salida sin suponer un formato concreto del mensaje:

sp audit verify \> audit-verify.txt 2\>\&1
status=$?
printf 'sp audit verify exit=%s\\n' \"$status\"

Guarda audit-verify.txt con el registro de migración, no en un hilo de chat que desaparecerá. Un código de salida cero solo es útil si también indicas qué endpoint lo produjo y cuándo. Si el verificador informa de un error o devuelve un estado distinto de cero, detén el proceso del cambio. Conserva el origen intacto, copia la salida de diagnóstico e investiga la transferencia en lugar de iniciar un diario nuevo que oculte la discontinuidad.

Hay otra distinción que conviene mantener: el historial de auditoría transferido demuestra lo que registró el endpoint antiguo; la actividad del destino demuestra lo que hace el nuevo endpoint después del cambio. No los mezcles mentalmente. La primera llamada del destino debe ser fácil de localizar, estar vinculada a la autorización de sesión nueva y ser claramente posterior a la última llamada del origen.

Vuelve a inscribir las credenciales en lugar de extraerlas

El atajo habitual consiste en exportar un token API o una clave privada SSH del Mac antiguo, pegarlo en el nuevo y prometer que se limpiará después. Es popular porque funciona rápido. Es incorrecto cuando el diseño antiguo mantenía deliberadamente la credencial fuera del agente y vinculaba el uso local a una bóveda protegida.

La reinscripción cambia la pregunta de «¿Cómo copio este secreto?» a «¿Quién debe conceder autoridad nueva a este endpoint?». Esa es una pregunta más saludable. Puede requerir crear un token API nuevo, registrar una clave pública SSH nueva u obtener una credencial nueva del propietario del sistema. También crea un punto de revocación limpio para el Mac antiguo.

Para el acceso HTTP, crea una credencial de prueba desechable y de solo lectura cuando el servicio remoto lo permita. Dale acceso a un único recurso inocuo. Haz que el agente recién aprobado solicite ese recurso. Revisa el resultado devuelto y la entrada de auditoría local. Después revoca la credencial de prueba o deja que caduque conforme al proceso habitual del servicio.

Para SSH, usa una cuenta de prueba dedicada o un host de prueba restringido. El primer comando debe ser de observación, como mostrar la identidad de la cuenta remota y el directorio de trabajo actual. No conviertas la primera prueba de éxito en un push al repositorio, una publicación de paquetes, un comando de base de datos o un disparador de despliegue. Esas acciones dificultan mucho la depuración porque modifican precisamente el sistema que intentas proteger.

Una credencial que exige aprobación por llamada resulta especialmente útil en esta fase. Obliga a una persona a observar exactamente cuándo comienza el uso externo. Cuando el destino haya superado las pruebas de autorización, auditoría y acción inocua, vuelve a inscribir las credenciales de producción mediante su proceso normal de propiedad. Revoca la credencial antigua o elimina la autorización del endpoint antiguo en cuanto el sistema remoto permita distinguirlo.

No confundas un archivo de clave SSH con una identidad SSH que deba pertenecer al Mac nuevo. Una clave privada copiada puede autenticarse, pero eso solo demuestra que un servidor aceptó el mismo material criptográfico. No dice nada sobre si la transferencia conservó tu modelo de seguridad local. Endpoint nuevo, registro de identidad nuevo e historial de auditoría nuevo.

La primera acción real debe ser deliberadamente aburrida

La primera acción cercana a producción debe indicar si toda la cadena funciona sin crear trabajo de limpieza. Elige una operación de solo lectura, limitada a un objeto de prueba inerte y fácil de encontrar tanto en los registros remotos como en el diario de actividad local.

Algunas buenas opciones son leer los metadatos de un objeto API de prueba, listar un directorio SSH vacío dedicado o consultar la identidad autenticada actual de un servicio. Las malas opciones incluyen crear recursos en la nube, rotar credenciales compartidas, publicar artefactos, cambiar ajustes del repositorio y ejecutar comandos que usen expansión del shell sobre rutas reales.

Ejecuta la acción una vez. Confirma lo siguiente en el orden en que ocurrió:

1. La bóveda del destino estaba en el estado previsto antes de la solicitud.
2. El proceso de agente nuevo recibió una autorización de sesión nueva.
3. Una credencial por llamada solicitó aprobación si su configuración la exigía.
4. El sistema remoto registró la acción inocua esperada.
5. El registro de actividad del destino coincide con la acción que autorizaste.

Si falta alguna observación, no repitas la acción hasta entender el motivo. Repetir una prueba opaca suele crear un montón de registros casi idénticos sin ninguna explicación. Un éxito limpio aporta más información que cinco reintentos apresurados.

Después de superar esa acción, activa el acceso externo de una credencial cada vez. Evita activar todos los endpoints guardados en una tarde solo porque la máquina de destino por fin se puede usar. Un token de producción, una identidad SSH de infraestructura y un token personal de servicio no tienen el mismo riesgo ni necesitan el mismo aprobador. Actívalos en el orden que conceda la menor autoridad primero.

Conserva el Mac antiguo hasta cerrar las pruebas

No borres ni entregues el Mac original cuando el destino se inicie correctamente. Mantenlo disponible, con los agentes desactivados, hasta que el registro de transferencia esté completo y puedas explicar las pruebas de ambos lados.

El registro de cierre debe incluir el último estado de auditoría verificado del origen, el primer estado de auditoría verificado del destino, el resultado de las pruebas de aprobación nueva, las credenciales que se reinscribieron, las credenciales que se revocaron y la persona que autorizó el acceso de producción. No es burocracia sin más. Es la forma de responder después a la pregunta de si una acción procedió de la máquina antigua, de la nueva o de una coincidencia no planificada.

Después revoca las sesiones activas del origen. Retira el origen de las listas de permitidos de acceso remoto cuando existan. Revoca los tokens específicos del origen y los registros SSH una vez que el reemplazo funcione. Por último, comprueba que el endpoint antiguo no pueda recuperar el acceso simplemente al volver a conectarse.

La prueba que más importa no es si Migration Assistant transfirió lo suficiente. Es si el destino tuvo que volver a ganarse la autoridad externa. Si la respuesta es sí, el Mac nuevo empieza con una frontera defendible. Si la respuesta es no, mantén los agentes desconectados hasta poder explicar exactamente qué atravesó la transferencia y por qué.