Sandbox para agentes de IA que executam código: o que verificar antes

Um sandbox para agente de IA é um lugar isolado onde o código gerado é executado, com pastas de trabalho próprias, uma lista curta de destinos de rede alcançáveis e sem acesso a credenciais da empresa ou a sistemas em produção, a menos que a tarefa conceda isso de forma explícita. Um agente que roda scripts precisa desse isolamento porque o código pode estar errado, pode ser influenciado por conteúdos que o agente lê e pode agir em velocidade de máquina. Antes de liberar qualquer execução, verifique o que a rodada pode ler, gravar, alcançar e manter, e quem é avisado quando ela tenta algo fora desses limites.

Principais pontos

• O sandbox é a fronteira da execução. Ele não é uma configuração opcional quando o agente escreve e roda scripts.
• Bloqueie o acesso de saída à rede por padrão e libere destinos nomeados um a um, com um motivo registrado.
• Dê a cada execução a sua própria pasta de trabalho, defina o que pode permanecer depois da rodada e mantenha as demais pastas fora de alcance.
• Mantenha as credenciais fora do sandbox e entregue apenas um acesso restrito e de curta duração para uma única tarefa.
• Registre cada execução, cada tentativa bloqueada e cada alteração de arquivo para que uma pessoa possa revisar o que aconteceu.

Por que um agente que executa código precisa de um sandbox próprio?

Quando um modelo de linguagem apenas redige texto, o pior resultado comum é uma frase ruim que uma pessoa lê antes de qualquer coisa acontecer. Quando o mesmo modelo escreve um script e o executa, a saída vira ação. Um script pode apagar arquivos, chamar um endereço externo, instalar um pacote ou enviar dados a um serviço que não deveria tocar. O modelo não precisa ter intenção ruim para que isso dê errado. Basta uma suposição errada sobre o caminho de um arquivo, uma coluna mal interpretada em uma planilha ou uma dependência que mudou desde a última execução.

A entrada é o segundo risco. Agentes leem e-mails, páginas da web, chamados e documentos, e qualquer um deles pode conter texto escrito para redirecionar o agente. As orientações da OWASP sobre injeção de prompt tratam isso como um problema de projeto para se planejar, e não como um caso raro: conteúdo não confiável pode tentar sobrepor as instruções dadas ao agente. Um sandbox não impede que o modelo seja convencido. Ele limita o que um agente convencido consegue alcançar, e esse limite é o motivo para construí-lo.

O que o sandbox precisa isolar?

O isolamento cobre quatro superfícies: processo, arquivos, rede e identidade. O isolamento de processo impede que o código toque na máquina hospedeira ou em outras cargas de trabalho. O isolamento de arquivos dá à rodada um diretório de trabalho próprio e bloqueia leituras de pastas fora da tarefa. O isolamento de rede controla quais endereços o código consegue acessar. O isolamento de identidade garante que a rodada não herde um login pessoal, uma sessão de navegador ou uma chave de serviço ampla que esteja disponível na máquina.

Muitas equipes param no isolamento de processo porque ele é o mais conhecido. As outras três superfícies decidem se um erro continua pequeno. Verifique cada uma separadamente e registre a resposta. Uma resposta vaga em qualquer uma delas significa que o ambiente ainda não está pronto para dados reais.

Limite o acesso à rede antes de tudo

O acesso à rede tem a maior consequência, porque é por ali que os dados saem. O padrão deve ser não permitir conexões de saída. Quando uma tarefa precisa de um serviço, libere aquele host específico e apenas os métodos que a tarefa exige. Um script que lê uma tabela de preços pública não precisa de acesso de escrita a um provedor de pagamentos, e um script que monta um relatório semanal não precisa da internet aberta. As permissões de cada destino liberado devem ser revisadas da mesma forma que você revisaria o acesso de uma pessoa, como descrito em menor privilégio para agentes de IA.

Destinos liberados também podem apontar para algo que você não pretendia. Teste se o sandbox alcança páginas administrativas internas, outras máquinas da mesma rede e endereços de metadados de nuvem, que às vezes expõem credenciais temporárias. Pergunte ao fornecedor da plataforma como são tratadas a resolução de nomes e os redirecionamentos, e se os hosts permitidos são aplicados na camada de rede ou apenas no código que o agente escreve. A segunda opção é mais fraca, porque código gerado pode chamar qualquer coisa que consiga construir.

O padrão mais seguro para um script é não conseguir alcançar nada que não lhe tenha sido dado explicitamente.

Controle o acesso a arquivos e o que sobrevive à rodada

Dê a cada execução um diretório de trabalho vazio e monte apenas os arquivos de entrada que a tarefa indica. Os resultados devem ir para uma pasta designada, que um revisor consiga abrir. Decida se o sandbox é apagado depois de cada rodada. Estado persistente é útil em trabalhos longos, mas é também onde se acumulam arquivos antigos, tokens esquecidos e dados corrompidos. Quando um agente precisa reaproveitar informações de uma rodada para a seguinte, guarde-as pela camada de memória ou banco de dados aprovada, e não em um arquivo solto que a próxima execução aceita sem conferir. Em sistemas de dados, uma conexão somente leitura costuma ser o ponto de partida certo, como explicado em conectar um agente de IA ao banco de dados só com leitura.

Cenário ilustrativo: um pequeno distribuidor permite que um agente limpe uma exportação semanal de pedidos. O sandbox recebe um único arquivo CSV, grava uma versão limpa em uma pasta de saída e não tem caminho até o drive compartilhado. Em uma semana, a exportação traz uma célula que parece um comando. Como a rodada não tem rota de rede e não pode gravar fora da sua pasta, o script falha com um erro, registra uma entrada no log e nada mais muda. Uma pessoa revisa o log na segunda-feira e corrige a exportação de origem.

O que verificar antes de liberar a execução de código?

Use a lista a seguir como revisão antes da primeira rodada real. Cada item deve ter uma resposta escrita e um responsável.

• Quais linguagens e bibliotecas podem rodar, e quem aprova um pacote novo antes da instalação?
• Quais hosts de rede são alcançáveis, listados pelo nome, com um motivo para cada um?
• Quais pastas são visíveis para a rodada, e cada uma é somente leitura ou gravável?
• Por quanto tempo uma rodada pode durar, e quais limites de memória e de processador a interrompem?
• Quais credenciais, se houver, entram no sandbox, e elas são de curta duração e restritas a uma tarefa? Compare as opções em onde guardar senhas e chaves de API de agentes de IA.
• O que é registrado: o código executado, as entradas, as saídas, as tentativas de conexão bloqueadas e as alterações de arquivo?
• Quem recebe alerta quando uma rodada atinge um limite, e o que o agente pode fazer em seguida sem pedir permissão?
• O ambiente pode ser apagado e recriado rapidamente a partir de uma definição conhecida?
• Alguém testou uma entrada deliberadamente hostil, como um documento com instruções para enviar dados para outro lugar, antes que registros reais entrem?

Se ninguém da equipe consegue responder a uma dessas linhas, o agente ainda não deve receber direito de execução para aquela tarefa. Uma tarefa mais estreita, com a folha de respostas completa, é um primeiro passo melhor do que uma tarefa ampla com lacunas.

Como a Be Human trata sandboxes em operações gerenciadas?

A Be Human desenha a fronteira de execução como parte do primeiro projeto, e não como um acréscimo posterior. O primeiro papel define quais scripts o agente pode rodar, a política de sandbox para rede, arquivos e credenciais, os pontos de aprovação para instalar pacotes ou gravar fora da pasta de saída, e um critério de sucesso que mostra se a fronteira está funcionando. Em operações gerenciadas, a equipe revisa os logs de execução e as tentativas bloqueadas, testa as permissões em uma agenda recorrente, mantém as integrações quando um fornecedor muda um endereço ou o formato de um token, e trata incidentes pausando a execução enquanto a causa é rastreada. Memória, ferramentas e permissões continuam sob controle da empresa o tempo todo. Se você não tem certeza de qual tarefa merece direito de execução primeiro, faça o diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa que vale entregar a um agente.

Perguntas frequentes

Sandbox é a mesma coisa que contêiner? Um contêiner é uma forma comum de construir um sandbox, porque empacota um processo com sua própria visão de arquivos e limites de recursos. Só o contêiner não define o que o código alcança pela rede nem quais credenciais ele enxerga. Essas regras precisam ser definidas de propósito, qualquer que seja a tecnologia que fornece o isolamento.

Posso deixar o agente rodar código no meu notebook ou em um servidor compartilhado? Você pode testar no notebook com dados fictícios, mas um servidor compartilhado ou uma máquina pessoal normalmente guarda logins, tokens e arquivos que um script alcançaria por padrão. Para qualquer coisa que toque registros reais da empresa, use um ambiente separado, sem acesso herdado. Mantenha claramente separados o ambiente de teste e o de produção.

O sandbox impede a injeção de prompt? Não. Um sandbox não faz o modelo ignorar instruções hostis e não consegue julgar se um pedido é legítimo. O que ele faz é limitar o dano quando uma instrução tem sucesso, mantendo pequeno o acesso à rede, aos arquivos e às credenciais. Combine-o com etapas de aprovação para qualquer ação que altere dados ou envie algo para fora da empresa.

Como saber se o sandbox está funcionando? Teste de propósito. Peça ao agente que acesse um host que não deveria alcançar, leia uma pasta que não deveria ver e grave fora do diretório de saída, e confirme que cada tentativa foi bloqueada e registrada. Repita essas verificações após qualquer mudança em permissões, pacotes ou fornecedores, porque os limites tendem a se desviar quando ninguém os acompanha.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.