A Perplexity abriu o código do SPACE, plataforma de sandboxing usada por trás do recurso Computer para executar código de agentes em microVMs isoladas. O projeto, publicado sob licença Apache-2.0, organiza o ciclo de vida de ambientes baseados em Firecracker e Kubernetes: cria sandboxes, executa processos, preserva estado, suspende máquinas e as remove por API. A mudança interessa menos como “mais uma ferramenta de agentes” e mais como infraestrutura para limitar o que um agente pode fazer quando recebe permissão para navegar, programar ou manipular arquivos.
O código está disponível no repositório SPACE da Perplexity; a documentação técnica descreve uma arquitetura em que cada sandbox é uma microVM com sistema de arquivos gravável próprio. A empresa afirma que a plataforma está por trás do Perplexity Computer e que a Akamai já a testou e lançou em sua nuvem.
Resumo: o que foi aberto e por que isso importa
- SPACE é uma plataforma de execução isolada para código de agentes e usuários, não um modelo de linguagem.
- Ela usa Firecracker, tecnologia de microVMs baseada em KVM, para criar uma fronteira de isolamento mais forte do que a de um processo comum.
- A arquitetura separa o objeto sandbox, os processos executados nele, as sessões de comando e as operações assíncronas de ciclo de vida.
- O projeto é open source sob licença Apache-2.0, o que permite auditoria, adaptação e uso comercial sujeito aos termos da licença.
- A instalação local documentada exige Linux x86_64 com KVM, Docker, Kubernetes via Kind e privilégios elevados; não é uma ferramenta pronta para rodar diretamente no macOS.
O problema que o SPACE tenta resolver
Agentes de IA deixaram de apenas responder texto. Em produtos de desenvolvimento, pesquisa e automação, eles podem abrir páginas, baixar arquivos, escrever código, executar comandos e usar credenciais de serviços. Isso cria uma questão operacional: como permitir uma tarefa útil sem transformar o computador ou o ambiente de produção em extensão irrestrita do agente?
Um sandbox não torna um agente confiável. Ele reduz o raio de impacto quando o agente erra, interpreta mal uma instrução, encontra conteúdo malicioso na web ou executa uma dependência insegura. O objetivo é limitar processos e arquivos a um ambiente descartável, observável e sujeito a políticas explícitas. Essa separação é especialmente importante para agentes que executam código gerado pelo próprio modelo ou por terceiros.
O SPACE adota microVMs em vez de depender somente de contêineres convencionais. Firecracker foi criado para executar cargas isoladas com virtualização de hardware via KVM e uma superfície de dispositivos reduzida. Na prática, isso adiciona uma fronteira de virtualização entre a carga não confiável e o host. Ainda assim, essa proteção depende da configuração do host, das regras de rede, das imagens usadas e da política de credenciais; microVM não é sinônimo de segurança automática.
Como a arquitetura organiza uma execução de agente
A documentação do SPACE descreve um fluxo de estado que vai do PostgreSQL para um controlador de cluster, um pod de sandbox no Kubernetes, um runtime shim do SPACE, serviços de worker, a microVM Firecracker e, por fim, o processo convidado. Essa cadeia mostra que o projeto não é apenas um wrapper para iniciar uma VM: ele tenta administrar os componentes que tornam execuções efêmeras reproduzíveis em escala.
Sandbox, processo, sessão e operação não são a mesma coisa
No modelo do projeto, um sandbox é a microVM isolada, com configuração e sistema de arquivos próprios. Um processo é o programa que roda dentro dela. Uma sessão de comando representa a conexão e a autorização para iniciar ou acompanhar uma execução. Já uma operação registra ações assíncronas como criar, pausar, suspender, acordar ou apagar o sandbox.
Essa distinção resolve um problema comum de agentes: a chamada que cria ou controla um ambiente pode terminar antes da tarefa. O sandbox pode sobreviver à conexão inicial; o processo pode produzir saída por mais tempo; e o estado pode ser preservado para retomada posterior. A documentação também prevê exportação e importação de sandboxes e snapshots, indicando que portabilidade de estado faz parte do desenho, e não apenas a execução descartável.
O que a instalação revela sobre o público inicial
O guia oficial pede host Linux x86_64 com /dev/kvm, /dev/net/tun, loop devices, suporte a btrfs e Docker com permissão para contêineres privilegiados. A implantação local passa por um cluster Kind e usa uma imagem/template inicial chamada seed:latest. Esses requisitos deixam claro que o SPACE está voltado a equipes de plataforma, segurança e infraestrutura, não ao usuário que procura um botão simples para “rodar agentes com segurança”.
| Camada | Função no SPACE | Implicação de segurança |
|---|---|---|
| API e controlador | Registra e coordena o ciclo de vida | Políticas precisam impedir criação ou retenção indevida de ambientes |
| Kubernetes e workers | Agenda e opera a carga | Credenciais do cluster continuam sendo parte crítica da defesa |
| Firecracker microVM | Isola a carga com virtualização baseada em KVM | Reduz o acoplamento com o host, mas exige host bem configurado |
| Processo convidado | Executa código e ferramentas do agente | Deve receber somente arquivos, rede e segredos estritamente necessários |
O que muda para equipes que constroem agentes
O principal ganho do código aberto é tornar auditável uma peça que costuma ficar escondida em serviços proprietários: a camada que decide onde um agente executa código e como esse ambiente é descartado ou recuperado. Empresas podem estudar o desenho, adaptar integrações e avaliar se a implementação é compatível com suas políticas de rede, retenção de dados e auditoria.
Para times brasileiros, a relevância prática aparece em três cenários. O primeiro é o desenvolvimento de copilotos que precisam testar código ou manipular repositórios sem usar a máquina do desenvolvedor como ambiente de execução. O segundo é a automação de back office, em que agentes processam documentos, planilhas ou portais internos. O terceiro é pesquisa com navegação e ferramentas: cada tarefa pode nascer em um ambiente com escopo limitado, em vez de compartilhar sessão e arquivos com outras tarefas.
O projeto também ilustra uma mudança de foco no mercado de agentes. O debate deixa de ser apenas qual modelo alcança melhor pontuação e passa a incluir governança operacional: como isolar ferramentas, registrar ações, controlar egressos de rede, suspender tarefas e revogar acesso. Modelos mais capazes ampliam o valor de executar tarefas, mas também elevam o custo de uma execução mal direcionada.
Limitações e perguntas que o anúncio não resolve
- Não há garantia universal contra fuga ou abuso. O próprio Firecracker depende de configuração segura do host e de atualizações constantes do sistema.
- Isolamento não substitui autorização. Se um sandbox recebe uma chave de produção ampla, ele pode usar essa chave mesmo estando em uma VM isolada.
- O custo operacional é real. Kubernetes, virtualização, imagens e observabilidade exigem equipe e processos maduros.
- Compatibilidade importa. O guia atual é dirigido a hosts Linux x86_64 com recursos específicos; isso limita experimentação local em outros ambientes.
- Open source não equivale a prontidão automática. Cada organização precisa validar ameaças, retenção, telemetria e políticas antes de levar o sistema à produção.
Análise do NoticIA: o open source desloca a discussão para a camada certa
Na análise do NoticIA, a abertura do SPACE é relevante porque a segurança de agentes tende a falhar em interfaces: entre o modelo e a ferramenta, entre o processo e a credencial, entre a tarefa temporária e o estado persistente. Publicar o runtime não resolve essas interfaces, mas permite que engenheiros inspecionem e debatam a camada de execução em vez de aceitá-la como caixa-preta.
Também há um contraponto importante: microVMs podem reduzir riscos técnicos, porém não resolvem decisões ruins de produto. Um agente com instruções ambíguas, permissões excessivas ou acesso irrestrito à internet continua capaz de gerar dano dentro do seu escopo autorizado. A arquitetura mais segura combina sandbox, menor privilégio, limites de rede, credenciais de curta duração, logs de auditoria e aprovação humana para ações irreversíveis.
O valor do SPACE, portanto, não está em prometer um “agente seguro”, mas em oferecer uma base concreta para tratar execução como infraestrutura de segurança. À medida que agentes deixam de sugerir ações e passam a realizá-las, essa base tende a ser tão decisiva quanto a escolha do modelo.
Onde consultar o projeto
- Repositório oficial do SPACE no GitHub
- Documentação de arquitetura do SPACE
- Guia oficial de instalação local
- Projeto Firecracker
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
