Sandboxes de Agentes, Explicadas: Por que o TrueForge trata a Sandbox como uma Ferramenta

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
Um sandbox pode isolar a execução de código, arquivos e shell sem se tornar todo o tempo de execução do agente. Essa escolha altera os custos, a exposição de credenciais, o ciclo de vida e a semântica de recuperação.
Um sandbox responde a uma pergunta mais restrita do que "o agente é seguro?".
Um agente pode precisar executar código, manipular arquivos, inspecionar um repositório ou rodar comandos de shell. Essas operações não devem compartilhar um limite de processo irrestrito com o servidor de orquestração ou com a infraestrutura de produção da organização. Um sandbox cria um ambiente de execução restrito para esse trabalho.
Mas "agente em sandbox" é uma frase imprecisa. Pode significar que todo o loop do agente roda dentro de uma máquina isolada, incluindo clientes de modelo, credenciais de ferramentas e estado. Ou pode significar que o loop do agente permanece em um tempo de execução gerenciado e invoca um ambiente isolado apenas para tarefas que exigem muita execução. O TrueForge escolhe o segundo design: sandbox como ferramenta.
A distinção altera o que é isolado, quando a computação existe, onde os segredos residem e o que sobrevive a uma falha. Também evita que um sandbox se torne um rótulo de segurança mágico. O limite protege apenas as operações e o tráfego efetivamente colocados atrás dele.

A arquitetura mantém o modelo portador de segredos e os clientes MCP no lado do harness, enquanto dá ao código e ao trabalho de shell um limite de execução separado. O conector é um caminho de capacidade, não uma transferência de credenciais para dentro do sandbox.
Duas arquiteturas, diferentes compensações
Em uma arquitetura de agente-dentro-do-sandbox, cada execução ou ambiente de agente pode conter o loop de orquestração, cliente de modelo, ferramentas, credenciais e arquivos de trabalho. O isolamento é conceitualmente simples porque a maior parte da atividade ocorre dentro de um único limite. Os custos são provisionamento mais pesado, injeção de segredos mais complexa e reconstruções de imagem quando as dependências de tempo de execução mudam.
Na arquitetura documentada de sandbox-como-ferramenta do TrueForge, o loop do agente roda no servidor TrueForge. O sandbox é provisionado apenas quando o agente precisa de código, arquivo, shell, uma habilidade ou Modo de Código. Turnos de conversação simples e chamadas MCP não exigem computação de sandbox. As credenciais de modelo e MCP permanecem no harness, e as chamadas MCP do Modo de Código são redirecionadas para o harness em vez de fornecer esses tokens ao sandbox.
Isso reduz a superfície portadora de segredos e permite que o estado da conversação sobreviva a uma falha no sandbox. Também significa que o sandbox não é o perímetro de rede para cada chamada de modelo e ferramenta. O tráfego do provedor de modelo e as operações MCP originam-se através do caminho do harness, e eles precisam de seus próprios controles de gateway, identidade, credencial e rede.
O ciclo de vida documentado é limitado à sessão
O TrueForge documenta o sandbox como desativado por padrão para cada agente. Quando ativado e necessário, ele é provisionado sob demanda. O sandbox é reutilizado entre turnos na mesma sessão, portanto, os arquivos persistem enquanto a conversação continua. Após um período de inatividade, ele é interrompido, arquivado e, eventualmente, excluído de acordo com as configurações do provedor.
Esse ciclo de vida é mais útil do que "um contêiner descartável por prompt", mas introduz questões de gerenciamento de estado. Um arquivo do Turno 1 pode influenciar o Turno 5. Um arquivo malicioso extraído precocemente pode permanecer presente após a tarefa imediata ser esquecida. Uma dependência instalada durante um turno pode alterar a execução posterior. A continuidade da sessão é um recurso; o acúmulo de estado não gerenciado é um risco.
As aplicações devem rotular artefatos com seu evento de origem, resumo de conteúdo, classificação de dados e tempo de vida pretendido. Antes que um turno posterior execute um arquivo, verifique se ele ainda pertence à tarefa ativa e se o usuário atual está autorizado a acessá-lo. Quando a reprodutibilidade for importante, registre o snapshot do sandbox ou a identidade da imagem, o estado de bloqueio de dependências e os comandos que produziram o artefato.

A reutilização entre turnos é apresentada como um recurso e um risco. Os arquivos podem preservar um trabalho útil após uma pausa, mas cada artefato restaurado precisa de procedência, classificação e uma regra de ciclo de vida, em vez de herdar a confiança apenas da sessão.
Credenciais fora do sandbox reduzem — mas não removem — a autoridade
Manter as credenciais do modelo e do MCP no harness impede que códigos arbitrários em sandbox leiam esses segredos diretamente. Essa é uma barreira sólida. No entanto, um script em sandbox ainda pode solicitar que o harness execute uma chamada MCP por meio de uma ponte controlada. A questão de segurança relevante passa a ser: quais chamadas esse código pode solicitar, com qual identidade, usando quais argumentos e sob qual política?
A ponte deve expor uma capacidade restrita em vez de uma credencial genérica. Definições de ferramentas, identidade do sujeito, destino, classificação de dados, orçamentos cumulativos e requisitos de aprovação devem ser avaliados fora da sandbox. Os resultados retornados ao código devem ser minimizados, pois podem se tornar arquivos, logs ou entradas de comando dentro do ambiente.
Da mesma forma, a ausência de credenciais de modelo não prova que a sandbox não possui saída. A configuração do provedor determina a acessibilidade da rede. Uma implementação robusta define separadamente destinos de saída, comportamento de DNS, política de instalação de pacotes, acesso a serviços de metadados, montagens de sistema de arquivos, limites de recursos e controles de encerramento. O TrueForge orquestra o provedor da sandbox; a organização ainda valida o provedor e sua configuração em relação ao seu modelo de ameaças.
Mapeie explicitamente os limites de confiança
Expor
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.












.png)
.png)
.png)
.png)
.png)
.webp)
.webp)

.png)
.png)
.png)
.png)
.png)
.png)
.png)





