A maioria das estruturas de agentes hoje assume um desktop. Um usuário, uma máquina, um processo. O agente roda enquanto o laptop está aberto, escreve em um sistema de arquivos local, guarda chaves de API em variáveis de ambiente e morre quando o terminal é fechado. Quando algo quebra, o usuário tenta novamente. Quando o agente precisa de um pacote, o pip install o coloca dentro do Python do usuário. Estado, segredos e ciclo de vida residem todos dentro de um único limite confiável.
A infraestrutura de agentes em nuvem não tem nenhum desses luxos.
O agente roda em uma sandbox que inicializa do zero, em hardware compartilhado com estranhos, acionado por chamadores que o usuário nunca conhece: um cronograma, uma requisição HTTP, outro agente. O usuário geralmente está dormindo quando a execução acontece. O código dentro da sandbox pode ser adversarial. O sistema de arquivos precisa sobreviver a implantações. As credenciais não podem viver onde o agente vive. Toda garantia que o desktop oferece de graça — persistência, identidade, confiança de rede, nova tentativa — tem que ser reconstruída como um sistema explícito.
Passamos os últimos meses apertando essa camada na CREAO. Duas lições surgiram disso. Se você já enviou um agente de desktop e se perguntou o que muda quando ele se move para a nuvem, isso é o que muda.
Lição 1: Separe o que muda lentamente do que muda rapidamente
Em um desktop, o ambiente do usuário e o runtime do agente são a mesma coisa, atualizados no mesmo ritmo, pela mesma pessoa. Na nuvem, não são.
Um aplicativo agente acumula estado no lado da plataforma. Um analista de ações instala o matplotlib, baixa dados de mercado, escreve scripts de gráficos. Esse ambiente é a memória muscular do agente. Nós o congelamos em um snapshot da sandbox no momento em que o usuário está satisfeito, e mantemos esse snapshot congelado até que o usuário edite o ambiente novamente. Toda execução inicializa a partir da mesma imagem. Mesmos pacotes, mesmos arquivos, mesmas versões. A execução de segunda-feira se comporta como a de sexta-feira, porque nada abaixo mudou.
Essa é a propriedade que as estruturas de desktop não podem lhe dar de graça. Um pip install de seis meses atrás resolve para versões diferentes hoje. Um snapshot da nuvem resolve para os mesmos bytes para sempre. A reprodutibilidade é algo que a plataforma deve ao usuário, e um snapshot congelado é a maneira mais barata de entregá-la.
Então o problema de acoplamento aparece.
A mesma imagem que congela o ambiente do usuário também contém o código do runner — a pequena biblioteca harness que desenvolvemos e que gerencia o agente a cada execução. O usuário quer que seu ambiente permaneça parado. Nós queremos que nosso runner seja implantado muitas vezes ao dia. Um artefato, dois requisitos opostos.
Nossa primeira correção foi direta. Na inicialização, verificar se o runner dentro do snapshot corresponde à versão que acabamos de implantar. Se não corresponder, descartar o snapshot e inicializar a partir de um template limpo. Funcionou e ninguém reclamou. O dano só atingia a primeira execução após uma implantação.
Execuções não supervisionadas acabaram com essa cobertura. Um cron job às 9h de segunda-feira não deveria perder seu ambiente porque implantamos às 8h55. O contrato que estávamos violando silenciosamente — "seu ambiente está congelado até você alterá-lo" — foi quebrado.
A correção demorou mais do que deveria para enxergarmos. O ambiente do usuário e o código do runner mudam em ritmos completamente diferentes. O usuário edita seu agente quando quer. Nós implantamos a plataforma muitas vezes ao dia. Tratá-los como um único artefato forçava uma escolha a cada implantação: manter código do runner desatualizado ou destruir o ambiente congelado que o usuário pediu explicitamente para preservarmos.
O modelo em que chegamos se inspira em como os sistemas operacionais lidam com atualizações. O kernel muda. Seu diretório home não muda. Você não formata o disco para instalar um patch de segurança.
Traçamos o mesmo limite. A sandbox inicializa a partir do snapshot congelado do usuário, intocado. Em seguida, trocamos a quente apenas o runner. A sequência:
- Colocar o novo runner em um diretório temporário dentro da sandbox.
- Validá-lo com node --check para que qualquer erro de sintaxe seja capturado antes de tocarmos algo ativo.
- Trocar atomicamente: desbloquear o flag imutável do runner antigo, copiar o novo, religar com chattr +i, depois esconder o próprio binário chattr para que o código da sandbox não possa reverter o bloqueio.
- Limpar o cache de compilação do V8 (/home/user/.cache/v8-compile-cache/*) para que o novo arquivo realmente carregue em vez de executar bytecode desatualizado.
- Se algum passo falhar, matar a sandbox e tentar novamente com uma nova. Nenhum estado parcialmente atualizado jamais executa um agente.
A troca inteira leva cerca de 300 milissegundos. Refazemos o snapshot após uma execução bem-sucedida apenas quando o código do runner foi trocado, incorporando o código atualizado na imagem do usuário para que a próxima execução pule a troca completamente. Implantações da plataforma nunca descartam o estado do usuário; elas incorporam o novo runner a ele. Os pacotes, arquivos e personalizações do usuário seguem adiante inalterados.
Se você levar uma coisa dessa lição, é a pergunta diagnóstica. Para qualquer coisa que você persista em uma plataforma de nuvem, pergunte: quem controla o ritmo de mudança desse artefato? Se o usuário e a plataforma possuem ambos, você acabará pagando pelo acoplamento. Divida o artefato ao longo da fronteira de propriedade e deixe cada lado atualizar em seu próprio relógio.
Lição 2: Mantenha segredos fora do limite de execução
Esta é a lição que separa a infraestrutura de agentes em nuvem de todo o resto.
Um agente de desktop executa como o usuário. Ele usa as chaves do usuário, na máquina do usuário, contra a rede do usuário. Um agente de nuvem executa como ninguém, em hardware compartilhado, contra a internet aberta, executando código que um LLM escreveu a partir de um prompt que pode ter sido adversarial. O modelo de segurança tem que assumir que o código dentro da sandbox já está comprometido, não torcer para que não esteja.
A regra que mantemos é simples. Nenhuma credencial de longa duração jamais vive dentro da sandbox.
Quando um agente precisa chamar um serviço autenticado — Slack, GitHub, a própria API do usuário — ele não guarda o token. Ele envia uma requisição HTTP local para uma bridge de API executando fora da sandbox. A bridge anexa o token OAuth do lado do host e encaminha a chamada. A resposta volta sem que o token entre na memória ou ambiente da sandbox.
A parte interessante é como a bridge sabe que a sandbox tem permissão para perguntar. Duas verificações, em camadas propositais.
Primeiro, lista de permissão de IP. A bridge só aceita conexões da faixa de rede interna onde nossos hosts de sandbox residem. Uma chamada de qualquer outro lugar — um laptop de desenvolvedor, uma URL vazada, a internet pública — é descartada na camada de rede antes que qualquer código de aplicação execute. Isso prende a bridge a uma única peça de infraestrutura física e a torna inútil para qualquer pessoa fora dela.
Segundo, um JWT de curta duração cunhado por execução. Quando uma sandbox inicializa, a plataforma assina um token com escopo para essa execução específica: qual usuário, qual aplicativo, qual sessão, com uma expiração que cobre a janela de execução e nada mais. A sandbox o apresenta em toda chamada à bridge. A bridge verifica a assinatura, checa a expiração, e só então resolve as credenciais armazenadas do usuário e as anexa no lado do servidor. Se uma sandbox for sequestrada, o atacante herda um token que morre com a execução e só autoriza chamadas com escopo para aquela única sessão. Não há uma credencial mestre para roubar.
A mesma bridge carrega deduções de faturamento, logs e métricas para fora, então é a única interface que cruza o limite da sandbox em qualquer direção. Todo o resto dentro da sandbox é tratado como comprometido por padrão.
Se uma injeção de prompt convencer um agente a despejar process.env em um webhook amanhã, o atacante obtém um JWT de curta duração que só funciona de dentro de nossa rede e expira com a execução. Essa propriedade é o que nos permite executar código de usuário não confiável em hardware compartilhado sem perder o sono.
O padrão subjacente
Infraestrutura de agente em nuvem confiável e segura não é um sistema novo. São algumas propriedades mantidas sem exceção:
- O estado vive na sandbox, congelado até que o usuário o altere.
- O código é substituível a quente, independente do estado.
- As credenciais vivem no lado do host, nunca dentro do agente.
- Um único pipeline de execução atende a todos os chamadores, seja o gatilho um humano, um cronograma ou outro software.
Essa última propriedade é a conclusão de todo o design. Uma única função executeAgent lida com cliques na UI, execuções agendadas e chamadas de API. O sistema de faturamento, os logs de dedução de crédito, os sinais de observabilidade — todos idênticos, independentemente de um humano ter clicado em Executar, um cron ter disparado ou um script ter chamado a API. Adicionar uma nova superfície de gatilho é uma mudança de roteamento, não uma mudança de arquitetura. O agente em si não sabe nem se importa quem puxou o gatilho.
Isso é o que as estruturas de desktop não podem lhe dar, e o que torna a versão em nuvem digna de ser construída. Um agente em um laptop está vinculado ao laptop. Um agente na nuvem é uma função que o restante de sua stack pode chamar. O usuário o escreve uma vez. A plataforma o faz sobreviver a implantações, executar com segurança em hardware compartilhado e aceitar chamadores que o usuário nunca previu.
Um agente é uma função com uma interface de linguagem natural. Sua implementação pertence ao usuário. Sua superfície de gatilho, seu runtime, seu limite de segurança pertencem à plataforma. A disciplina é construir as camadas para que cada uma evolua em seu próprio relógio, e gastar o tempo encontrando as fissuras entre sistemas antes que outra pessoa o faça.
Isso é o que torna a próxima superfície barata de enviar e segura de enviar.
