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

À medida que os fluxos de trabalho com agentes crescem e se tornam mais autônomos, os ambientes em que os agentes de IA operam importam tanto quanto os modelos que os impulsionam. Os agentes precisam realizar trabalho real, como executar código, editar sistemas de arquivos e realizar tarefas em várias etapas ao longo de horas ou dias. Os usuários querem 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 que os agentes sejam comprometidos. Um 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 normalmente assumem trabalhos de curta duração e sem estado, e têm o kernel como um ponto único de falha. Em contraste, 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 simplesmente ser descartados e reconstruídos do zero. Além disso, a carga de trabalho interna deve não ser confiável por padrão, exigindo medidas de segurança mais fortes. As sessões de agentes de longa duração precisam de um substrato que possa isolar um convidado hostil, preservar seu estado e ainda operar em escala.

O principal desafio na engenharia de sandbox vem da tensão que frequentemente surge entre segurança, funcionalidade e eficiência. Por exemplo:

• Conceder acesso mais amplo permite que um agente realize mais, mas expõe mais do sistema a uma carga de trabalho em que você não confia.
• Partilhar mais recursos entre sandboxes torna a criação mais rápida, mas amplia a superfície de ataque.
• Criar instantâneos com maior frequência melhora a recuperação e permite funcionalidades como a reversão, mas exige tempo e espaço de armazenamento.

Os sandboxes para agentes, como os necessários para executar código, usar Agent Skills ou realizar pipelines de Search as Code em consultas do Computer, precisam dos três. Trabalhamos arduamente nos últimos meses na engenharia da próxima geração de infraestrutura de agentes que impulsiona nossos produtos. Hoje estamos apresentando o SPACE (Sandboxed Platform for Agentic Code Execution): uma plataforma de sandbox criada para fluxos de trabalho com agentes que é segura, confiável e eficiente em escala. No mês passado, começamos a implantar o SPACE como a camada de sandbox que alimenta o Perplexity Computer. Na última semana, ele suportou com segurança milhões de criações de sandboxes e dezenas de milhões de reconexões, com tempos de inicialização de 3 a 5 vezes mais rápidos do que nossa solução anterior.

Este artigo apresenta as decisões arquitetônicas e de design por trás do SPACE. A partir de hoje, 100% das sessões do Computer agora executam no SPACE. Estamos empolgados em implantar esta plataforma em ainda mais superfícies para fornecer um ambiente de execução de excelência para agentes para nossos usuários e desenvolvedores.

Arquitetura

Em um nível alto, 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 módulos de gerenciamento de estado em nível de cluster.

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

O sandbox é o próprio ambiente de execução isolado. Ele é implementado como uma máquina virtual combinada com o space-daemon: um processo em segundo plano dentro do convidado que intermedeia o acesso da carga de trabalho ao sistema de ficheiros, aos processos e à rede.

Expandir

Plano de Controle

O gateway de API é o ponto de entrada. As solicitações recebidas são autenticadas e autorizadas, sendo então traduzidas em registros de 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ó eles estão atribuídos, onde estão sendo executados e se foram salvos em backup para armazenamento durável. Ele compara continuamente o estado desejado com o estado observado e conduz os dois 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 do Nó

Os serviços locais do nó realizam o trabalho real de preparar modelos, iniciar sandboxes, conectar redes e executar serviços de tempo de execução do lado do host. Cada nó executa um pequeno conjunto de daemons que gerenciam cada sandbox colocado nele, e o nó é a fonte da verdade para os estados ativos desses sandboxes.

O gerenciador de sandbox sabe quais sandboxes estão em execução, pausados, suspensos ou parados, junto com seus recursos reais. Ele é executado sem privilégios e delega todo o trabalho privilegiado para o gerenciador de nós, o único processo raiz que faz a mediação das primitivas subjacentes. O armazenamento é tratado localmente e de forma durável: snapshots dos estados atuais do 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 permitir operações entre nós. Os mecanismos de segurança protegem o que um 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 impõe a política de saída de cada sandbox.

Sandbox

O próprio sandbox é uma máquina virtual (VM) com seu próprio kernel de convidado, executando a carga de trabalho do usuário por trá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 que ela explore com sucesso seu kernel de convidado, esse comprometimento fica confinado ao limite da VM do sandbox em vez de se propagar por outras cargas de trabalho.

Um daemon space é executado dentro de cada máquina virtual, servindo como um agente leve que regula cada ação ou modificação que a plataforma executa 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 um sandbox ficou ocioso e pode ser pausado ou desalocado. Crucialmente, o daemon space não fala diretamente com os clientes, mas sim se comunica com o host por um canal privado dentro da VM. Isso mantém toda a interação do convidado em um caminho controlado e reserva a rede própria do sandbox puramente para o tráfego de saída da carga de trabalho.

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

Em seguida, mergulhamos nas propriedades principais que o SPACE deve entregar em três pilares: segurança, funcionalidade e eficiência. Como observado anteriormente, estes três estão em tensão entre si. No entanto, não podemos comprometer nenhum deles se quisermos apoiar agentes poderosos que correspondam às capacidades dos modelos de hoje. A segurança impede que uma carga de trabalho não confiável e possivelmente hostil prejudique o host, outros locatários ou os segredos de um usuário. A funcionalidade oferece aos agentes o ciclo de vida rico 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

As plataformas de sandbox precisam de forte segurança para garantir que códigos errôneos ou mesmo maliciosos executados dentro de sandboxes não possam causar efeitos nocivos em outros lugares. Sem impor um controle de saída rigoroso e manter os segredos fora do sandbox, um único passo em falso de um agente pode vazar as chaves de um usuário ou exfiltrar trabalho.

Expandir

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

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

Os dados são protegidos em repouso. O SPACE oferece suporte a BYOK (Bring Your Own Key) para proteger dados armazenados externamente. As chaves de criptografia vêm do serviço de gerenciamento de chaves do cliente e nunca entram no sandbox. Se a empresa revogar a chave, seus dados se tornarão ilegíveis.

Funcionalidade: Potencializando Fluxos de Trabalho com Agentes

Para dar suporte a fluxos de trabalho com agentes, os sandboxes precisam de um suporte robusto ao ciclo de vida. Eles devem ser criados rapidamente e em escala, já que um agente pode iniciar vários de uma vez e não deve esperar que nenhum deles inicialize. Eles devem persistir por um período indefinido, já que uma sessão pode durar minutos ou rodar por meses. Eles devem pausar de forma limpa, às vezes por longos períodos, como quando uma tarefa está bloqueada por entrada humana. E eles devem dar suporte a ramificação, reversão e recuperação de falhas, para que uma sessão possa se ramificar, desfazer um passo em falso ou retomar após uma falha em vez de começar de novo.

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

Expandir

Os snapshots são o mecanismo por trás da maioria dessas capacidades. Um agendador é acionado em intervalos regulares e captura dois tipos de snapshots: snapshots de disco (cópias pontuais do sistema de arquivos) e snapshots completos (pontos de verificação de toda a VM pausada). Os snapshots de disco são capturados com frequência, enquanto os pontos de verificação completos são menos frequentes. Tudo permanece no nó, e a retenção decai por camada. 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 pontos de verificação completos permitem que um sandbox que falhou seja retomado em um ponto de execução recente em vez de em um disco frio.

Quando um sandbox é suspenso, a VM é pausada, um snapshot completo é tirado e os artefatos do snapshot completo são carregados para o armazenamento de objetos. Uma linha de banco de dados rastreia o snapshot e só se torna restaurável assim que cada artefato for enviado, de modo que um snapshot parcialmente carregado nunca possa ser retomado em um estado corrompido. A restauração é o inverso da suspensão. Como o snapshot vive no armazenamento de objetos em vez de no nó original, qualquer nó pode trazer o 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 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. A memória e o 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 do ciclo de vida devem ser baratas em tempo e espaço. Não podemos nos dar ao luxo de copiar uma imagem de máquina inteira toda vez que um sandbox é criado, pausado ou ramificado.

Uma escolha de design fundamental torna isso possível: o sistema de arquivos. O SPACE usa btrfs como o sistema de arquivos no nó para armazenamento em sandbox. O 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 tem alguns benefícios:

As cópias Reflink são rápidas, pois você compartilha os extentes subjacentes, portanto, apenas os metadados precisam ser copiados.

Os snapshots são atômicos e rápidos, pois você apenas cria uma nova raiz.

É necessário o mínimo de armazenamento, pois você armazena apenas o que foi alterado.

Como resultado, os sandboxes podem ser criados e restaurados rapidamente. Em vez de criar um sandbox do zero a cada vez, mantemos um pool quente de pods que já têm modelos comuns materializados no disco e atendemos a uma solicitação vinculando-a a um pod cujo modelo já corresponda. Dar a esse 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 se encaixa, materializamos o modelo sob demanda; combinamos solicitações simultâneas para a mesma imagem em um único download, de modo que uma rajada de solicitações idênticas não se transforme em uma rajada de trabalho idêntico.

O resultado é um tempo de execução de sandbox que é ao mesmo tempo poderoso, leve e extremamente rápido. Quando lançamos o SPACE, o executamos 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 em toda a 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 percentil 90 caiu de 447 milissegundos para 89 milissegundos (melhoria de 5,0x). Observamos melhorias semelhantes de ordem de magnitude em outros indicadores de desempenho e uso de recursos.

Expandir

Isso também facilita a realização de snapshots de disco contínuos, pois eles são rápidos, eficientes em termos de espaço e não exigem a pausa do sandbox. Além disso, o armazenamento delta eficiente reduz 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, nos propusemos a alcançar uma melhoria de Pareto em todos os três pilares.

Cada escolha de design individual pode atender a vários objetivos ao mesmo tempo, tornando esse equilíbrio delicado possível. VMs por sandbox dão a cada carga de trabalho seu próprio kernel, fortalecendo a segurança por meio de um forte isolamento e também fornecendo o limite de ponto de verificação limpo em que os snapshots se baseiam. O Btrfs permite a implementação eficiente de snapshots, ramificações e outras operações essenciais para tempos de execução de agentes. O daemon space mantém toda a interação do convidado em um caminho controlado do lado do host, selando o limite entre convidado e host, preservando a liberdade de manobra dos agentes. O gateway de rede central medeia 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 com estado e de longa duração podem lidar com segurança com trabalhos 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 provisionamento e controle de sandboxes em qualquer ambiente: desde microVMs Linux até convidados Windows e a própria máquina local de um usuário. Estamos trabalhando arduamente para introduzir o SPACE nesses novos ambientes, para que os desenvolvedores possam lançar 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ã, convidamos você a fazer parte da nossa equipe.

Citação

@online{perplexity2026MakingSpaceSecureAndEfficientRuntimesForLongRunningAgents,
  author = {{Perplexity} and Kumar Pallav and Nick Dujay and Zibi Braniecki and Dmitry Pervukhin and Gigi Sayfan and Mostafa Abdelraouf and Nikhil Birmiwal and Rohin Bhasin and Shrikant Pandhare and Nikitha Lokareddy and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma},
  title = {{Making SPACE: Secure and efficient runtimes for long-running agents}},
  date = {2026-07-15},
  url = {https://www.perplexity.ai/hub/blog/making-space-secure-and-efficient-runtimes-for-long-running-agents}
}