Como encamiña SPACE as solicitudes á execución correcta do contorno illado

Cando alguén lle pide a un axente de IA que analice unha folla de cálculo ou que probe software, confía en que traballe de forma segura cos seus ficheiros e datos. Os axentes necesitan contornos illados onde poidan levar a cabo ese traballo sen expoñer os datos doutros usuarios nin interferir nas súas cargas de traballo.

A medida que os axentes asumen tarefas máis complexas con maior autonomía, estes contornos axudan a conter os erros e a limitar o dano que pode causar o código inseguro ou malicioso. Os contornos illados proporcionan ese illamento mentres comparten servizos do plano de control, nodos de traballo e infraestrutura de encamiñamento.

Esa infraestrutura compartida debe entregar cada operación á execución autorizada para xestionala. Unha ruta obsoleta pode enviar unha solicitude válida a outro contorno illado ou a unha execución anterior do contorno illado correcto. SPACE, a plataforma segura de contornos illados de Perplexity, vincula cada operación a unha execución seleccionada e comproba o destino antes de reenviala.

Durante meses, SPACE xestionou millóns de execucións ao día, cada unha protexida por unha identidade criptográfica única, cunha taxa de erros inferior ao 0,0002 % e sen ningunha conexión perdida.

O problema do encamiñamento

A seguridade dos contornos illados tamén depende de que cada solicitude chegue ao destino correcto. Mesmo unha simple lectura de ficheiro pasa por unha infraestrutura compartida que debe saber en todo momento onde se está a executar o contorno illado mentres se pausa, se retoma ou se move entre máquinas.

Unha lectura de ficheiro percorre varios compoñentes. O plano de control de SPACE resolve o contorno illado nunha execución e nun nodo de traballo. A solicitude entra a través de node-api, pasa ao xestor de contornos illados, sbx-manager, e atravesa un socket Unix ata a ponte do host, spaced-host. A ponte reenvíaa por VSOCK, o transporte de sockets entre host e convidado, ata spaced-guest, dentro da microVM de Firecracker.

Cada decisión depende dun estado que pode quedar por detrás dos cambios na infraestrutura. Unha base de datos pode conservar unha localización antiga, un enderezo en caché pode apuntar a outro lugar ou unha ruta de socket pode adquirir un escoitador diferente. Unha conexión establecida correctamente aínda pode chegar ao destino incorrecto. Unha lectura podería expoñer os datos doutro usuario; unha escritura podería modificar o sistema de ficheiros incorrecto.

As instantáneas engaden outro problema. Retomar un contorno illado noutro nodo de traballo conserva a súa identidade lóxica, pero inicia unha nova execución. Unha solicitude atrasada ou unha conexión que sobreviva pode chegar á execución anterior e devolver un estado antigo baixo o nome correcto do contorno illado.

Ampliar

Identidade do contorno illado e identidade de execución

SPACE separa o contorno do usuario do tempo de execución que o serve:

• Identidade do contorno illado: o ID estable do contorno lóxico. A autorización do chamador establece o acceso a este contorno illado.
• Identidade de ruta/execución: A encarnación do contorno de execución seleccionada e a súa ubicación, incluídos o seu worker, o seu substrato e a súa activación.

Unha xeración de execución distingue as encarnacións do tempo de execución. En Kubernetes, a ruta tamén inclúe o UID do pod. Os enderezos localizan os extremos; a identidade da execución determina se eses extremos poden servir a operación.

Supoñamos que o contorno illado S se executa como execución 7 no nodo de traballo A e despois se retoma como execución 8 no nodo de traballo B. Unha solicitude seleccionada para a execución 8 debe fallar se chega á execución 7. Comprobar só o ID do contorno illado non detectaría a discrepancia.

Ampliar

Selección de execución asinada

Cada solicitude leva unha proba asinada de que execución do contorno illado pode xestionala e de que acceso está permitido. O compoñente receptor contrasta esa proba coa súa propia identidade de tempo de execución antes de deixar continuar a solicitude.

Despois da autorización do chamador, SPACE emite unha capacidade asinada de curta duración que identifica o contorno illado, a execución, a localización e o acceso permitido. As capacidades de portos de servizo públicos tamén especifican o porto e o protocolo permitidos.

O xestor de contornos illados receptor verifica a sinatura e compara a identidade completa co seu rexistro de tempo de execución persistido localmente. A sinatura establece quen autorizou a selección. A comparación establece se esa selección coincide co receptor.

O tráfico de ServicePort recibe unha segunda comprobación na pasarela de rede de cada contorno illado, netgtw, antes de que se abra unha conexión co convidado. A pasarela compara a identidade co estado de activación de confianza e comproba o porto e o protocolo. As operacións de control continúan ata a verificación dos extremos da ponte.

SPACE usa sinaturas Ed25519. As claves de sinatura do plano de control emiten capacidades; as claves públicas de verificación dos nodos de traballo e das pasarelas non poden emitilas.

As capacidades duran 120 segundos, cunha tolerancia de ata 15 segundos de desfase de reloxo na caducidade. Unha sinatura válida e un token non caducado seguen sen ser suficientes cando as identidades seleccionada e instalada non coinciden.

Ampliar

Rexeitamento no destino incorrecto

O nodo de traballo receptor pode detectar un erro de encamiñamento mesmo cando a propia solicitude está autorizada. Comproba se a execución que ten en marcha é a seleccionada para esa solicitude e, se non coinciden, rexéitaa.

Se unha solicitude seleccionada para a execución 8 chega ao worker A, que aínda serve a execución 7, o worker A rexéitaa antes de reenviala. Unha vez que un receptor instala a identidade da execución 8, tamén rexeita as capacidades da execución 7, mesmo antes de que caduquen.

Esta garantía ten un límite importante. Unha capacidade para a execución 7 aínda pode coincidir cun nodo de traballo que serve a execución 7 ata que ese nodo teña constancia da retirada ou a capacidade caduque. A aplicación local e a vida limitada das capacidades funcionan conxuntamente mentres se propagan as actualizacións.

Ampliar

Verificación dos extremos da ponte

Un rexistro de tempo de execución coincidente establece a execución prevista. A ponte de control tamén debe chegar aos procesos e ao transporte que pertencen a esa activación, e non a unha substituta que herdase o mesmo enderezo.

Os xestores de contornos illados e de nodos verifican as credenciais do par da ponte do host e as identidades dos procesos tanto da ponte como de Firecracker, incluídas as horas de inicio, e detectan ID reutilizados ou executables modificados

As comprobacións de transporte vinculan o escoitador VSOCK ao proceso de Firecracker esperado mediante a propiedade do socket, a identidade do convidado e as evidencias de sockets do núcleo. A ponte só reenvía operacións despois da verificación e rexeita as reconexións transparentes. Cada nova conexión debe superar de novo as comprobacións.

Esta verificación abrangue a ponte de control de Firecracker en Kubernetes e en hosts xestionados directamente. O tráfico de ServicePort usa comprobacións de execución e de porto na súa pasarela; non certifica a identidade dunha aplicación arbitraria dentro do convidado.

Ampliar

Vida dos fluxos e recuperación de rutas

Algunhas conexións permanecen abertas mentres cambia a execución dun contorno illado, polo que as comprobacións de identidade deben ir máis alá da solicitude inicial. SPACE retira as conexións vinculadas á execución antiga e permite que as operacións aptas se reconecten á actual baixo as mesmas comprobacións de seguridade.

Os terminais e as vixilancias de ficheiros poden durar máis que as solicitudes que os abriron. SPACE vincula os fluxos do backend a unha época de identidade para que un fluxo non poida permanecer ligado á execución anterior despois de que o receptor instale unha execución de substitución.

SPACE volve comprobar a identidade duradeira antes de abrir un fluxo. Substituír a súa ruta ou execución cancela a concesión do fluxo e detén a entrada e a saída.

Os cambios de propiedade son distintos da substitución da execución. Unha transferencia de operacións do ciclo de vida nun residente de Kubernetes sen cambios conserva a súa identidade de ruta, as capacidades non caducadas e os fluxos. A pasarela tamén conserva os fluxos establecidos ante cambios que só afectan ao intento de activación dentro da mesma ruta e xeración de execución. As novas aperturas requiren a identidade actualizada.

A recuperación mantén intactas estas comprobacións. O comparador de identidade pode devolver RefreshRoute se hai unha discrepancia de encarnación dentro do mesmo contorno illado, ou Deny se se trata dun contorno illado diferente. Só un sinal de actualización recoñecido activa a reparación da ruta despois dun rexeitamento de identidade. Os fallos de transporte seguen regras de recuperación separadas e específicas de cada operación. As sinaturas, os propósitos ou os perfís de porto non válidos seguen denegados.

Unha operación apta pode resolver a execución actual e facer un único intento reconstruído. A substitución na caché está condicionada á ruta rexeitada, o que impide que un rexeitamento atrasado expulse unha entrada máis recente. A renovación da sesión nativa conserva a caducidade orixinal da caché, separando a reparación da ruta da renovación da autorización do chamador.

As regras de repetición seguen a depender de cada operación. Un backend de substitución debe superar de novo a admisión, mesmo cando o WebSocket orientado ao cliente segue aberto.

Ampliar

Contrapartidas e límites de confianza

A identidade da execución pasa a ser un estado crítico para a seguridade. As actualizacións do plano de control e os paquetes de claves de verificación deben chegar aos compoñentes que serven as solicitudes, e a retirada faise efectiva cando cada receptor instala a actualización. A curta vida das capacidades limita a reutilización durante a propagación.

O deseño presupón que a aplicación da identidade está activada e confía no asinante do plano de control, no núcleo do nodo de traballo e nos servizos de xestión locais do nodo. O compromiso da conta root do nodo de traballo ou dun administrador de clúster con privilexios queda fóra do modelo de ameazas. A verificación da ponte é unha verificación local de procesos e transporte, non unha atestación remota baseada en hardware.

A verificación de sinaturas, as comparacións do tempo de execución e a validación da ponte engaden traballo á ruta da solicitude. Usan o estado local en lugar dunha consulta de autorización remota en cada salto privado.

Comparativa do sector

A comparación relevante é como xestionan as plataformas unha solicitude autorizada que chega á execución incorrecta do contorno illado correcto. Estas conclusións refírense ás implementacións examinadas, non á seguridade xeral das plataformas. SPACE, OpenShell e E2B revisáronse o 8 de outubro de 2026:

• OpenShell: Ofrece unha selección de execución para novas chamadas e unha vinculación entre supervisor e tempo de execución comparables, mediante comprobacións de xeración e autorización na pasarela, validación da identidade do backend e confirmación de conexións activas do supervisor (admisión na pasarela, autenticación e vinculación do tempo de execución). SPACE leva a selección asinada ao longo de toda a súa ruta de servizo e engade verificación local de procesos e transporte no nodo de traballo; OpenShell distribúe as comprobacións correspondentes entre a súa pasarela, a identidade de lanzamento e o protocolo autenticado do tempo de execución (deseño do tempo de execución).
• E2B: Fai un seguimento dos ID de execución e illa os grupos de proxies segundo o ciclo de vida de Firecracker, pero o seu proxy de entrada selecciona o contorno illado lóxico e o porto sen unha identidade de execución esperada coa que o receptor poida comparar (publicación de rutas, admisión no proxy). Unha execución anterior que aínda figure como activa nun receptor obsoleto con credenciais coincidentes non se pode distinguir, mediante esas comprobacións, da execución máis recente seleccionada, aínda que o desmantelamento normal elimina as rutas e pecha as conexións vinculadas ao ciclo de vida (credenciais, desmantelamento).
• CubeSandbox: Repara o encamiñamento ao retomar e invalida as cachés, pero a entrada privada usa credenciais restrinxidas ao contorno illado e reenvía sen unha encarnación de execución esperada (encamiñamento na retoma, encamiñamento de entrada). A reparación de rutas reduce as xanelas de rutas obsoletas; a capacidade vinculada á execución de SPACE tamén lle dá ao receptor unha base independente para rexeitar a encarnación incorrecta.

A identidade como límite de illamento

A delegación segura depende de manter o traballo de cada axente dentro dos límites previstos para el. Unha microVM proporciona illamento, mentres que a plataforma que a rodea debe garantir que cada solicitude e cada conexión en curso cheguen á execución autorizada para xestionalas.

SPACE fai da identidade da execución parte desa protección. Ao comprobar os destinos, verificar os extremos da ponte e vincular as conexións á execución que as autorizou, preserva eses límites mentres os contornos illados se pausan, se retoman e se moven.

Seguimos traballando nisto a medida que evoluciona a infraestrutura. Para SPACE e outras plataformas de contornos illados, a seguridade require probar estas rutas fronte a erros de encamiñamento habituais e a cargas de traballo hostís, e despois reforzar os límites alí onde esas probas revelen fendas.