Como o SPACE roteia solicitações para a execução certa do sandbox

Quando alguém pede a um agente de IA que analise uma planilha ou teste um software, está confiando que ele trabalhará com segurança com seus arquivos e dados. Os agentes precisam de ambientes isolados onde possam realizar esse trabalho sem expor os dados de outros usuários nem interferir em suas cargas de trabalho.

À medida que os agentes assumem tarefas mais complexas com mais autonomia, esses ambientes ajudam a conter erros e a limitar os danos que códigos inseguros ou maliciosos podem causar. Os sandboxes oferecem esse isolamento enquanto compartilham serviços do plano de controle, nós de trabalho e infraestrutura de roteamento.

Essa infraestrutura compartilhada precisa entregar cada operação à execução autorizada a tratá-la. Uma rota obsoleta pode enviar uma solicitação válida para outro sandbox ou para uma execução mais antiga do sandbox certo. O SPACE, a plataforma de sandbox segura da Perplexity, vincula cada operação a uma execução selecionada e verifica o destino antes de encaminhá-la.

Há meses, o SPACE processa milhões de execuções por dia, cada uma protegida por uma identidade criptográfica exclusiva, com uma taxa de erro abaixo de 0,0002% e nenhuma conexão perdida.

O problema do roteamento

A segurança do sandbox também depende de fazer cada solicitação chegar ao destino certo. Até uma simples leitura de arquivo passa por uma infraestrutura compartilhada que precisa acompanhar onde o sandbox está sendo executado à medida que ele é pausado, retomado ou movido entre máquinas.

Uma leitura de arquivo passa por vários componentes. O plano de controle do SPACE resolve o sandbox para uma execução e um worker. A solicitação entra pelo node-api, passa para o gerenciador de sandbox, sbx-manager, e atravessa um socket Unix até a ponte do host, spaced-host. A ponte a encaminha por VSOCK, o transporte de sockets entre host e convidado, até o spaced-guest dentro da microVM do Firecracker.

Cada decisão depende de um estado que pode ficar defasado em relação às mudanças na infraestrutura. Um banco de dados pode manter um posicionamento antigo, um endereço em cache pode apontar para outro lugar ou um caminho de socket pode passar a ter outro listener. Uma conexão bem-sucedida ainda pode chegar ao destino errado. Uma leitura poderia expor os dados de outro usuário; uma gravação poderia modificar o sistema de arquivos errado.

Os snapshots trazem outro problema. Retomar um sandbox em outro worker preserva sua identidade lógica, mas inicia uma nova execução. Uma solicitação atrasada ou uma conexão remanescente pode chegar à execução anterior e retornar um estado antigo sob o nome do sandbox certo.

Expandir

Identidade do sandbox e identidade de execução

O SPACE separa o ambiente do usuário do runtime que o atende:

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

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

Suponha que o sandbox S seja executado como execução 7 no worker A e depois seja retomado como execução 8 no worker B. Uma solicitação selecionada para a execução 8 precisa falhar se chegar à execução 7. Verificar apenas o ID do sandbox não detectaria a divergência.

Expandir

Seleção de execução assinada

Cada solicitação carrega uma prova assinada de qual execução de sandbox pode tratá-la e de qual acesso é permitido. O componente receptor confere essa prova com sua própria identidade de runtime antes de deixar a solicitação prosseguir.

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

O gerenciador de sandbox receptor verifica a assinatura e compara a identidade completa com seu registro de runtime persistido localmente. A assinatura determina quem autorizou a seleção. A comparação determina se essa seleção corresponde ao receptor.

O tráfego de ServicePort passa por uma segunda verificação no gateway de rede de cada sandbox, o netgtw, antes que uma conexão com o convidado seja aberta. O gateway compara a identidade com o estado de ativação confiável e verifica a porta e o protocolo. As operações de controle seguem para a verificação dos endpoints da ponte.

O SPACE usa assinaturas Ed25519. As chaves de assinatura do plano de controle emitem capacidades; as chaves públicas de verificação nos workers e gateways não podem emiti-las.

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

Expandir

Rejeição no destino errado

O worker receptor consegue detectar um erro de roteamento mesmo quando a própria solicitação está autorizada. Ele verifica se a execução que está rodando é a selecionada para aquela solicitação e a rejeita caso sejam diferentes.

Se uma solicitação selecionada para a execução 8 chegar ao worker A, que ainda atende a execução 7, o worker A a rejeita antes de encaminhá-la. Depois que um receptor instala a identidade da execução 8, ele também rejeita capacidades da execução 7, mesmo antes de expirarem.

Essa garantia tem um limite importante. Uma capacidade para a execução 7 ainda pode corresponder a um worker que atende a execução 7 até que esse worker seja informado da desativação ou que a capacidade expire. 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 registro de runtime correspondente estabelece a execução pretendida. A ponte de controle também precisa alcançar os processos e o transporte pertencentes a essa ativação, e não um substituto que herdou o mesmo endereço.

Os gerenciadores de sandbox e de nó verificam as credenciais do par da ponte do host e as identidades dos processos da ponte e do Firecracker, incluindo os horários de início, detectando IDs reutilizados ou executáveis alterados

As verificações de transporte vinculam o listener VSOCK ao processo Firecracker esperado usando a propriedade do socket, a identidade do convidado e evidências de socket do kernel. A ponte só encaminha operações após a verificação e recusa reconexões transparentes. Cada nova conexão precisa passar pelas verificações novamente.

Essa verificação abrange a ponte de controle do Firecracker no Kubernetes e em hosts gerenciados diretamente. O tráfego de ServicePort usa verificações de execução e de porta em seu gateway; ele não atesta a identidade de um aplicativo arbitrário dentro do convidado.

Expandir

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

Algumas conexões permanecem abertas enquanto a execução de um sandbox muda, então as verificações de identidade precisam ir além da solicitação inicial. O SPACE desativa as conexões vinculadas à execução antiga e permite que operações elegíveis se reconectem à execução atual sob as mesmas verificações de segurança.

Terminais e monitoramentos de arquivos podem durar mais do que as solicitações que os abriram. O SPACE vincula os streams de backend a uma época de identidade para que um stream não continue conectado à execução anterior depois que o receptor instala uma execução substituta.

O SPACE verifica novamente a identidade durável antes de abrir um stream. A substituição da rota ou da execução cancela a concessão do stream, interrompendo a entrada e a saída.

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

A recuperação mantém essas verificações intactas. O comparador de identidade pode retornar RefreshRoute para uma incompatibilidade de encarnação dentro do mesmo sandbox ou Deny para um sandbox diferente. Somente um sinal de atualização reconhecido aciona o reparo de rota após a rejeição de identidade. Falhas de transporte seguem regras de recuperação separadas e específicas para cada operação. Assinaturas, finalidades ou perfis de porta inválidos continuam sendo negados.

Uma operação elegível pode resolver a execução atual e fazer uma única nova tentativa reconstruída. A substituição no cache depende da 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 do cache, separando o reparo da rota da renovação da autorização do chamador.

As regras de repetição continuam sendo específicas de cada operação. Um backend substituto precisa passar novamente pela admissão, mesmo quando o WebSocket voltado ao cliente permanece aberto.

Expandir

Trade-offs e limites de confiança

A identidade da execução se torna um estado crítico para a segurança. As atualizações do plano de controle e os pacotes de chaves de verificação precisam chegar aos componentes de atendimento, e a desativação entra em vigor quando cada receptor 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 de identidade esteja ativada e confia no assinador do plano de controle, no kernel do worker e nos serviços de gerenciamento 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 processo e transporte, não uma atestação remota baseada em hardware.

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

Comparação com o setor

A comparação relevante é como as plataformas lidam com uma solicitação autorizada que chega à execução errada do sandbox certo. Essas conclusões dizem respeito às implementações analisadas, não à segurança geral das plataformas. SPACE, OpenShell e E2B foram verificados em 8 de outubro de 2026:

• OpenShell: oferece seleção de execução para novas chamadas e vinculação entre supervisor e runtime comparáveis, por meio de verificações de geração e autorização no gateway, validação da identidade do backend e conexões confirmadas de supervisores ativos (admissão no gateway, autenticação e vinculação do runtime). O SPACE leva a seleção assinada por todo o seu caminho de atendimento e acrescenta verificação local de processo e transporte no worker; o OpenShell distribui verificações correspondentes entre seu gateway, a identidade de inicialização e o protocolo de runtime autenticado (design do runtime).
• E2B: rastreia IDs de execução e isola pools de proxy por ciclo de vida do Firecracker, mas seu proxy de entrada seleciona o sandbox lógico e a porta sem uma identidade de execução esperada para comparação pelo receptor (publicação de rotas, admissão no proxy). Uma execução mais antiga ainda registrada como ativa em um receptor obsoleto com credenciais correspondentes não pode ser diferenciada, por essas verificações, da execução mais recente selecionada, embora o encerramento normal remova as rotas e feche as conexões vinculadas ao ciclo de vida (credenciais, encerramento).
• CubeSandbox: corrige o roteamento ao retomar e invalida caches, mas o ingress privado usa credenciais com escopo de sandbox e encaminha sem uma encarnação de runtime esperada (roteamento na retomada, roteamento de ingress). O reparo de rotas reduz as janelas de rotas obsoletas; a capacidade vinculada à execução do SPACE também dá ao receptor uma base independente para rejeitar a encarnação errada.

Identidade como limite de isolamento

Delegar com segurança depende de manter o trabalho de cada agente dentro dos limites previstos para ele. Uma microVM oferece isolamento, enquanto a plataforma ao redor precisa garantir que cada solicitação e cada conexão em andamento cheguem à execução autorizada a tratá-las.

O SPACE torna a identidade da execução parte dessa proteção. Ao verificar destinos, validar os endpoints da ponte e vincular as conexões à execução que as autorizou, ele preserva esses limites à medida que os sandboxes são pausados, retomados e movidos.

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