Criando o SPACE: Runtimes seguros e eficientes para agentes de longa duração

À medida que os fluxos de trabalho agente crescem em duração e autonomia, os ambientes nos quais os agentes de IA operam tornam-se tão importantes quanto os modelos que os impulsionam. Os agentes precisam realizar trabalho real, como executar códigos, editar sistemas de arquivos e realizar tarefas de várias etapas ao longo de horas ou dias. Os usuários desejam que os agentes tenham acesso às ferramentas e arquivos de que precisam para realizar essas tarefas, mas também precisam confiar que seus sistemas permanecerão seguros mesmo se os agentes forem comprometidos. Uma sandbox é o que torna tudo isso possível: um ambiente isolado onde um agente pode operar livremente enquanto o host, outros locatários e credenciais confidenciais permanecem protegidos.

As abordagens tradicionais de sandbox baseadas em contêineres não foram projetadas para essas tarefas. Elas geralmente pressupõem trabalhos de curta duração e sem estado, e possuem o kernel como um ponto único de falha. Em contrapartida, as sessões de agentes são de longa duração e com estado: um agente acumula horas de contexto, um sistema de arquivos de trabalho e processos em execução que não podem ser simplesmente descartados e reconstruídos do zero. Além disso, a carga de trabalho interna deve ser considerada não confiável por padrão, necessitando de medidas de segurança mais fortes. Sessões de agentes de longa duração precisam de um substrato capaz de isolar um convidado hostil, preservar seu estado e ainda ser operado em escala.

O principal desafio na engenharia de sandbox provém da tensão que muitas vezes surge entre segurança, funcionalidade e eficiência. Por exemplo:

Conceder acesso mais amplo permite que um agente realize mais, mas expõe mais o sistema a uma carga de trabalho em que você não confia.

Compartilhar mais entre sandboxes torna a criação mais rápida, mas amplia a superfície de ataque.

Tirar snapshots com mais frequência melhora a recuperação e habilita recursos como rollback, mas requer tempo e espaço de armazenamento.

As sandboxes agente, como aquelas necessárias para executar código, usar Habilidades de Agente, ou realizar pipelines de Pesquisa como Código em consultas de Computer, precisam de todas as três. Temos trabalhado arduamente nos últimos meses na engenharia da próxima geração de infraestrutura de agente que alimenta nossos produtos. Hoje estamos apresentando o SPACE (Plataforma em Sandbox para Execução de Código Agente): uma plataforma de sandbox criada para fluxos de trabalho agente que é segura, confiável e eficiente em escala. No mês passado, começamos a implementar o SPACE como a camada de sandbox que alimenta o Perplexity Computer. Na última semana, ele ofereceu suporte seguro a milhões de criações de sandbox e dezenas de milhões de reconexões, com tempos de inicialização 3-5 vezes mais rápidos que nossa solução anterior.

Este artigo apresenta as decisões arquiteturais e de design por trás do SPACE. A partir de hoje, 100% das sessões de Computer rodam agora no SPACE. Estamos empolgados em implantar esta plataforma em ainda mais superfícies para entregar um runtime agente de primeira classe para nossos usuários e desenvolvedores.

Arquitetura

Em alto nível, o sistema é organizado em três camadas.

O plano de controle é o cérebro do sistema, decidindo o que deve existir e onde. Ele consiste no gateway de API e nos módulos de gerenciamento de estado em nível de cluster.

Serviços locais ao nó são o maquinário local necessário para executar o plano do plano de controle. Eles detêm o ciclo de vida da sandbox, armazenamento, rede e as operações privilegiadas por trás deles.

A sandbox é o próprio ambiente de execução isolado. Ela é implementada como uma máquina virtual pareada com o daemon space: um processo de segundo plano no convidado que intermedeia o acesso ao sistema de arquivos, ao processo e à rede para a carga de trabalho.

Plano de Controle

O gateway de API é o ponto de entrada. Solicitações recebidas são autenticadas e autorizadas e, então, traduzidas em registros do estado desejado.

O plano de controle é sem estado por design, com todas as informações duráveis descarregadas para um banco de dados compartilhado. Ele rastreia informações em nível de cluster sobre sandboxes, como a qual nó elas estão atribuídas, onde estão rodando e se foram copiadas para armazenamento durável. Ele compara continuamente o estado desejado com o estado observado e conduz ambos em direção à convergência. As operações são idempotentes, portanto, o plano de controle pode se recuperar automaticamente após qualquer falha, reinicialização ou falha parcial.

Serviços Locais ao Nó

Serviços locais ao nó fazem o trabalho real de preparar modelos, iniciar sandboxes, configurar redes e executar serviços de runtime do lado do host. Cada nó executa um pequeno conjunto de daemons que gerenciam cada sandbox colocada nele, e o nó é a fonte da verdade para os estados vivos dessas sandboxes.

O gerenciador de sandbox sabe quais sandboxes estão rodando, pausadas, suspensas ou paradas, juntamente com seus recursos reais. Ele roda sem privilégios e delega todo o trabalho privilegiado ao gerenciador de nó, o processo raiz único que intermedeia as primitivas subjacentes. O armazenamento é tratado local e duravelmente: snapshots dos estados atuais da sandbox são salvos no nó, e um gerenciador de volume move snapshots e modelos de e para o armazenamento de objetos conforme necessário para habilitar operações entre nós. Portões de segurança protegem o que uma sandbox pode alcançar: o gerenciador de credenciais governa a injeção de credenciais sob autorização por serviço, e o gateway de rede aplica a política de saída de cada sandbox.

Sandbox

A própria sandbox é uma máquina virtual (VM) com seu próprio kernel de convidado, executando a carga de trabalho do usuário atrás de um limite de isolamento de hardware. Como cada sandbox tem seu próprio kernel, uma carga de trabalho comprometida não pode recorrer a um kernel de host compartilhado como um ponto único de falha; mesmo se ela explorar com sucesso seu kernel de convidado, esse comprometimento fica confinado ao limite da VM da sandbox, em vez de se propagar por outras cargas de trabalho.

Um daemon space roda dentro de cada máquina virtual, servindo como um agente leve que regula cada ação ou modificação que a plataforma realiza dentro do convidado. Ele lida com o acesso ao sistema de arquivos e o gerenciamento de processos. Ele também relata a prontidão do convidado e rastreia a atividade, para que a plataforma saiba quando uma sandbox ficou ociosa e pode ser pausada ou recuperada. Crucialmente, o daemon space não fala com clientes diretamente, mas se comunica com o host através de um canal privado dentro da VM. Isso mantém toda a interação do convidado em um caminho controlado e reserva a rede da própria sandbox puramente para o tráfego de saída da carga de trabalho.

Três Pilares: Segurança, Funcionalidade e Eficiência

A seguir, mergulhamos nas propriedades principais que o SPACE deve entregar através de três pilares: segurança, funcionalidade e eficiência. Como observado anteriormente, estes três se contrapõem. No entanto, não podemos comprometer nenhum deles se quisermos dar suporte a agentes poderosos que alcancem as capacidades dos modelos atuais. A segurança impede que uma carga de trabalho não confiável, possivelmente hostil, prejudique o host, outros locatários ou segredos de um usuário. A funcionalidade oferece aos agentes o rico ciclo de vida de que precisam. A eficiência torna tudo isso acessível sob memória, disco e computação finitos.

Segurança: Protegendo Dados e Sistemas

Plataformas de sandbox precisam de segurança forte para garantir que códigos errôneos ou até maliciosos executados dentro de sandboxes não possam causar efeitos prejudiciais em outros lugares. Sem aplicar um controle de saída rígido e manter segredos fora da sandbox, um único passo em falso de um agente pode vazar as chaves de um usuário ou exfiltrar trabalho.

O SPACE adota uma abordagem em camadas para garantir a segurança das sandboxes. O isolamento de sandbox tem dois componentes, isolamento de VM e isolamento de processo de SO do host. Ambos devem ser violados para acesso entre sandboxes. A comunicação com a sandbox é estritamente controlada; processos só podem se comunicar através de canais dedicados. O gateway de rede força toda a saída através dele. O daemon space é o único canal sancionado entre a sandbox (não confiável) e a plataforma (confiável).

As credenciais nunca residem onde um agente pode roubá-las. O armazenamento de credenciais fica fora do limite da sandbox e é responsável pelo ciclo de vida das credenciais. Ele armazena e recupera segredos via um backend de cofre conectável, resolve credenciais usando escopo hierárquico, gerencia metadados como método de injeção e expiração, e aplica limites de taxa e auditoria de log em todo acesso. Quando necessário, as credenciais são injetadas na camada de rede ou preenchidas automaticamente por um agente de navegador, em vez de entrar diretamente na sandbox.

Os dados são protegidos em repouso. O SPACE oferece suporte ao BYOK (Traga Sua Própria Chave) para proteger dados armazenados externamente. As chaves de criptografia vêm do serviço de gerenciamento de chaves do cliente e nunca entram na sandbox. Se a empresa revogar a chave, seus dados se tornam ilegíveis.

Funcionalidade: Impulsionando Fluxos de Trabalho Agente

Para dar suporte a fluxos de trabalho agente, sandboxes precisam de suporte rico ao ciclo de vida. Elas precisam ser criadas rapidamente e em escala, já que um agente pode iniciar muitas de uma vez e não deve esperar que nenhuma delas inicialize. Elas precisam persistir por uma duração indefinida, já que uma sessão pode durar minutos ou rodar por meses. Elas precisam pausar de forma limpa, às vezes por longos períodos, como quando uma tarefa está bloqueada por entrada humana. E elas precisam dar suporte a fork, rollback e recuperação de falhas, para que uma sessão possa ramificar, desfazer um passo ruim ou retomar após uma falha em vez de começar de novo.

O SPACE dá suporte a tudo o que foi mencionado acima. Ele modela o ciclo de vida completo da sandbox como uma máquina de estados explícita, que é o que torna possíveis operações como criar, pausar, retomar, suspender e restaurar.

Snapshots são o mecanismo por baixo da maioria dessas capacidades. Um agendador marca em intervalos regulares e captura dois tipos de snapshots: snapshots de disco (cópias ponto no tempo do sistema de arquivos) e snapshots completos (checkpoints de toda a VM pausada). Snapshots de disco são capturados frequentemente, enquanto checkpoints completos são menos frequentes. Tudo permanece no nó, e a retenção decai por nível. Esses snapshots podem ser usados para recuperação dentro da sessão; por exemplo, snapshots de disco podem ser usados para reverter o sistema de arquivos para desfazer um comando destrutivo, e checkpoints completos permitem que uma sandbox que travou retome em um ponto de execução recente em vez de um disco frio.

Quando uma sandbox é suspensa, a VM é pausada, um snapshot completo é tirado e os artefatos do snapshot completo são carregados para o armazenamento de objetos. Uma linha no banco de dados rastreia o snapshot e só se torna restaurável assim que cada artefato for colocado, para que um snapshot parcialmente carregado nunca possa ser retomado em um estado corrompido. Restaurar é o inverso de suspender. Como o snapshot vive no armazenamento de objetos em vez de no nó original, qualquer nó pode trazer a sandbox de volta. O agendador escolhe um nó, esse nó baixa os artefatos, reaplica o delta do sistema de arquivos sobre o modelo e retoma a VM a partir de seu estado capturado.

Eficiência: Otimizando Tempo e Espaço

Não basta implementar os recursos acima no vácuo; eles também precisam ser possíveis sob restrições rígidas de recursos. Memória e disco em um nó são finitos, e os usuários querem que os agentes operem o mais rápido possível, portanto, as operações de ciclo de vida devem ser baratas em tempo e espaço. Não podemos nos dar ao luxo de copiar uma imagem completa de máquina toda vez que uma sandbox é criada, pausada ou ramificada.

Uma escolha de design chave torna isso possível: o sistema de arquivos. O SPACE usa btrfs como o sistema de arquivos no nó para armazenamento de sandbox. Btrfs (sistema de arquivos B-tree) combina um sistema de arquivos de cópia em gravação com gerenciamento integrado de volume lógico. Isso traz alguns benefícios:

Cópias Reflink são rápidas, já que você compartilha as extensões subjacentes, então apenas os metadados precisam ser copiados.

Snapshots são atômicos e rápidos, já que você apenas cria uma nova raiz.

Armazenamento mínimo é necessário, já que você só armazena o que mudou.

Como resultado, sandboxes podem ser criadas e restauradas rapidamente. Em vez de criar uma sandbox do zero a cada vez, mantemos um pool quente de pods que já possuem modelos comuns materializados em disco, e atendemos a uma solicitação vinculando-a a um pod cujo modelo já corresponde. Dar a essa sandbox seu próprio sistema de arquivos raiz gravável é, então, um clone de cópia em gravação em vez de uma cópia completa. Quando nenhum pod quente serve, materializamos o modelo sob demanda; colapsamos solicitações simultâneas para a mesma imagem em um único download, para que uma explosão de solicitações idênticas não se transforme em uma explosão de trabalho idêntico.

O resultado é um runtime de sandbox que é, ao mesmo tempo, poderoso, leve e extremamente rápido. Quando implementamos o SPACE, rodamos junto com nosso provedor de sandbox anterior no mesmo tráfego de produção. Ao longo da semana de lançamento, o SPACE criou sandboxes de três a cinco vezes mais rápido ao longo da distribuição. Especificamente, a latência mediana de criação caiu de 185 milissegundos para 60 milissegundos (melhoria de 3,1x), e a latência no 90º percentil caiu de 447 milissegundos para 89 milissegundos (melhoria de 5,0x). Observamos melhorias de ordem de magnitude semelhantes em outros indicadores de desempenho e uso de recursos.

Também torna fácil tirar snapshots de disco rotativos, já que são rápidos, eficientes em termos de espaço e não requerem pausar a sandbox. E, o armazenamento delta eficiente diminui o espaço necessário para armazenar esses snapshots.

Conclusão

Ao projetar sistemas complexos, é tentador escolher um único objetivo para otimizar isoladamente. Mas os desenvolvedores de agentes de fronteira exigem segurança, funcionalidade e eficiência em igual medida. Com o SPACE, partimos para alcançar uma melhoria de Pareto em todos os três pilares.

Cada escolha de design individual pode servir a múltiplos objetivos ao mesmo tempo, tornando possível esse delicado equilíbrio. VMs por sandbox dão a cada carga de trabalho seu próprio kernel, fortalecendo a segurança através de um isolamento forte, enquanto também fornecem o limite limpo de checkpoint do qual os snapshots dependem. O Btrfs habilita a implementação eficiente de snapshots, fork e outras operações essenciais para runtimes agente. O daemon space mantém toda a interação do convidado em um caminho controlado do lado do host, selando o limite convidado-host enquanto preserva a liberdade de manobra dos agentes. O gateway de rede central intermedeia a saída e a injeção de credenciais sem nunca expor segredos ao convidado.

O resultado dessas e outras decisões de design é uma plataforma que permite a orquestração de agentes no mundo real em escala. O SPACE fornece o substrato no qual agentes de longa duração e com estado podem lidar com segurança com trabalho de complexidade ou duração arbitrária, sem sacrificar o desempenho ou a segurança.

Hoje, o SPACE já alimenta milhões de sessões do Perplexity Computer. Pretendemos que o SPACE sirva como uma camada unificada para provisionar e controlar sandboxes em qualquer cenário: desde microVMs Linux até convidados Windows e a própria máquina local de um usuário. Estamos trabalhando arduamente para levar o SPACE para esses novos cenários, para que os desenvolvedores possam enviar produtos de IA que funcionem onde quer que os usuários trabalhem.

Se você está ansioso para moldar a camada de computação que impulsiona os agentes de fronteira de amanhã, nós o convidamos a fazer parte da nossa equipe.