O que aprendemos ao rodar agentes de IA em sandboxes na nuvem: Resultados e benchmarks
Testamos plataformas de sandbox em situações reais: conexões WebSocket contínuas funcionam bem, mas cortar o acesso de saída à internet inviabiliza o trabalho dos agentes.
O plano original previa cortar todo o tráfego de saída das máquinas dos agentes. Os testes provaram que os agentes precisam acessar APIs de modelos e repositórios remotos.
A importância central do WebSocket
Terminais exigem fluxos contínuos de dados, suportados nativamente via HTTP Upgrade.
GET /?identifier=<id>&api-version=2024-02-02-preview
Authorization: Bearer <token>
101 Switching Protocols
frames server to client, and client to serverRequisições sem credenciais são rejeitadas com 403 Unauthenticated.
A rede de saída não pode ser desligada
Sem internet de saída o agente não consegue consultar LLMs nem o Git. A segurança deve estar nos dados que a máquina armazena.
As restrições da infraestrutura moldam a arquitetura mais do que os diagramas conceituais.
Conclusões práticas
Valide sempre a infraestrutura com testes reais antes de definir a arquitetura e mantenha os protocolos desacoplados do transporte de rede.
O impacto arquitetural é detalhado em a máquina que executa os agentes não guarda segredos, e os terminais em observar um terminal remoto.
Respostas diretas
É possível rodar agentes de código em sandboxes gerenciadas na nuvem?
Sim. Os testes confirmam suporte estável a conexões WebSocket persistentes.
Por que testar em vez de apenas ler a documentação?
Porque detalhes práticos de proxies, escopos de tokens e timeouts só aparecem em execução real.
O que mudou na arquitetura após os testes?
O isolamento foi aplicado no design do software (removendo banco e chaves) em vez de bloqueio cego de rede de saída.