Managed Agents no Gemini API: Sandbox Virou Feature

Google lançou Managed Agents no Gemini API durante a onda do I/O 2026. A ideia: com uma chamada, você sobe um agente que raciocina, usa ferramentas e executa código em um ambiente Linux isolado e efêmero.

Isso parece infraestrutura. Para dev, é produto. A parte difícil de agente em produção nunca foi só chamar um modelo. É dar ferramentas sem dar permissão demais, executar código sem contaminar ambiente e versionar instruções sem virar prompt solto.

Managed Agents colocam esse problema no centro da API. Sandbox deixou de ser detalhe de segurança e virou feature de developer experience.

---

Por Que Sandbox Importa

Agente que executa código precisa de limite. Ele pode ler arquivo, rodar comando, instalar pacote, chamar API e manipular dados. Sem sandbox, qualquer erro vira risco operacional.

Ambiente efêmero reduz impacto. O agente roda, produz artefato, termina e o ambiente desaparece. Isso dificulta persistência acidental, vazamento de estado e dependência invisível.

Também melhora reprodutibilidade. Se cada execução começa limpa, fica mais fácil entender o que aconteceu.

Sandbox não resolve tudo. Secrets, rede, permissões e dados ainda precisam de controle. Mas sem sandbox, nem comece conversa séria sobre agentes executores.

---

AGENTS.md E SKILL.md Como Contrato

O ponto que mais chama atenção é suporte a agentes customizados com instruções, skills e dados definidos como arquivos versionáveis usando AGENTS.md e SKILL.md.

Isso é grande porque tira comportamento de agente do prompt escondido e coloca no repositório. Quando regra vira arquivo, ela pode ser revisada, versionada, testada e discutida.

Esse padrão já vem aparecendo em várias ferramentas. O projeto deixa de ser apenas código para humanos e passa a ser ambiente de trabalho para agentes.

Para times, isso cria uma nova camada de arquitetura: documentação operacional para IA.

---

Interactions API E Google AI Studio

Google posiciona Managed Agents dentro da Interactions API e do Google AI Studio. Isso indica uma tentativa de cobrir dois públicos: devs que querem API e builders que querem experimentar visualmente.

Essa combinação é útil. Protótipo pode começar no AI Studio, depois virar agente versionado e executado via API. O caminho de demo para produção fica menos quebrado.

O risco é a mesma armadilha de sempre: demo sem governança. Se o agente tem ferramenta poderosa, precisa de política desde o início.

Mesmo em sandbox, o agente pode gerar código inseguro, acessar dados errados ou usar ferramenta de forma indevida. Sandbox limita execução, não substitui design.

---

Quando Managed Agent Faz Sentido

Faz sentido para tarefas que precisam de execução controlada: análise de repositório, geração de artefatos, validação de código, transformação de arquivos, pesquisa com ferramentas e prototipação técnica.

Não faz sentido para ação irreversível sem revisão. Alterar produção, enviar e-mail externo, aprovar pagamento ou modificar dados sensíveis exigem gate humano e logging forte.

Também é bom para produtos que querem oferecer agentes aos próprios usuários sem construir sandbox do zero. Em vez de manter infraestrutura isolada, a API entrega parte do runtime.

Isso reduz barreira de entrada para startups. Empresas maiores ainda vão perguntar sobre controle, região, logs, rede e compliance.

---

O Novo Backend Dos Agentes

Antes, backend de IA era endpoint chamando LLM. Agora começa a parecer outra coisa: runtime com ambiente, ferramentas, estado, arquivos, política, observabilidade e artefatos.

Managed Agents mostram essa evolução. Modelo sozinho responde. Runtime executa.

Para arquitetos, isso muda desenho de sistema. Você precisa decidir onde o agente roda, quais ferramentas entram, como auditar, como recuperar falhas e como versionar comportamento.

Prompt engineering vira só uma parte pequena. Agent runtime engineering vira disciplina.

---

O Que Um Sandbox Precisa Ter

Sandbox bom não é só "rodar em container". Ele precisa controlar filesystem, rede, tempo de execução, memória, CPU, secrets e saída. Também precisa registrar ações.

Para agentes, o ponto mais delicado é rede. Um agente com internet aberta pode baixar pacote, chamar endpoint externo, enviar dado sem perceber ou seguir instrução maliciosa. Rede deve ser intencional, não padrão invisível.

Secrets também exigem cuidado. O ambiente efêmero não deve receber credenciais completas por conveniência. Se a tarefa precisa acessar um recurso, use token escopado e temporário.

Outro ponto é artefato. O agente precisa devolver resultado de forma verificável: arquivo gerado, diff, log, comando rodado e resumo de validação. Sem isso, sandbox vira caixa-preta.

---

AGENTS.md Dentro Do Runtime

Quando AGENTS.md e SKILL.md entram no runtime, a instrução deixa de ser conversa e vira configuração. Isso muda governança.

Você pode versionar instruções, revisar mudanças, comparar comportamento entre versões e fazer rollback. Isso aproxima agentes de software tradicional.

Também permite ambientes diferentes. Um agente em sandbox de leitura recebe ferramentas limitadas. Um agente de transformação recebe filesystem e testes. Um agente de produção recebe quase nada sem aprovação.

Essa separação é saudável. Nem todo agente precisa do mesmo poder.

---

Managed Agents Versus Construir Tudo Em Casa

Empresas técnicas podem construir sandbox próprio. Docker, Firecracker, Kubernetes, policy engine, logs, fila, isolamento e storage temporário. Dá para fazer. Também dá trabalho.

Managed Agents reduzem esse esforço inicial. Para startups e times menores, isso pode acelerar produto. Em vez de gastar meses construindo runtime, o time testa casos de uso.

Mas serviço gerenciado não elimina responsabilidade. Você ainda precisa decidir política, dados permitidos, logging, retenção e riscos legais.

Minha leitura: use gerenciado para acelerar aprendizado, mas mantenha arquitetura com fronteiras claras. Não deixe regra crítica escondida só no provedor.

---

Casos De Uso Bons

Um bom caso inicial é análise de repositório. O agente recebe código, roda leitura e devolve relatório. Baixo risco, muito valor.

Outro caso é geração de artefato: documentação, changelog, migration plan, matriz de testes ou resumo de incidentes. O agente produz saída revisável.

Também faz sentido para validação: rodar testes, comparar outputs, verificar lint, detectar quebra de contrato e sugerir correção.

Casos ruins para começar: alteração direta de produção, envio externo, mudança de permissão, operação financeira e qualquer ação sem rollback.

---

Observabilidade Para Agentes

Se você não consegue explicar o que um agente fez, ele não está pronto para tarefa séria. Observabilidade precisa incluir tool calls, inputs relevantes, comandos, arquivos tocados, erros, decisões e outputs.

Logs não devem vazar segredo. Isso cria outro desafio: registrar o suficiente para auditar sem expor dados sensíveis.

Também vale ter replay parcial. Se um agente falha, o time precisa reproduzir contexto ou pelo menos entender sequência de eventos.

Em software tradicional, logs ruins dificultam incidentes. Em agentes, logs ruins podem tornar impossível saber se a ação foi correta ou só pareceu correta.

---

Relação Com Supply Chain

Sandbox também ajuda contra supply-chain, mas não resolve tudo. Se o agente instala pacote malicioso dentro de ambiente sem secrets e sem rede de saída, impacto cai. Se instala com token de produção disponível, impacto explode.

Managed Agents devem ser combinados com lockfile, allowlist, scanner e política de dependência. Agente não deveria atualizar pacote crítico sem aprovação.

Também é importante tratar AGENTS.md e SKILL.md como supply chain de contexto. Se essas instruções forem comprometidas, o agente pode executar comportamento errado de forma obediente.

Segurança de agente junta duas coisas: execução isolada e contexto confiável.

---

Como Avaliar O Gemini Managed Agents

Eu avaliaria com uma matriz simples. Primeiro, tempo para colocar um agente útil de pé. Segundo, qualidade do isolamento. Terceiro, facilidade de observabilidade. Quarto, integração com ferramentas existentes. Quinto, controle de custo.

Também testaria falhas. O que acontece quando comando quebra? Quando pacote não instala? Quando o agente tenta acessar recurso proibido? Quando excede tempo?

Produto de runtime precisa lidar bem com erro. Demo costuma mostrar caminho feliz. Produção vive em caminho torto.

Se o runtime falha de forma clara e auditável, é bom sinal.

---

O Impacto Para Arquitetura De Produto

Produtos que querem oferecer agentes aos clientes precisam pensar em multi-tenancy. Um agente de um cliente não pode ver dado de outro. Ambiente efêmero ajuda, mas isolamento de dados precisa estar em toda camada.

Também há questão de custo por usuário. Agente executando código pode consumir mais do que chamada simples de LLM. Produto precisa de quota, plano e rate limit.

Outra decisão é experiência. Usuário espera resultado síncrono ou tarefa assíncrona? Agentes executores muitas vezes precisam de fila, progresso e notificação.

Managed Agents podem acelerar backend, mas produto ainda precisa desenhar jornada.

---

Um Modelo De Permissões Em Camadas

Eu desenharia permissões de agentes em camadas. Camada um: leitura sem secrets e sem rede externa ampla. Camada dois: escrita em workspace efêmero, ainda sem acesso a produção. Camada três: uso de ferramentas internas com token escopado. Camada quatro: ações sensíveis com aprovação humana.

Essa separação evita o erro clássico de dar poder demais cedo demais. O agente começa com autonomia baixa e sobe conforme caso de uso prova valor.

Também ajuda auditoria. Quando algo dá errado, fica claro em qual camada a falha ocorreu. O problema foi leitura? Escrita? Ferramenta? Aprovação?

Sem camadas, toda discussão vira binária: deixa agente fazer tudo ou nada. Essa é uma falsa escolha.

---

Como Testar Segurança Sem Esperar Incidente

Faça testes adversariais simples. Coloque uma instrução maliciosa em um arquivo de documentação de teste e veja se o agente obedece. Peça para acessar secret inexistente e veja se insiste. Tente induzir download de script remoto.

Esses testes mostram se o runtime respeita limites ou se apenas confia no comportamento do modelo.

Também rode simulações de falha. Interrompa rede, quebre dependência, negue permissão, force timeout. Um runtime bom falha de forma clara.

Produção não perdoa agente que entra em loop silencioso ou oculta erro para parecer competente.

---

Diferença Entre Sandbox E Ambiente De CI

Sandbox de agente e CI não são a mesma coisa. CI valida uma mudança em pipeline definido. Sandbox permite exploração, leitura, tentativa e erro. Por isso precisa de controles diferentes.

No CI, comandos são previsíveis. No sandbox, agente pode decidir próximos passos. Essa liberdade exige logging mais rico e política mais granular.

Também muda o ciclo de vida. CI roda e termina. Agente pode criar artefatos intermediários, planos, patches e logs. O produto precisa preservar o que importa e descartar o resto.

Se a empresa tratar sandbox como CI com chat, vai subestimar o risco.

Também vale separar output de execução. O agente pode gerar plano, patch, relatório ou artefato. Cada tipo de output tem risco diferente. Plano pode ser revisado com calma. Patch precisa de teste. Artefato pode precisar de validação externa.

Essa distinção ajuda produto e segurança a falarem a mesma língua. Nem toda execução de agente é perigosa, mas toda execução precisa de categoria clara.

Categoria clara também ajuda custo. Tarefa de leitura, tarefa de patch e tarefa de execução externa não deveriam ter o mesmo budget, timeout ou política de aprovação.

Esse desenho torna autonomia incremental. O time aprende com tarefas seguras antes de liberar ações mais caras, sensíveis ou difíceis de desfazer.

---

Principais Aprendizados

• Managed Agents rodam agentes em sandbox Linux efêmero.
• AGENTS.md e SKILL.md tornam comportamento versionável.
• Sandbox reduz risco, mas não elimina governança.
• API e AI Studio ajudam a ligar protótipo e produção.
• Backend de agentes vira runtime, não só chamada LLM.

---

Conclusão

Managed Agents no Gemini API mostram uma direção saudável: se agentes vão executar código e usar ferramentas, o runtime precisa ser produto de primeira classe.

Para devs, a mensagem é prática. Comece a tratar instruções, skills e permissões como parte do código. O agente que trabalha no seu projeto também precisa de arquitetura.

---

Fontes e Referências

• Introducing Managed Agents in the Gemini API
• Building the agentic future: Developer highlights from I/O 2026
• All the news from the Google I/O 2026 Developer keynote
• Google Antigravity Documentation