Sandboxing para agentes de IA ficou 100 vezes mais rápido com a nova aposta da Cloudflare
A Inteligência Artificial chegou em um ponto onde os agentes não apenas pensam, mas também escrevem e executam código em tempo real. Isso muda tudo, mas traz uma pergunta que ninguém pode ignorar: onde esse código roda de forma segura?
A resposta mais comum hoje são os containers, mas eles têm um problema sério de performance e custo que começa a incomodar quando a escala aumenta. Centenas de milissegundos para inicializar e centenas de megabytes de memória para funcionar acabam criando um gargalo real em ambientes de produção que lidam com múltiplos agentes simultaneamente.
A Cloudflare entrou nessa conversa com uma solução que vai bem além do que o mercado estava acostumado a ver, e o resultado é impressionante: um ambiente de sandboxing que pode ser até 100 vezes mais rápido do que as abordagens tradicionais baseadas em containers. 🚀
Neste artigo, você vai entender como o Dynamic Worker Loader funciona, por que o TypeScript se tornou a linguagem favorita dos agentes de IA para esse tipo de tarefa, quais bibliotecas auxiliares acompanham o ecossistema, como empresas já estão usando essa tecnologia e o que tudo isso significa na prática para quem está construindo produtos com código gerado por IA hoje.
O problema que ninguém queria admitir
Durante muito tempo, a indústria de tecnologia tratou a execução de código gerado por Inteligência Artificial como um detalhe de implementação, algo que viria depois, quando o modelo estivesse bom o suficiente. O que aconteceu foi o contrário: os modelos ficaram muito bons muito rápido, e a infraestrutura para rodar esse código com segurança ficou para trás. Hoje, qualquer agente de IA minimamente capaz consegue escrever um script funcional em segundos, mas colocar esse script para rodar em produção sem criar um risco de segurança ainda é um desafio real para a maioria das empresas.
Simplesmente usar um eval() no código gerado pela IA diretamente na aplicação está fora de questão. Um usuário mal-intencionado poderia facilmente induzir o modelo a injetar vulnerabilidades no código. É por isso que o conceito de sandbox é tão central: um lugar isolado para executar código, completamente separado da aplicação principal e do resto do mundo, exceto pelas capacidades específicas que o código precisa acessar.
Os containers Docker surgiram como a resposta padrão para esse problema, e por boas razões: eles isolam o ambiente, controlam os recursos e oferecem uma camada de segurança razoável. O problema é que containers precisam de tempo para inicializar, consomem memória considerável mesmo quando ociosos, e quando você está lidando com dezenas ou centenas de execuções simultâneas de código gerado por IA, o custo operacional escala de forma assustadora. A própria Cloudflare reconhece esse cenário ao oferecer seu container runtime e seu Sandbox SDK, mas também aponta que, para agentes em escala de consumidor, onde cada usuário final pode ter um ou vários agentes e cada agente escreve código, containers simplesmente não são suficientes.
Existe também uma questão mais sutil que costuma passar despercebida: a latência percebida pelo usuário final. Quando um agente de IA termina de gerar um trecho de código e o sistema precisa esperar alguns segundos para inicializar um container antes de executá-lo, essa espera quebra completamente a sensação de fluidez que torna a experiência com IA tão poderosa. O usuário perde o contexto, a confiança no produto diminui, e a proposta de valor da ferramenta começa a ser questionada. Resolver o sandboxing não é só uma questão técnica, é uma questão de experiência de produto.
De onde veio o Dynamic Worker Loader
A história começa lá em setembro do ano passado, quando a Cloudflare apresentou o conceito de Code Mode: a ideia de que agentes de IA deveriam realizar tarefas não fazendo chamadas de ferramentas individuais, mas sim escrevendo código que chama APIs diretamente. A empresa demonstrou que simplesmente converter um servidor MCP em uma API TypeScript conseguia reduzir o uso de tokens em 81%. Além disso, mostraram que o Code Mode podia operar tanto na frente quanto atrás de um servidor MCP, resultando no novo servidor MCP da Cloudflare que expõe toda a API da empresa com apenas duas ferramentas e menos de 1.000 tokens.
Escondida naquele mesmo anúncio de setembro estava uma funcionalidade experimental: o Dynamic Worker Loader API. Essa API permite que um Cloudflare Worker instancie um novo Worker, em seu próprio sandbox, com código especificado em tempo de execução, tudo dinamicamente. Agora, essa funcionalidade saiu do status experimental e entrou em beta aberto, disponível para todos os usuários pagos do Workers.
Como o Dynamic Worker Loader muda o jogo
O Dynamic Worker Loader é a tecnologia central por trás da solução de sandboxing apresentada pela Cloudflare, e ela funciona de uma forma bastante diferente do que estamos acostumados a ver. Em vez de inicializar um container completo para cada execução, o sistema utiliza Workers isolados que são carregados dinamicamente, aproveitando a infraestrutura distribuída da rede da Cloudflare para criar ambientes de execução extremamente leves e rápidos. Cada Worker roda em seu próprio contexto isolado, sem compartilhar memória ou estado com outros Workers, o que garante o nível de isolamento necessário para execução segura de código gerado por Inteligência Artificial.
A mágica técnica aqui está no mecanismo de isolamento utilizado. Enquanto os containers tradicionais dependem de virtualização no nível do sistema operacional, o modelo dos Dynamic Workers usa isolates, que são instâncias do motor de execução JavaScript V8 da Google, o mesmo que roda no Chrome. Esse é o mesmo mecanismo que sustenta toda a plataforma Cloudflare Workers desde seu lançamento, há oito anos. Cada isolate é essencialmente um contexto V8 separado, com sua própria heap de memória e sem acesso ao ambiente externo, a menos que isso seja explicitamente permitido.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Os números são impressionantes: um isolate leva apenas alguns milissegundos para iniciar e usa apenas alguns megabytes de memória. Isso representa cerca de 100 vezes mais velocidade e entre 10 e 100 vezes mais eficiência de memória do que um container típico. Na prática, isso significa que é perfeitamente viável criar um novo isolate para cada requisição de usuário sob demanda, executar um único trecho de código e descartá-lo em seguida, sem preocupação com custo ou performance.
O fluxo prático funciona assim: o agente de IA gera o código, geralmente em TypeScript ou JavaScript, esse código é enviado para o sistema de sandboxing, o Dynamic Worker Loader cria um contexto isolado em milissegundos, executa o código dentro desse contexto com as permissões e limites de recursos definidos previamente, retorna o resultado e descarta o Worker. Todo esse ciclo pode acontecer em dezenas de milissegundos, comparado com vários segundos no modelo baseado em containers. Para produtos que dependem de execução de código em tempo real, essa diferença é transformadora. 🔥
Escalabilidade sem limites artificiais
Muitos provedores de sandbox baseados em containers impõem limites globais de sandboxes simultâneos e de taxa de criação de sandboxes. O Dynamic Worker Loader não tem esses limites. Ele não precisa, porque é simplesmente uma API para a mesma tecnologia que sempre sustentou a plataforma da Cloudflare, que sempre permitiu que Workers escalassem de forma transparente para milhões de requisições por segundo.
Quer processar um milhão de requisições por segundo onde cada requisição individual carrega um sandbox Dynamic Worker separado, todos rodando simultaneamente? Sem problema.
Latência zero na comunicação
Os Dynamic Workers de uso único geralmente rodam na mesma máquina, e até na mesma thread, do Worker que os criou. Não há necessidade de se comunicar pelo mundo para encontrar um sandbox aquecido. Os isolates são tão leves que podem simplesmente rodar onde a requisição chegou. Os Dynamic Workers são suportados em cada uma das centenas de localizações da Cloudflare ao redor do mundo.
Por que o TypeScript virou a língua franca dos agentes de IA
Se você acompanha o ecossistema de desenvolvimento nos últimos anos, provavelmente já percebeu que o TypeScript foi gradualmente tomando o espaço que o JavaScript ocupava como linguagem padrão para desenvolvimento web. O que talvez não seja tão óbvio é que esse movimento também se reflete de forma muito clara no comportamento dos agentes de Inteligência Artificial quando o assunto é geração de código.
A Cloudflare é bastante direta sobre isso: tecnicamente, os Workers, incluindo os dinâmicos, suportam Python e WebAssembly, mas para pequenos trechos de código gerados sob demanda por um agente, JavaScript e TypeScript carregam e executam muito mais rápido. E enquanto nós humanos temos preferências fortes sobre linguagens de programação, os agentes de IA não têm. Os LLMs são especialistas em todas as linguagens principais, e seus dados de treinamento em JavaScript são imensos. Além disso, JavaScript, por sua natureza na web, foi projetado para ser executado em sandbox. É a linguagem correta para o trabalho.
A razão para a preferência pelo TypeScript especificamente é mais técnica do que parece. O sistema de tipos do TypeScript oferece uma camada de verificação estática que permite que tanto humanos quanto sistemas automatizados validem a correção de um trecho de código antes mesmo de executá-lo. Quando um agente de IA gera código em Python ou JavaScript puro, erros de tipo só aparecem em tempo de execução, o que significa que o sandboxing precisa lidar com falhas inesperadas de forma reativa. Com TypeScript, uma parte significativa desses problemas pode ser detectada antes que o código chegue ao ambiente de execução isolado.
TypeScript consome menos tokens do que OpenAPI
Se queremos que nosso agente faça algo útil, ele precisa se comunicar com APIs externas. A questão é: como informamos o agente sobre as APIs que ele pode acessar? O MCP define schemas para chamadas de ferramentas simples, mas não para APIs de programação. O OpenAPI oferece uma forma de expressar APIs REST, mas é verboso tanto no schema quanto no código necessário para chamá-lo.
Para APIs expostas a JavaScript, a resposta é uma só: TypeScript. Uma interface TypeScript descrevendo uma API de sala de chat, por exemplo, pode ser expressa de forma concisa em poucas linhas, enquanto a especificação OpenAPI equivalente é tão longa que você precisa rolar a tela para ver tudo. Menos tokens significam menos custo de inferência e melhor compreensão pelo modelo, tanto para agentes quanto para humanos.
O Dynamic Worker Loader facilita a implementação de uma API TypeScript no seu próprio Worker e a passagem dela para o Dynamic Worker como parâmetro de método ou no objeto env. O runtime dos Workers configura automaticamente uma ponte RPC entre o sandbox e o código hospedeiro, para que o agente possa invocar sua API através da fronteira de segurança sem nem perceber que não está usando uma biblioteca local.
Filtragem HTTP e injeção de credenciais
Para quem prefere fornecer APIs HTTP aos agentes, o suporte é completo. Usando a opção globalOutbound da API do worker loader, é possível registrar um callback que será invocado em cada requisição HTTP. Nesse callback, você pode inspecionar a requisição, reescrevê-la, injetar chaves de autenticação, responder diretamente, bloquear ou fazer qualquer outra coisa necessária.
Isso permite implementar injeção de credenciais: quando o agente faz uma requisição HTTP para um serviço que requer autorização, as credenciais são adicionadas automaticamente na saída. Dessa forma, o agente nunca conhece as credenciais secretas e, portanto, não pode vazá-las. Ainda assim, a Cloudflare reforça que, na ausência de um requisito de compatibilidade, interfaces RPC em TypeScript são superiores ao HTTP por exigirem menos tokens, serem mais fáceis de restringir e mais simples de proteger.
Segurança testada em batalha
Proteger um sandbox baseado em isolates não é trivial. Embora todos os mecanismos de sandboxing tenham bugs, falhas de segurança no V8 são mais comuns do que em hypervisors típicos. Quando se usa isolates para fazer sandbox de código potencialmente malicioso, camadas adicionais de defesa em profundidade são fundamentais.
A Cloudflare tem quase uma década de experiência protegendo sua plataforma baseada em isolates. Os sistemas da empresa aplicam patches de segurança do V8 em produção em questão de horas, mais rápido do que o próprio Chrome. A arquitetura de segurança inclui um sandbox de segunda camada customizado com isolamento dinâmico de tenants baseado em avaliações de risco. A empresa estendeu o próprio sandbox do V8 para aproveitar recursos de hardware como MPK, colaborou com pesquisadores para desenvolver defesas inovadoras contra Spectre e conta com sistemas que escaneiam código em busca de padrões maliciosos, bloqueando-os automaticamente ou aplicando camadas adicionais de sandboxing.
Quando você usa Dynamic Workers na Cloudflare, toda essa infraestrutura de segurança vem de graça. 🛡️
Bibliotecas auxiliares que facilitam a vida
A Cloudflare construiu um conjunto de bibliotecas para facilitar o trabalho com Dynamic Workers, e vale a pena conhecer cada uma delas.
Code Mode SDK
O pacote @cloudflare/codemode simplifica a execução de código gerado por modelos de IA contra ferramentas usando Dynamic Workers. No centro está o DynamicWorkerExecutor(), que constrói um sandbox sob medida com normalização de código para lidar com erros de formatação comuns e acesso direto a um fetcher globalOutbound para controlar o comportamento de fetch dentro do sandbox.
O SDK também fornece duas funções utilitárias do lado do servidor: uma que envolve um servidor MCP existente substituindo sua superfície de ferramentas por uma única ferramenta de código, e outra que, dado uma especificação OpenAPI e um executor, constrói um servidor MCP completo com ferramentas de busca e execução, mais adequado para APIs maiores. Em ambos os casos, o código gerado pelo modelo roda dentro de Dynamic Workers.
Bundling com @cloudflare/worker-bundler
Dynamic Workers esperam módulos pré-empacotados. O pacote @cloudflare/worker-bundler resolve isso automaticamente: você fornece arquivos fonte e um package.json, e ele resolve dependências npm do registro, empacota tudo com esbuild e retorna o mapa de módulos que o Worker Loader espera. Ele também suporta aplicações full-stack, empacotando um Worker servidor, JavaScript client-side e assets estáticos juntos, com serviço de assets integrado que lida com content types, ETags e roteamento SPA.
Manipulação de arquivos com @cloudflare/shell
O pacote @cloudflare/shell dá ao seu agente um sistema de arquivos virtual dentro de um Dynamic Worker. O código do agente chama métodos tipados em um objeto state, incluindo leitura, escrita, busca, substituição, diff, glob, consulta e atualização JSON e arquivamento, com entradas e saídas estruturadas em vez de parsing de strings.
O armazenamento é respaldado por um Workspace durável baseado em SQLite e R2, então os arquivos persistem entre execuções. Operações como buscas em múltiplos arquivos e substituições em lote minimizam round-trips de RPC. Escritas em lote são transacionais por padrão: se qualquer escrita falhar, as anteriores são revertidas automaticamente.
Quem já está usando e como
O uso prático do Dynamic Worker Loader já está acontecendo em cenários variados e bastante interessantes.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Code Mode em produção
Desenvolvedores querem que seus agentes escrevam e executem código contra APIs de ferramentas, em vez de fazer chamadas de ferramentas sequenciais uma de cada vez. Com Dynamic Workers, o LLM gera uma única função TypeScript que encadeia múltiplas chamadas de API, executa em um Dynamic Worker e retorna o resultado final de volta ao agente. Apenas o resultado, e não cada passo intermediário, vai para a janela de contexto. Isso reduz tanto a latência quanto o uso de tokens e produz resultados melhores, especialmente quando a superfície de ferramentas é grande.
O próprio servidor MCP da Cloudflare foi construído exatamente dessa forma: ele expõe toda a API da Cloudflare através de apenas duas ferramentas, busca e execução, em menos de 1.000 tokens, porque o agente escreve código contra uma API tipada em vez de navegar por centenas de definições de ferramentas individuais.
Automações customizadas
A Zite, por exemplo, está construindo uma plataforma de aplicativos onde usuários interagem através de uma interface de chat. O LLM escreve TypeScript nos bastidores para construir apps CRUD, conectar a serviços como Stripe, Airtable e Google Calendar e executar lógica de backend, tudo sem que o usuário veja uma linha de código. Cada automação roda em seu próprio Dynamic Worker, com acesso apenas aos serviços e bibliotecas específicos que o endpoint precisa.
Segundo Antony Toron, CTO e cofundador da Zite, a empresa precisava de uma camada de execução que fosse instantânea, isolada e segura, e o Dynamic Workers atingiu os três requisitos, superando todas as outras plataformas que eles avaliaram em velocidade e suporte a bibliotecas. A Zite agora processa milhões de requisições de execução diariamente graças aos Dynamic Workers.
Aplicações geradas por IA
Desenvolvedores também estão construindo plataformas que geram aplicações completas a partir de IA, seja para seus clientes ou para equipes internas construindo protótipos. Com Dynamic Workers, cada app pode ser iniciada sob demanda e depois colocada em cold storage até ser invocada novamente. Tempos de inicialização rápidos facilitam a visualização de mudanças durante o desenvolvimento ativo, e as plataformas podem bloquear ou interceptar qualquer requisição de rede que o código gerado faça.
Quanto custa tudo isso
Os Dynamic Workers são cobrados a US$ 0,002 por Worker único carregado por dia, além do preço habitual de tempo de CPU e invocações dos Workers regulares. Para casos de uso de Code Mode, onde cada Worker é um uso único, isso significa US$ 0,002 por Worker carregado mais CPU e invocações, um custo tipicamente negligenciável comparado aos custos de inferência para gerar o código.
Durante o período de beta, a cobrança de US$ 0,002 está suspensa. Como os preços podem mudar, vale sempre consultar a documentação oficial de pricing dos Dynamic Workers para informações atualizadas.
O que isso significa na prática para quem desenvolve com IA
Falando de forma bem concreta: se você está construindo qualquer produto onde um agente de Inteligência Artificial precisa executar código como parte do seu fluxo de trabalho, seja um assistente de análise de dados, uma ferramenta de automação, um copiloto de desenvolvimento ou qualquer outra aplicação similar, a forma como você resolve o problema de sandboxing vai impactar diretamente a experiência do seu usuário e o custo da sua infraestrutura.
A abordagem do Dynamic Worker Loader abre uma terceira via que antes não existia de forma acessível: sandboxing rápido, seguro e com custo proporcional ao uso real, sem a necessidade de manter uma infraestrutura complexa de containers. Para startups e times pequenos, isso é especialmente relevante porque remove uma barreira técnica significativa que antes exigia engenheiros especializados ou soluções caras de terceiros. Para empresas maiores, o ganho de performance e a redução de custo em escala podem representar uma vantagem competitiva real, principalmente em produtos onde a velocidade de execução de código é parte da proposta de valor central.
É importante também mencionar que essa não é uma solução mágica que resolve todos os problemas de segurança relacionados à execução de código gerado por Inteligência Artificial. O sandboxing resolve o isolamento de execução, mas a validação do código antes da execução, os limites de acesso a recursos externos e a política de o que pode ou não ser executado ainda precisam ser definidos pela equipe que está construindo o produto. O Dynamic Worker Loader oferece a infraestrutura, mas a arquitetura de segurança completa ainda depende de decisões de design que vão além da escolha da plataforma de execução. O que muda é que agora a parte mais difícil, o isolamento rápido e confiável, já está resolvida de forma bastante elegante. ⚡
A combinação de TypeScript, sandboxing baseado em isolates V8 e o Dynamic Worker Loader representa uma das evoluções mais práticas e imediatas para quem está construindo com Inteligência Artificial hoje, e vale muito a pena acompanhar como esse ecossistema vai se desenvolver nos próximos meses.
