Em um mesmo ciclo de anúncios, três sinais apontaram para o mesmo lugar. A Google lançou o Agent Compute Engine: cada agente autônomo recebe um microVM isolado por hardware onde pode rodar um shell, dirigir um browser headless e escrever código — com root, em loops que duram semanas, com checkpoint e resume quando precisa esperar um humano ou um modelo. No mesmo movimento, a Google estendeu a governança de agentes a ambientes de terceiros e abriu o Agent Substrate, um runtime open-source para Kubernetes que registrou 500 ativações por segundo num benchmark de 200 mil agentes. No mesmo ciclo, a Modal cruzou US$ 1 bilhão de run rate e levantou US$ 750 milhões — com o sandbox de agente já representando cerca de um terço da receita, bilhões de sandboxes criados e distribuídos por mais de 20 nuvens. E a OpenAI colocou em disponibilidade geral a Decisions API, com a Datadog relatando pontuar comandos de shell arriscados de agentes 40 vezes mais rápido. Junte os pontos: a conversa sobre IA parou de ser "qual modelo" e virou "onde e como o agente roda".
O que mudou esta semana: o agente ganhou um runtime
Durante dois anos, a pergunta que definiu a adoção de IA foi qual modelo respondia melhor. Essa pergunta está envelhecendo depressa. Quando a maior provedora de nuvem do planeta anuncia que cada agente passa a ter um ambiente de execução isolado por hardware, a mensagem implícita é que os agentes deixaram de só sugerir texto e passaram a executar trabalho real: abrir um terminal, navegar, compilar, disparar integrações, manter estado por semanas. O Agent Compute Engine não é um modelo mais inteligente — é um lugar para o agente rodar. E a arquitetura desse lugar entrega o que importa: o sandbox não guarda segredo nenhum. As credenciais são injetadas no ponto de egress de rede, fora do microVM, e cada agente carrega uma identidade curta e própria.
A Modal confirma o mesmo movimento pelo lado da economia. Se o sandbox de agente já é um terço da receita de uma empresa que acabou de ser avaliada em US$ 16 bilhões, então "rodar código gerado por IA" virou uma categoria de infraestrutura com custo e escala próprios — não um detalhe de implementação. E a Datadog fecha o triângulo pelo lado do controle: pontuar o risco de um comando de shell que um agente quer executar virou uma chamada de API de baixa latência, porque alguém precisa decidir, em tempo de máquina, se aquela ação perigosa passa ou não. Nenhum desses três anúncios é sobre inteligência do modelo. Todos são sobre o runtime: onde o agente executa, com qual isolamento, com qual segredo e sob qual governança.
O agente que age é um processo com root na sua infra — não um prompt
Essa é a virada de chave que muita equipe ainda não fez na própria arquitetura. Enquanto o agente apenas gerava texto, o pior caso era uma resposta errada. Agora que o agente roda um shell, dirige um browser e escreve código em loop, o pior caso é um processo privilegiado agindo sozinho, em velocidade de máquina, dentro da sua infraestrutura. Um agente que executa não é um prompt: é um usuário não-humano com poder de mudar estado — mover arquivos, chamar APIs, tocar bancos de dados, provisionar recursos.
O caminho rápido, que funciona na demo e falha em produção, é dar ao agente a mesma chave que um humano usaria e soltá-lo no seu ambiente. Você acabou de criar um processo com privilégio amplo, credencial compartilhada, sem isolamento da execução e sem um botão de desligar individual. Quando algo der errado — e, em velocidade de máquina, "errado" acontece em segundos — você não vai saber qual agente fez o quê, não vai conseguir conter um sem derrubar todos, e vai descobrir que a chave que ele usava estava acessível de dentro do próprio processo que vazou. O diferencial e o risco migraram do modelo para a camada que contém e conecta esse runtime.
As 4 travas de contenção do runtime do agente
Quando o agente age sobre sistemas reais, quatro controles separam quem deixa o agente trabalhar com confiança de quem está sentado sobre uma superfície de ataque. Nenhum deles vem do modelo — todos vêm da camada de infraestrutura e integração que você controla. A própria arquitetura que a Google descreveu esta semana é um mapa desses quatro controles.
1. Isolar a execução. O agente roda dentro de um limite forte — um microVM ou container — de onde não alcança o resto do seu ambiente por engano nem por abuso. Se ele executa código arbitrário (e um agente que escreve e roda código executa, por definição, código arbitrário), esse código precisa estar numa caixa cujas paredes você definiu. Isolamento por hardware ou por kernel não é luxo: é a diferença entre um comando ruim contido e um comando ruim que passeia pela sua rede.
2. Segredo fora do agente. A credencial que o agente usa não pode viver dentro do agente — nem no código, nem no prompt, nem no sistema de arquivos do sandbox. O padrão que a Google adotou é claro: o segredo é injetado no ponto de egress de rede, fora do microVM. O agente faz a chamada; a camada de rede anexa a credencial certa no caminho. Assim, comprometer o sandbox não entrega a chave — porque a chave nunca esteve lá dentro.
3. Identidade efêmera por agente. Cada agente tem uma identidade própria, de vida curta, distinta da do usuário e da de outros agentes. Não é "a conta de serviço da empresa": é uma identidade de máquina emitida para aquele agente, naquela tarefa, por aquele tempo, rotacionável e revogável sozinha. Sem isso, toda ação é atribuída a um humano que não a executou, e a auditoria vira ficção.
4. Governança cross-nuvem. Seus agentes não vão viver todos na mesma nuvem — a própria Google estendeu a governança de agentes a ambientes de terceiros, e a Modal distribui sandboxes por mais de 20 nuvens. O controle precisa atravessar fronteiras: as mesmas regras de identidade, escopo e auditoria valendo quer o agente rode na sua nuvem, na do parceiro ou em Kubernetes aberto. Um cofre por fornecedor não governa nada — só fragmenta o problema em pedaços que ninguém vê inteiros.
Como a CCX constrói essa camada
É exatamente essa camada que as Integrações & APIs Enterprise da CCX constroem. Em vez de o agente chamar seus sistemas direto com uma chave compartilhada, as ações do agente passam por uma camada com contratos de API estáveis e arquitetura orientada a eventos (Kafka, RabbitMQ), onde cada agente age com identidade de máquina própria, escopo declarado e idempotência — para que um retry não vire efeito colateral duplicado. É o trilho por onde o agente executa em ERP, CRM, e-commerce e sistemas de pagamento sem herdar a sua chave mestra.
Por baixo e ao redor desse trilho, a Arquitetura Cloud e a frente de DevOps & CI/CD (Kubernetes, Helm, pipelines) provisionam o ambiente isolado e elástico onde o agente roda — contido, observável e portável entre nuvens; e a Security Engineering & Cybersecurity aplica OAuth2, menor privilégio, segredos em cofre (Vault), SIEM e o kill-switch por agente, mantendo a credencial fora do agente e auditando cada execução. Com mais de 200 projetos entregues em integração, cloud e segurança, a CCX trata o agente que age pelo que ele é: um processo com root rodando na sua infraestrutura, que só pode operar solto quando a camada de runtime o isola, mantém o segredo longe dele, lhe dá identidade efêmera e governa isso atravessando as nuvens.
Perguntas frequentes
O que é um sandbox (ou microVM) de agente de IA? É um ambiente de execução isolado onde o agente pode rodar código, comandos e navegação sem alcançar o resto da sua infraestrutura. O microVM leva o isolamento ao nível de hardware: cada agente roda numa máquina virtual leve e separada, de modo que um comando perigoso fica contido nos limites daquela caixa.
Por que guardar o segredo fora do agente? Porque o agente executa código que você nem sempre escreveu e nem sempre consegue prever. Se a credencial vive dentro do sandbox, qualquer comprometimento do agente expõe a chave. Injetando o segredo no ponto de egress de rede — fora do microVM — o agente consegue fazer a chamada autenticada sem nunca ter a chave em mãos.
Como isolar um agente que roda código? Combinando isolamento da execução (microVM/container), identidade efêmera e escopo próprios por agente, e uma camada de integração por onde toda ação passa de forma auditável. O objetivo é que o agente só consiga fazer o que a tarefa exige, sem rastro dependente da boa vontade do próprio agente.
Dá para governar agentes em várias nuvens? Sim, se a governança não estiver presa a um fornecedor. As mesmas regras de identidade, escopo e auditoria precisam valer em qualquer ambiente onde o agente rode — e é por isso que a camada de integração e governança, não o cofre nativo de uma nuvem só, é o lugar certo para esse controle.
Agente autônomo é um processo com root rodando na sua infra. Contenha o runtime antes de soltá-lo: isolamento por microVM/container, segredo fora do agente (injetado no egress), identidade efêmera e governança cross-nuvem — com as Integrações & APIs Enterprise + Arquitetura Cloud + Security Engineering da CCX. Conheça as soluções da CCX →