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

Cuando alguien le pide a un agente de IA que analice una hoja de cálculo o pruebe software, confía en que trabajará de forma segura con sus archivos y datos. Los agentes necesitan entornos aislados donde puedan realizar ese trabajo sin exponer los datos de otros usuarios ni interferir con 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 con una ejecución seleccionada y verifica el destino antes de reenviarla.

Durante meses, SPACE ha gestionado 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 cero conexiones perdidas.

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 dónde se está ejecutando el entorno aislado mientras se pausa, se reanuda o se mueve entre máquinas.

Una lectura de archivo recorre 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 administrador de entornos aislados, sbx-manager, y cruza un socket de Unix hasta el puente del host, spaced-host. El puente la reenvía mediante VSOCK, el transporte de sockets entre el host y el invitado, hasta spaced-guest dentro de la microVM de Firecracker.

Cada decisión depende de un estado que puede quedarse atrás respecto a los cambios en la infraestructura. Una base de datos puede conservar una ubicación antigua, una dirección en caché puede apuntar a otro lugar o una ruta de socket puede adquirir otro proceso de escucha. Una conexión exitosa aún puede llegar al destino incorrecto. Una lectura podría exponer los datos de otro usuario; una escritura podría modificar el sistema de archivos equivocado.

Las instantáneas agregan 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 que sobrevive podría llegar a su predecesora y devolver un estado antiguo bajo el nombre del entorno aislado correcto.

Ampliar

Identidad del entorno aislado e identidad de ejecución

SPACE separa el entorno del usuario del runtime que lo atiende:

• Identidad del entorno aislado: El ID estable del entorno lógico. La autorización del llamador 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 runtime. En Kubernetes, la ruta también incluye el UID del pod. Las direcciones ubican los endpoints; la identidad de la ejecución determina si esos endpoints pueden atender la operación.

Supongamos que el entorno aislado S se ejecuta como la ejecución 7 en el nodo de trabajo A y luego se reanuda como la 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. Verificar 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 de entorno aislado puede gestionarla y qué acceso está permitido. El componente receptor contrasta esa prueba con su propia identidad de runtime antes de permitir que la solicitud continúe.

Tras la autorización del llamador, SPACE emite una capacidad firmada 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 administrador de entornos aislados receptor verifica la firma y compara la identidad completa con su registro de runtime persistido localmente. La firma establece quién autorizó la selección. La comparación establece si esa selección coincide con el receptor.

El tráfico de ServicePort recibe una segunda verificación en el gateway de red de cada entorno aislado, netgtw, antes de que se abra una conexión con el invitado. El gateway compara la identidad con el estado de activación de confianza y verifica el puerto y el protocolo. Las operaciones de control continúan hacia la verificación de los endpoints del puente.

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

Las capacidades duran 120 segundos, con una tolerancia de hasta 15 segundos de desfase de reloj para la expiración. Una firma válida y un token sin expirar siguen siendo insuficientes 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 solicitud en sí está autorizada. Comprueba si la ejecución que tiene en marcha es la seleccionada para esa solicitud y la rechaza si no coinciden.

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 se entere del retiro o la capacidad expire. La aplicación local de controles y la vida útil acotada de las capacidades funcionan en conjunto mientras se propagan las actualizaciones.

Ampliar

Verificación de los endpoints del puente

Un registro de runtime 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 un reemplazo que heredó la misma dirección.

Los administradores 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 verificaciones de transporte vinculan el socket de escucha de VSOCK con el proceso de Firecracker esperado mediante la propiedad del socket, la identidad del invitado y la evidencia de sockets del kernel. El puente reenvía operaciones solo después de la verificación y rechaza las reconexiones transparentes. Cada conexión nueva debe volver a pasar las verificaciones.

Esta verificación abarca el puente de control de Firecracker en Kubernetes y en hosts administrados directamente. El tráfico de ServicePort usa verificaciones de ejecución y de puerto en su gateway; no da fe de la identidad de una aplicación arbitraria dentro del invitado.

Ampliar

Vida útil 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 verificaciones 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 elegibles se vuelvan a conectar a la actual con las mismas verificaciones de seguridad.

Las terminales y los observadores de archivos pueden sobrevivir a las solicitudes que los abrieron. SPACE vincula los flujos del backend con una época de identidad para que un flujo no pueda permanecer conectado a la ejecución anterior después de que el receptor instale una ejecución de reemplazo.

SPACE vuelve a verificar la identidad persistente antes de abrir un flujo. Reemplazar 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 del reemplazo de una ejecución. Una transferencia de operaciones del ciclo de vida en un residente de Kubernetes sin cambios conserva su identidad de ruta, sus capacidades sin expirar y sus flujos. El gateway también conserva los flujos establecidos ante cambios que solo afectan el intento de activación dentro de la misma ruta y la misma generación de ejecución. Las aperturas nuevas requieren la identidad actualizada.

La recuperación mantiene intactas estas comprobaciones. El comparador de identidad puede devolver RefreshRoute ante una discrepancia de encarnación dentro del mismo entorno aislado, o Deny para un entorno aislado diferente. Solo una señal de actualización reconocida activa la reparación de la ruta después de 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 siendo rechazados.

Una operación elegible puede resolver la ejecución actual y reintentar una sola vez con una solicitud reconstruida. El reemplazo de la entrada en caché está condicionado a la ruta rechazada, lo que evita que un rechazo retrasado desaloje una entrada más reciente. La actualización de la sesión nativa conserva la expiración original de la caché, lo que separa la reparación de rutas de la renovación de la autorización del llamador.

Las reglas de repetición de solicitudes siguen siendo específicas de cada operación. Un backend de reemplazo debe volver a pasar la admisión, incluso cuando el WebSocket del lado del 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 atienden las solicitudes, y el retiro 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 supone que la aplicación de controles de identidad está habilitada y confía en el firmante del plano de control, el kernel del nodo de trabajo y los servicios de administración locales del nodo. Un compromiso del usuario root del nodo de trabajo o de un 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 transporte, no una atestación remota respaldada por hardware.

La verificación de firmas, las comparaciones de runtime y la validación del puente agregan trabajo a la ruta de la solicitud. Usan estado local en lugar de una consulta de autorización remota en cada salto privado.

Comparación con el sector

La comparación relevante es cómo manejan las plataformas una solicitud autorizada que llega a la ejecución incorrecta del entorno aislado correcto. Estos hallazgos se refieren a las implementaciones inspeccionadas, 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 con el runtime comparables, mediante la generación del gateway y verificaciones de autorización, la validación de la identidad del backend y las conexiones de supervisor activas confirmadas (admisión en el gateway, autenticación y vinculación del runtime). SPACE transporta la selección firmada a lo largo de su ruta de servicio y agrega verificación local de procesos y transporte en el nodo de trabajo; OpenShell distribuye las verificaciones correspondientes entre su gateway, la identidad de lanzamiento y el protocolo de runtime autenticado (diseño del runtime).
• E2B: Da seguimiento a 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). Con esas verificaciones, una ejecución anterior que sigue registrada como activa en un receptor obsoleto con credenciales coincidentes no se puede distinguir 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 el ingreso privado usa credenciales con alcance de entorno aislado y reenvía sin una encarnación de runtime esperada (enrutamiento al reanudar, enrutamiento de ingreso). La reparación de rutas reduce los intervalos con rutas obsoletas; la capacidad vinculada a la ejecución de SPACE también le da 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 hace que la identidad de la ejecución forme parte de esa protección. Al verificar los destinos, validar los endpoints del puente y vincular las conexiones con la ejecución que las autorizó, preserva esos límites mientras los entornos aislados se pausan, se reanudan y se mueven.

Seguimos trabajando en esto a medida que la infraestructura evoluciona. 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 luego reforzar los límites dondequiera que esas pruebas revelen brechas.