Como o SPACE encaminha pedidos para a execução de sandbox certa

Quando alguém pede a um agente de IA que analise uma folha de cálculo ou teste software, está a confiar que este trabalhe em segurança com os seus ficheiros e dados. Os agentes precisam de ambientes isolados onde possam realizar esse trabalho sem expor os dados de outros utilizadores nem interferir com as suas cargas de trabalho.

À medida que os agentes assumem tarefas mais complexas com maior autonomia, estes ambientes ajudam a conter erros e a limitar os danos que código inseguro ou malicioso pode causar. As sandboxes proporcionam esse isolamento, partilhando ao mesmo tempo serviços do plano de controlo, nós de trabalho e infraestrutura de encaminhamento.

Essa infraestrutura partilhada tem de entregar cada operação à execução autorizada a processá-la. Uma rota obsoleta pode enviar um pedido válido para outra sandbox ou para uma execução anterior da sandbox certa. O SPACE, a plataforma de sandbox segura da Perplexity, vincula cada operação a uma execução selecionada e verifica o destino antes de a reencaminhar.

Há meses que o SPACE processa milhões de execuções por dia, cada uma protegida por uma identidade criptográfica única, com uma taxa de erro inferior a 0,0002% e sem qualquer ligação perdida.

O problema do encaminhamento

A segurança das sandboxes também depende de fazer chegar cada pedido ao destino certo. Até uma simples leitura de ficheiro passa por infraestrutura partilhada que tem de acompanhar onde a sandbox está a ser executada à medida que é pausada, retomada ou movida entre máquinas.

Uma leitura de ficheiro passa por vários componentes. O plano de controlo do SPACE resolve a sandbox para uma execução e um worker. O pedido entra através do node-api, passa para o gestor de sandboxes, o sbx-manager, e atravessa um socket Unix até à ponte do anfitrião, o spaced-host. A ponte reencaminha-o através de VSOCK, o transporte por socket entre anfitrião e convidado, até ao spaced-guest, dentro da microVM Firecracker.

Cada decisão depende de estado que pode ficar desfasado das alterações na infraestrutura. Uma base de dados pode manter uma colocação antiga, um endereço em cache pode apontar para outro lado ou um caminho de socket pode passar a ter um listener diferente. Uma ligação bem-sucedida pode, ainda assim, chegar ao destino errado. Uma leitura poderia expor os dados de outro utilizador; uma escrita poderia modificar o sistema de ficheiros errado.

Os snapshots acrescentam outro problema. Retomar uma sandbox noutro worker preserva a sua identidade lógica, mas inicia uma nova execução. Um pedido atrasado ou uma ligação que sobreviva pode chegar à execução antecessora e devolver estado antigo sob o nome da sandbox certa.

Expandir

Identidade da sandbox e identidade da execução

O SPACE separa o ambiente do utilizador do runtime que o serve:

• Identidade da sandbox: O ID estável do ambiente lógico. A autorização do chamador estabelece o acesso a esta sandbox.
• Identidade de rota/execução: a encarnação de runtime selecionada e o respetivo posicionamento, incluindo o worker, o substrato e a ativação.

Uma geração de execução distingue as encarnações do runtime. No Kubernetes, a rota inclui também o UID do pod. Os endereços localizam endpoints; a identidade da execução determina se esses endpoints podem servir a operação.

Suponhamos que a sandbox S é executada como execução 7 no worker A e, depois, é retomada como execução 8 no worker B. Um pedido selecionado para a execução 8 tem de falhar se chegar à execução 7. Verificar apenas o ID da sandbox não detetaria a divergência.

Expandir

Seleção de execução assinada

Cada pedido transporta uma prova assinada que indica que execução de sandbox o pode processar e que acesso é permitido. O componente recetor compara essa prova com a sua própria identidade de runtime antes de deixar o pedido prosseguir.

Após a autorização do chamador, o SPACE emite uma capacidade assinada de curta duração que identifica a sandbox, a execução, a colocação e o acesso permitido. As capacidades de portas de serviço públicas também especificam a porta e o protocolo permitidos.

O gestor de sandboxes recetor verifica a assinatura e compara a identidade completa com o seu registo de runtime persistido localmente. A assinatura estabelece quem autorizou a seleção. A comparação estabelece se essa seleção corresponde ao recetor.

O tráfego ServicePort é sujeito a uma segunda verificação no gateway de rede de cada sandbox, o netgtw, antes de ser aberta uma ligação ao convidado. O gateway compara a identidade com o estado de ativação fidedigno e verifica a porta e o protocolo. As operações de controlo avançam para a verificação dos endpoints da ponte.

O SPACE utiliza assinaturas Ed25519. As chaves de assinatura do plano de controlo emitem capacidades; as chaves públicas de verificação nos workers e gateways não as podem emitir.

As capacidades duram 120 segundos, com uma tolerância de até 15 segundos para a dessincronização de relógio na expiração. Uma assinatura válida e um token não expirado continuam a ser insuficientes quando as identidades selecionada e instalada não coincidem.

Expandir

Rejeição no destino errado

O worker recetor consegue detetar um erro de encaminhamento mesmo quando o próprio pedido está autorizado. Verifica se a execução que está a correr é a selecionada para esse pedido e rejeita-o se forem diferentes.

Se um pedido selecionado para a execução 8 chegar ao worker A, que ainda serve a execução 7, o worker A rejeita-o antes de o reencaminhar. Assim que um recetor instala a identidade da execução 8, rejeita também as capacidades da execução 7, mesmo antes de expirarem.

Esta garantia tem um limite importante. Uma capacidade para a execução 7 pode continuar a corresponder a um worker que serve a execução 7 até esse worker tomar conhecimento da desativação ou até a capacidade expirar. A aplicação local e o tempo de vida limitado das capacidades atuam em conjunto enquanto as atualizações se propagam.

Expandir

Verificação dos endpoints da ponte

Um registo de runtime correspondente estabelece a execução pretendida. A ponte de controlo também tem de chegar aos processos e ao transporte que pertencem a essa ativação, e não a uma substituta que herdou o mesmo endereço.

Os gestores de sandboxes e de nós verificam as credenciais do par da ponte do anfitrião e as identidades dos processos da ponte e do Firecracker, incluindo as horas de início, detetando IDs reutilizados ou executáveis alterados

As verificações de transporte associam o listener VSOCK ao processo Firecracker esperado, recorrendo à propriedade do socket, à identidade do convidado e a provas ao nível dos sockets do kernel. A ponte só reencaminha operações após a verificação e recusa religações transparentes. Cada nova ligação tem de passar novamente pelas verificações.

Esta verificação abrange a ponte de controlo do Firecracker no Kubernetes e em anfitriões geridos diretamente. O tráfego ServicePort utiliza verificações de execução e de porta no seu gateway; não atesta a identidade de uma aplicação arbitrária dentro do convidado.

Expandir

Tempo de vida dos streams e recuperação de rotas

Algumas ligações permanecem abertas enquanto a execução de uma sandbox muda, pelo que as verificações de identidade têm de ir além do pedido inicial. O SPACE desativa as ligações associadas à execução antiga e permite que as operações elegíveis voltem a ligar-se à atual, sujeitas às mesmas verificações de segurança.

Os terminais e as observações de ficheiros podem sobreviver aos pedidos que os abriram. O SPACE associa os streams de backend a uma época de identidade, para que um stream não possa permanecer ligado à execução antecessora depois de o recetor instalar uma execução de substituição.

O SPACE volta a verificar a identidade persistente antes de abrir um stream. Substituir a rota ou a execução cancela a concessão do stream, interrompendo a entrada e a saída.

As alterações de propriedade são distintas da substituição da execução. Uma transferência de operação de ciclo de vida num residente Kubernetes inalterado preserva a identidade da sua rota, as capacidades não expiradas e os streams. O gateway também preserva os streams estabelecidos em alterações que afetam apenas a tentativa de ativação dentro da mesma rota e geração de execução. As novas aberturas exigem a identidade atualizada.

A recuperação mantém estas verificações intactas. O comparador de identidade pode devolver RefreshRoute em caso de incompatibilidade de encarnação na mesma sandbox, ou Deny no caso de uma sandbox diferente. Só um sinal de atualização reconhecido desencadeia a reparação da rota após uma rejeição de identidade. As falhas de transporte seguem regras de recuperação próprias, específicas de cada operação. Assinaturas, finalidades ou perfis de porta inválidos continuam a ser recusados.

Uma operação elegível pode resolver a execução atual e fazer uma tentativa reconstruída. A substituição da cache está condicionada à rota rejeitada, o que impede que uma rejeição atrasada remova uma entrada mais recente. A atualização da sessão nativa preserva a expiração original da cache, separando a reparação de rotas da renovação da autorização do chamador.

As regras de repetição continuam a ser específicas de cada operação. Um backend de substituição tem de passar novamente pela admissão, mesmo quando o WebSocket do lado do cliente permanece aberto.

Expandir

Compromissos e limites de confiança

A identidade da execução torna-se um estado crítico para a segurança. As atualizações do plano de controlo e os pacotes de chaves de verificação têm de chegar aos componentes que servem pedidos, e a desativação produz efeito quando cada recetor instala a atualização. Tempos de vida curtos das capacidades limitam a reutilização durante a propagação.

O design pressupõe que a aplicação da identidade está ativada e confia no signatário do plano de controlo, no kernel do worker e nos serviços de gestão locais do nó. O comprometimento do root do worker ou de um administrador de cluster privilegiado está fora do modelo de ameaças. A verificação da ponte é uma verificação local de processos e de transporte, e não uma atestação remota suportada por hardware.

A verificação de assinaturas, as comparações de runtime e a validação da ponte acrescentam trabalho ao caminho do pedido. Utilizam estado local em vez de uma consulta de autorização remota em cada salto privado.

Comparação com o setor

A comparação relevante é a forma como as plataformas lidam com um pedido autorizado que chega à execução errada da sandbox certa. Estas conclusões dizem respeito às implementações analisadas, e não à segurança global das plataformas. O SPACE, o OpenShell e o E2B foram analisados a 8 de outubro de 2026:

• OpenShell: Oferece seleção de execução para novas chamadas e vinculação entre supervisor e runtime comparáveis, através de verificações de geração e de autorização no gateway, validação da identidade do backend e confirmação de ligações ativas do supervisor (admissão no gateway, autenticação e vinculação do runtime). O SPACE transporta a seleção assinada ao longo do seu caminho de serviço e acrescenta verificação local de processos e de transporte no worker; o OpenShell distribui as verificações correspondentes pelo seu gateway, pela identidade de lançamento e pelo protocolo de runtime autenticado (design do runtime).
• E2B: Regista os IDs de execução e isola os pools de proxy por ciclo de vida do Firecracker, mas o seu proxy de entrada seleciona a sandbox lógica e a porta sem uma identidade de execução esperada para comparação pelo recetor (publicação de rotas, admissão no proxy). Uma execução mais antiga, ainda registada como ativa num recetor obsoleto com credenciais correspondentes, não pode ser distinguida da execução mais recente selecionada através dessas verificações, embora a desmontagem normal remova as rotas e feche as ligações associadas ao ciclo de vida (credenciais, desmontagem).
• CubeSandbox: Repara o encaminhamento ao retomar e invalida caches, mas o ingress privado utiliza credenciais com âmbito de sandbox e reencaminha sem uma encarnação de runtime esperada (encaminhamento ao retomar, encaminhamento de ingress). A reparação de rotas reduz as janelas de rotas obsoletas; a capacidade vinculada à execução do SPACE também dá ao recetor uma base independente para rejeitar a encarnação errada.

A identidade como limite de isolamento

Uma delegação segura depende de manter o trabalho de cada agente dentro dos limites que lhe foram destinados. Uma microVM proporciona isolamento, enquanto a plataforma envolvente tem de garantir que cada pedido e cada ligação em curso chegam à execução autorizada a processá-los.

O SPACE torna a identidade da execução parte dessa proteção. Ao verificar destinos, validar os endpoints da ponte e associar as ligações à execução que as autorizou, preserva esses limites à medida que as sandboxes são pausadas, retomadas e movidas.

Continuamos este trabalho à medida que a infraestrutura evolui. Para o SPACE e outras plataformas de sandbox, a segurança exige testar estes caminhos contra erros de encaminhamento rotineiros e cargas de trabalho hostis e, depois, reforçar os limites onde quer que esses testes revelem lacunas.