O que é um sandbox de IA? Como agentes executam código com limites

Um agente de programação pode sugerir uma alteração sem executar nada. O risco muda quando ele instala um pacote, executa um teste, abre um arquivo enviado ou inicia um servidor. Essas ações executam programas com as permissões do ambiente. Um comando de teste pode executar scripts de dependências; uma análise pode abrir arquivos que o usuário nunca pretendeu compartilhar.

Considere um agente encarregado de corrigir um aplicativo com falhas. Ele lê o projeto, altera um módulo, instala dependências e executa os testes. Dar a esse processo seu ambiente de desenvolvimento habitual também dá acesso a tudo que ele alcança: diretórios montados, credenciais, serviços de rede e talvez sistemas de produção. Uma fronteira de execução permite conceder menos capacidades à tarefa.

O objetivo é tornar explícitas as ações permitidas. Um sandbox pode executar código incorreto, contatar um endpoint permitido ou usar indevidamente uma credencial fornecida de propósito. Trate o código gerado e suas dependências como entradas a verificar e projete o ambiente conforme as consequências de executá-las.

Uma execução típica começa com um projeto ou dados de entrada. O agente propõe código ou um comando, uma ferramenta o executa no ambiente configurado e devolve evidências como saída, código de retorno ou arquivo gerado. O agente pode usar esses resultados para fazer outra alteração.

Para um aplicativo, o resultado pode incluir um servidor de prévia. Para uma tarefa de dados, um gráfico. Para uma revisão de código, um teste com falha e seus logs. Um contrato útil define as entradas, o que foi executado, as saídas e o que deve permanecer após a execução parar.

Sandbox descreve uma finalidade, não uma implementação única. Contêineres Linux comuns usam namespaces e outros controles para separar processos, compartilhando o kernel do host. A documentação de segurança do Docker cobre namespaces, cgroups, capabilities e o risco de acesso ao daemon Docker. Montagens, privilégios e interfaces expostos continuam fazendo parte da fronteira.

O gVisor adiciona um kernel de aplicação em espaço de usuário que implementa uma interface semelhante à do Linux. Ele faz a mediação com o host e busca reduzir a exposição a vulnerabilidades do kernel do host. Essa camada adicional também exige avaliar a compatibilidade e o desempenho da carga.

Uma microVM executa um kernel convidado dentro de uma máquina virtual. O Firecracker é uma implementação: seu projeto descreve convidados Linux, KVM, um modelo reduzido de dispositivos e um jailer para produção. A plataforma ainda precisa configurar armazenamento, rede, identidade e o ciclo de vida de cada ambiente.

Um sandbox não precisa ser descartável. O isolamento descreve a fronteira da execução; a persistência descreve o que permanece depois. Você pode executar uma tarefa curta sobre código durável, manter um ambiente entre interações ou descartar seus arquivos após coletar o resultado.

Defina com precisão o que persiste. Um repositório salvo é diferente de um cache de dependências, de um volume de dados montado ou da memória de um processo em execução. Parar um ambiente pode preservar alguns deles e perder outros. Uma sessão longa não substitui backups ou controle de versão.

Para agentes de programação, um workspace durável com ciclo de execução próprio é uma combinação útil. A equipe pode continuar revisando o código após parar uma prévia e refazer o build com as entradas registradas. Para cálculos pontuais, manter a referência de entrada e o artefato de saída pode bastar.

O isolamento do runtime não decide se a ação solicitada por um agente é adequada. Se o ambiente alcança um serviço externo e possui uma credencial aceita por ele, o código pode usar esse acesso. Proteger o host e limitar as permissões do aplicativo são tarefas relacionadas, mas distintas.

O modelo de segurança do gVisor distingue explicitamente os recursos externos ao sandbox daqueles disponibilizados dentro dele. Aplique essa distinção ao decidir quais arquivos, destinos de rede e credenciais expor. Passar dados sensíveis para um ambiente isolado continua sendo uma decisão de disponibilizá-los à tarefa.

O mesmo vale para produção. Um agente pode gerar um build válido e ainda introduzir uma verificação de permissões falha ou uma consulta cara. Mantenha a revisão do aplicativo e a autorização de publicação no fluxo; o isolamento não prova que a funcionalidade está correta.

Um assistente de programação precisa dos arquivos do projeto, de ferramentas de build e de uma forma de revisar alterações. Um agente que cria aplicativos também precisa de um processo de prévia e de uma rota acessível. Um agente de análise de dados precisa dos dados de entrada relevantes e de uma forma de devolver um artefato. Essas tarefas podem compartilhar infraestrutura sem exigir as mesmas permissões ou regras de retenção.

Executar scripts de clientes é outro caso. O código pode ser intencionalmente hostil, e uma tarefa não deve consumir a cota de outro cliente nem acessar seus dados. Avalie explicitamente esse modelo de confiança antes de tratar um workspace conveniente como um serviço de execução de código arbitrário.

Meça o caminho completo da tarefa ao comparar opções. Um número de inicialização do runtime não inclui o carregamento do código, a instalação de dependências, as filas, a inicialização do aplicativo e as verificações de integridade. O tempo até o agente poder usar um resultado costuma ser mais útil.

Defina o contrato de execução antes de escolher um provedor ou criar a integração. Teste com cargas representativas, incluindo falhas. Um comando travado, uma dependência ausente ou uma prévia parada devem produzir um estado que seu aplicativo consiga entender e do qual possa se recuperar.

O Adios conecta o fluxo de programação por meio de um workspace baseado em código-fonte. Sua documentação descreve arquivos, operações Git, atividade do agente, builds, logs, controles de prévia e deploy. A equipe mantém um projeto ao qual pode voltar depois que um comando ou uma prévia termina.

Um cliente MCP compatível pode usar as ferramentas hospedadas do Adios para criar um workspace, gravar arquivos, preparar uma prévia e consultar logs. A autenticação limita o cliente aos recursos autorizados da equipe. O fluxo MCP documentado exige aprovação explícita antes do deploy.

A visão geral da segurança do Adios descreve namespaces Linux, cgroups e limites de recursos quando suportados pelo runtime escolhido. Esses controles documentados devem orientar a avaliação; a palavra sandbox não promete uma microVM ou um kernel convidado dedicado para cada workspace. Confirme as propriedades necessárias para o código que pretende executar.

Para experimentar o fluxo, conecte um cliente MCP ou abra um workspace, faça uma pequena alteração e examine o build e a prévia. Mantenha o resultado no Git. Isso oferece um ponto de partida concreto para decidir o que a próxima tarefa do agente precisa.