Cómo SPACE enruta las solicitudes a la ejecución correcta del entorno aislado

Cuando alguien pide a un agente de IA que analice una hoja de cálculo o pruebe software, confía en que trabaje de forma segura con sus archivos y datos. Los agentes necesitan entornos aislados en los que puedan llevar a cabo ese trabajo sin exponer los datos de otros usuarios ni interferir en sus cargas de trabajo.

A medida que los agentes asumen tareas más complejas con mayor autonomía, estos entornos ayudan a contener los errores y a limitar el daño que puede causar el código inseguro o malicioso. Los entornos aislados proporcionan ese aislamiento mientras comparten servicios del plano de control, nodos de trabajo e infraestructura de enrutamiento.

Esa infraestructura compartida debe entregar cada operación a la ejecución autorizada para gestionarla. Una ruta obsoleta puede enviar una solicitud válida a otro entorno aislado o a una ejecución anterior del entorno aislado correcto. SPACE, la plataforma segura de entornos aislados de Perplexity, vincula cada operación a una ejecución seleccionada y comprueba el destino antes de reenviarla.

Desde hace meses, SPACE gestiona millones de ejecuciones al día, cada una protegida por una identidad criptográfica única, con una tasa de error inferior al 0,0002 % y ninguna conexión caída.

El problema del enrutamiento

La seguridad de los entornos aislados también depende de que cada solicitud llegue al destino correcto. Incluso una simple lectura de archivo pasa por una infraestructura compartida que debe saber en todo momento dónde se está ejecutando el entorno aislado mientras se pausa, se reanuda o se traslada entre máquinas.

Una lectura de archivo atraviesa varios componentes. El plano de control de SPACE resuelve el entorno aislado en una ejecución y un nodo de trabajo. La solicitud entra a través de node-api, pasa al gestor de entornos aislados, sbx-manager, y cruza un socket Unix hasta el puente del host, spaced-host. El puente la reenvía mediante VSOCK, el transporte por sockets entre el host y el invitado, a spaced-guest, dentro de la microVM de Firecracker.

Cada decisión se basa en un estado que puede ir por detrás de los cambios en la infraestructura. Una base de datos puede conservar una ubicación antigua, una dirección almacenada en caché puede apuntar a otro lugar o una ruta de socket puede adquirir un agente de escucha diferente. Una conexión que se establece correctamente puede, aun así, llegar al destino equivocado. Una lectura podría exponer los datos de otro usuario; una escritura podría modificar el sistema de archivos equivocado.

Las instantáneas añaden otro problema. Reanudar un entorno aislado en otro nodo de trabajo conserva su identidad lógica, pero inicia una nueva ejecución. Una solicitud retrasada o una conexión superviviente pueden llegar a la ejecución anterior y devolver un estado antiguo bajo el nombre correcto del entorno aislado.

Ampliar

Identidad del entorno aislado e identidad de ejecución

SPACE separa el entorno del usuario del entorno de ejecución que lo atiende:

• Identidad del entorno aislado: El ID estable del entorno lógico. La autorización del llamante establece el acceso a este entorno aislado.
• Identidad de ruta/ejecución: la encarnación del entorno de ejecución seleccionada y su ubicación, incluidos su worker, su sustrato y su activación.

Una generación de ejecución distingue las encarnaciones del entorno de ejecución. En Kubernetes, la ruta también incluye el UID del pod. Las direcciones localizan los extremos; la identidad de la ejecución determina si esos extremos pueden atender la operación.

Supongamos que el entorno aislado S se ejecuta como ejecución 7 en el nodo de trabajo A y después se reanuda como ejecución 8 en el nodo de trabajo B. Una solicitud seleccionada para la ejecución 8 debe fallar si llega a la ejecución 7. Comprobar solo el ID del entorno aislado no detectaría la discrepancia.

Ampliar

Selección de ejecución firmada

Cada solicitud lleva una prueba firmada de qué ejecución del entorno aislado puede gestionarla y qué acceso está permitido. El componente receptor contrasta esa prueba con su propia identidad del entorno de ejecución antes de permitir que la solicitud continúe.

Tras la autorización del llamante, SPACE emite una capacidad firmada y de corta duración que identifica el entorno aislado, la ejecución, la ubicación y el acceso permitido. Las capacidades de puertos de servicio públicos también especifican el puerto y el protocolo permitidos.

El gestor de entornos aislados receptor verifica la firma y compara la identidad completa con el registro del entorno de ejecución que conserva de forma persistente en local. La firma establece quién autorizó la selección. La comparación establece si esa selección corresponde al receptor.

El tráfico de ServicePort se somete a una segunda comprobación en la pasarela de red de cada entorno aislado, netgtw, antes de que se abra una conexión con el invitado. La pasarela compara la identidad con el estado de activación de confianza y comprueba el puerto y el protocolo. Las operaciones de control pasan a la verificación de los extremos del puente.

SPACE utiliza firmas Ed25519. Las claves de firma del plano de control emiten capacidades; las claves públicas de verificación de los nodos de trabajo y las pasarelas no pueden emitirlas.

Las capacidades duran 120 segundos, con un margen de hasta 15 segundos de desfase de reloj para la caducidad. Una firma válida y un token sin caducar siguen sin ser suficientes cuando las identidades seleccionada e instalada no coinciden.

Ampliar

Rechazo en el destino incorrecto

El nodo de trabajo receptor puede detectar un error de enrutamiento incluso cuando la propia solicitud está autorizada. Comprueba si la ejecución que tiene en marcha es la seleccionada para esa solicitud y, si no coinciden, rechaza la solicitud.

Si una solicitud seleccionada para la ejecución 8 llega al worker A, que todavía atiende la ejecución 7, el worker A la rechaza antes de reenviarla. Una vez que un receptor instala la identidad de la ejecución 8, también rechaza las capacidades de la ejecución 7, incluso antes de que caduquen.

Esta garantía tiene un límite importante. Una capacidad para la ejecución 7 todavía puede coincidir con un nodo de trabajo que sirve la ejecución 7 hasta que ese nodo tenga constancia de la retirada o la capacidad caduque. La aplicación local de las comprobaciones y la vida útil limitada de las capacidades actúan conjuntamente mientras se propagan las actualizaciones.

Ampliar

Verificación de los extremos del puente

Un registro del entorno de ejecución coincidente establece la ejecución prevista. El puente de control también debe llegar a los procesos y al transporte que pertenecen a esa activación, y no a una sustitución que haya heredado la misma dirección.

Los gestores de entornos aislados y de nodos verifican las credenciales del par del puente del host y las identidades de los procesos tanto del puente como de Firecracker, incluidas sus horas de inicio, lo que permite detectar ID reutilizados o ejecutables modificados

Las comprobaciones del transporte vinculan el agente de escucha VSOCK al proceso de Firecracker esperado mediante la propiedad del socket, la identidad del invitado y las evidencias de socket del kernel. El puente solo reenvía operaciones después de la verificación y rechaza las reconexiones transparentes. Cada conexión nueva debe superar de nuevo las comprobaciones.

Esta verificación abarca el puente de control de Firecracker en Kubernetes y en hosts gestionados directamente. El tráfico de ServicePort utiliza comprobaciones de ejecución y de puerto en su pasarela; no certifica la identidad de una aplicación arbitraria dentro del invitado.

Ampliar

Duración de los flujos y recuperación de rutas

Algunas conexiones permanecen abiertas mientras cambia la ejecución de un entorno aislado, por lo que las comprobaciones de identidad deben ir más allá de la solicitud inicial. SPACE retira las conexiones vinculadas a la ejecución anterior y permite que las operaciones aptas se vuelvan a conectar a la actual con las mismas comprobaciones de seguridad.

Los terminales y la vigilancia de archivos pueden sobrevivir a las solicitudes que los abrieron. SPACE vincula los flujos del backend a una época de identidad para que un flujo no pueda seguir vinculado a la ejecución anterior después de que el receptor instale una ejecución de sustitución.

SPACE vuelve a comprobar la identidad persistente antes de abrir un flujo. Sustituir su ruta o su ejecución cancela la concesión del flujo, lo que detiene la entrada y la salida.

Los cambios de propiedad son distintos de la sustitución de la ejecución. El traspaso de una operación del ciclo de vida en un residente de Kubernetes que no ha cambiado conserva su identidad de ruta, sus capacidades sin caducar y sus flujos. La pasarela también conserva los flujos establecidos ante cambios que solo afectan al intento de activación dentro de la misma ruta y generación de ejecución. Las aperturas nuevas requieren la identidad actualizada.

La recuperación mantiene intactas estas comprobaciones. El comparador de identidades puede devolver RefreshRoute si hay una discrepancia de encarnación dentro del mismo entorno aislado, o Deny si se trata de un entorno aislado distinto. Solo una señal de actualización reconocida desencadena la reparación de la ruta tras un rechazo de identidad. Los fallos de transporte siguen reglas de recuperación independientes y específicas de cada operación. Las firmas, los propósitos o los perfiles de puerto no válidos siguen denegándose.

Una operación apta puede resolver la ejecución actual y realizar un único intento reconstruido. La sustitución de la entrada en caché está condicionada a la ruta rechazada, lo que impide que un rechazo retrasado expulse una entrada más reciente. La actualización de la sesión nativa conserva la caducidad original de la caché, lo que separa la reparación de rutas de la renovación de la autorización del llamante.

Las reglas de repetición siguen siendo específicas de cada operación. Un backend de sustitución debe superar de nuevo la admisión, incluso cuando el WebSocket orientado al cliente permanece abierto.

Ampliar

Concesiones y límites de confianza

La identidad de la ejecución se convierte en un estado crítico para la seguridad. Las actualizaciones del plano de control y los paquetes de claves de verificación deben llegar a los componentes que prestan servicio, y la retirada surte efecto cuando cada receptor instala la actualización. La corta vida útil de las capacidades limita su reutilización durante la propagación.

El diseño presupone que la aplicación obligatoria de la identidad está habilitada y confía en el firmante del plano de control, el kernel del nodo de trabajo y los servicios de gestión locales del nodo. La vulneración del usuario root del nodo de trabajo o de una cuenta de administrador de clúster con privilegios queda fuera del modelo de amenazas. La verificación del puente es una verificación local de procesos y del transporte, no una atestación remota respaldada por hardware.

La verificación de firmas, las comparaciones del entorno de ejecución y la validación del puente añaden trabajo a la ruta de la solicitud. Utilizan el estado local en lugar de una consulta de autorización remota en cada salto privado.

Comparativa del sector

La comparación relevante es cómo gestionan las plataformas una solicitud autorizada que llega a la ejecución incorrecta del entorno aislado correcto. Estas conclusiones se refieren a las implementaciones examinadas, no a la seguridad general de las plataformas. SPACE, OpenShell y E2B se revisaron el 8 de octubre de 2026:

• OpenShell: Ofrece una selección de ejecución para llamadas nuevas y una vinculación del supervisor al entorno de ejecución comparables mediante comprobaciones de generación y autorización en la pasarela, la validación de la identidad del backend y conexiones de supervisor activas confirmadas (admisión en la pasarela, autenticación y vinculación del entorno de ejecución). SPACE transporta la selección firmada a lo largo de toda su ruta de servicio y añade una verificación local, en el nodo de trabajo, de los procesos y del transporte; OpenShell distribuye las comprobaciones correspondientes entre su pasarela, la identidad de lanzamiento y el protocolo autenticado del entorno de ejecución (diseño del entorno de ejecución).
• E2B: Hace un seguimiento de los ID de ejecución y aísla los grupos de proxies según el ciclo de vida de Firecracker, pero su proxy de entrada selecciona el entorno aislado lógico y el puerto sin una identidad de ejecución esperada que el receptor pueda comparar (publicación de rutas, admisión en el proxy). Esas comprobaciones no permiten distinguir una ejecución anterior que sigue registrada como activa en un receptor obsoleto con credenciales coincidentes de la ejecución más reciente seleccionada, aunque el desmontaje normal elimina las rutas y cierra las conexiones vinculadas al ciclo de vida (credenciales, desmontaje).
• CubeSandbox: Repara el enrutamiento al reanudar e invalida las cachés, pero la entrada privada utiliza credenciales con ámbito de entorno aislado y reenvía sin una encarnación esperada del entorno de ejecución (enrutamiento de reanudación, enrutamiento de entrada). La reparación de rutas reduce los intervalos con rutas obsoletas; la capacidad vinculada a la ejecución de SPACE también proporciona al receptor una base independiente para rechazar la encarnación incorrecta.

La identidad como límite de aislamiento

Una delegación segura depende de mantener el trabajo de cada agente dentro de los límites previstos para él. Una microVM proporciona aislamiento, mientras que la plataforma que la rodea debe garantizar que cada solicitud y cada conexión en curso lleguen a la ejecución autorizada para gestionarlas.

SPACE incorpora la identidad de la ejecución a esa protección. Al comprobar los destinos, verificar los extremos del puente y vincular las conexiones a la ejecución que las autorizó, preserva esos límites mientras los entornos aislados se pausan, se reanudan y se trasladan.

Seguimos trabajando en ello a medida que evoluciona la infraestructura. Para SPACE y otras plataformas de entornos aislados, la seguridad exige probar estas rutas tanto frente a errores de enrutamiento habituales como frente a cargas de trabajo hostiles, y reforzar después los límites allí donde esas pruebas revelen carencias.