Em um cenário onde 1 a cada 5 requisições HTTP da internet já transita pela rede da Cloudflare, a segurança das aplicações migrou do data center centralizado para a borda da rede. Cloudflare Workers segurança é a resposta da plataforma para a nova geração de ameaças que miram APIs serverless, funções edge e agentes autônomos — tudo isso sem sacrificar latência nem escalabilidade. Desde a fundação em 2009, a Cloudflare transformou seu AS13335 em um dos maiores autonomous systems do planeta, com presença em mais de 300 cidades e 100 países, entregando CDN, WAF, DDoS Protection e Zero Trust de forma integrada. Mas foi com os Workers — o runtime JavaScript, WASM e Python que executa em 275+ pontos de presença com cold start inferior a 1 milissegundo — que a companhia redefiniu o que significa entregar código com segurança no edge.
O mercado de edge computing em 2026 está mais competitivo do que nunca. Soluções como AWS Lambda@Edge, Azure Functions Edge e Fastly Compute@Edge disputam cada milissegundo de latência com a Cloudflare. A diferença decisiva, contudo, está no modelo de isolamento: enquanto muitos provedores dependem de microVMs ou containers tradicionais, a Cloudflare aposta em V8 Isolates — o mesmo motor do Chrome — para sandboxar cada Worker individualmente. Isso significa que milhares de aplicações de clientes diferentes podem coexistir no mesmo processo do servidor sem que uma interfira na outra, com custo de inicialização próximo de zero e superfície de ataque drasticamente reduzida. Para profissionais de TI e engenheiros de segurança no Brasil, onde a LGPD impõe rigor crescente sobre onde e como os dados são processados, esse modelo oferece uma vantagem dupla: conformidade regional e proteção ativa contra exploração de vulnerabilidades.
As últimas semanas trouxeram uma série de anúncios que ampliam ainda mais a superfície de segurança dos Workers. A Agents SDK ganhou suporte a Browser Run com protocolo Chrome DevTools, execução de código via Codemode com aprovações duráveis, delegação de ferramentas entre subagentes e recuperação automática de falhas em WebSockets. Paralelamente, o Cloudflare One Stack introduziu agentes alimentados por IA que planejam e gerenciam ambientes Zero Trust completos, enquanto o time de segurança da empresa publicou a arquitetura de um harness de descoberta de vulnerabilidades multiestágio com triagem automatizada por LLMs. Todos esses lançamentos convergem para um ponto central: segurança na borda não é mais um complemento — é a fundação da plataforma. Neste post, vamos dissecar como a Cloudflare Workers segurança opera na prática, quais camadas de proteção estão disponíveis em 2026 e como times de infraestrutura podem implementar essas defesas em minutos.
Ao longo deste artigo técnico, você encontrará detalhes sobre o modelo de isolamento V8, integração nativa com WAF e DDoS, o novo pipeline de aprovações de agentes, hardenização de fontes via Cloudflare Fonts, visibilidade de postura de email com DMARC Management e as manutenções programadas que afetam a plataforma Workers. Nosso objetivo é fornecer um guia denso — mais de 2.500 palavras de análise — para que engenheiros de infraestrutura, SREs e CISOs possam tomar decisões informadas. Na JRT Technology Solutions, configuramos ambientes Cloudflare para clientes corporativos integrando exatamente essas camadas: CDN, WAF, Zero Trust e Workers com segurança reforçada. Vamos aos fundamentos.
O modelo de isolamento V8 Isolates: a base da Cloudflare Workers segurança
Para entender a Cloudflare Workers segurança, é preciso começar pelo runtime. Diferentemente de plataformas que usam containers Linux ou microVMs (como Firecracker, no caso da AWS), a Cloudflare executa cada Worker dentro de um V8 Isolate. Um Isolate é uma instância isolada do motor JavaScript V8 — o mesmo que roda no Google Chrome e no Node.js — que opera dentro de um único processo do sistema operacional, mas com limites de memória, CPU e acesso ao filesystem rigidamente controlados. Na prática, milhares de Workers de clientes diferentes podem compartilhar o mesmo processo sem jamais enxergar as variáveis, o estado ou as requisições uns dos outros. O resultado é um sandbox de nível de processo com latência de inicialização inferior a 1 milissegundo, o que torna viável executar funções de segurança — como validação de tokens JWT, inspeção de payloads e bloqueio de padrões maliciosos — no caminho quente de cada requisição HTTP.
O mecanismo de isolamento do V8 vai além do namespace de JavaScript. Cada Isolate possui seu próprio heap de memória, garbage collector e contexto de execução. Isso significa que vulnerabilidades clássicas de escape de sandbox — como as que afetam runtimes baseados em processos fork ou em containers compartilhados — são extremamente difíceis de explorar no modelo da Cloudflare. Em 2024 e 2025, pesquisas independentes demonstraram que o overhead de segurança dos Isolates é ordens de grandeza menor do que o de hypervisors tradicionais, viabilizando densidades de milhões de Workers por servidor. Para times de segurança, isso se traduz em uma superfície de ataque mínima: não há kernel compartilhado entre tenants, não há images de container para manter patchadas e não há risco de breakout via /proc ou /sys expostos.
A Cloudflare também implementa Spectre e Meltdown mitigations em nível de V8, utilizando técnicas como site isolation e out-of-process iframes adaptadas ao contexto de servidor. Além disso, todo o runtime é compilado com flags de segurança reforçada (stack canaries, PIE, RELRO) e executado em um sistema operacional mínimo e imutável baseado em Linux, sem shell, sem gerenciadores de pacotes e sem binários desnecessários. Esse princípio de least privilege é levado ao extremo: um Worker não pode fazer syscalls arbitrárias, acessar a rede de forma irrestrita ou persistir dados localmente sem usar as APIs de storage da plataforma (KV, R2, D1, Durable Objects). Cada uma dessas APIs, por sua vez, passa por uma camada de autorização que verifica o escopo do token e o namespace do cliente.
Em 2026, com a ascensão de agentes autônomos baseados em LLMs — como os construídos com a Agents SDK e o Think — a necessidade de isolamento forte se torna ainda mais crítica. Um agente que executa código gerado por IA para interagir com sistemas externos precisa ter garantias de que não conseguirá vazar dados entre sessões, escalar privilégios ou comprometer o ambiente de execução. O modelo V8 Isolates, combinado com o novo sistema de aprovações duráveis do Codemode, cria uma jaula de segurança onde cada ação do agente passa por approval gates antes de ser executada — tema que exploraremos mais adiante.
Agents SDK, Browser Run e Codemode: segurança para agentes autônomos na borda
O dia 18 de junho de 2026 marcou o lançamento de uma série de melhorias na Agents SDK que alteram profundamente o panorama de segurança para cargas de trabalho autônomas. A primeira grande novidade é o Browser Run: uma ferramenta durável que permite a agentes interagir com navegadores reais utilizando o Chrome DevTools Protocol (CDP). Em vez de oferecer uma lista fixa de ações pré-programadas, o modelo de IA escreve código contra o CDP para inspecionar páginas, capturar screenshots, ler conteúdo renderizado, depurar comportamento de frontend e interagir com sessões de browser ao vivo. Do ponto de vista de segurança, isso é revolucionário porque o browser é executado em um sandbox gerenciado pela Cloudflare — não no dispositivo do usuário — com gravação opcional de sessão, Live View URLs para auditoria e controle fino sobre cookies e abas.
As sessões de browser podem ser one-time, reutilizadas ou promovidas de one-time para persistentes durante uma execução. Isso resolve um dos maiores desafios de segurança em automação: cenários onde um agente precisa que um humano faça login, complete MFA ou aprove uma ação sensível. A execução pode pausar, manter as mesmas abas e cookies e retomar após a aprovação — tudo registrado no log durável de execução. Ferramentas como browser_markdown, browser_extract, browser_links e browser_scrape permitem tarefas de browsing one-shot que minimizam o tempo de exposição da sessão.
O segundo pilar de segurança da atualização é o Codemode, agora equipado com createCodemodeRuntime, conectores e um log de execução durável. Em vez de expor um prompt gigante com dezenas de definições de ferramentas, o modelo recebe uma única ferramenta codemode e descobre as capacidades necessárias escrevendo código contra globais tipados. Quando o código atinge uma ação que requer aprovação — como criar uma issue no GitHub, atualizar um sistema externo ou executar um comando com efeitos colaterais — o runtime pausa a execução e retorna uma pending approval. Após a aprovação, as chamadas concluídas são reproduzidas do log durável, a ação aprovada é executada e o mesmo código continua de onde parou. Esse modelo elimina a necessidade de lógica customizada de pause-and-resume para cada ferramenta e, crucialmente, impede que agentes autônomos executem side effects sem supervisão humana.
A delegação de ferramentas entre subagentes também foi reforçada. Agentes Think agora podem usar ferramentas definidas pelo cliente através do caminho RPC chat(). Um agente pai pode passar esquemas de ferramentas com clientTools e resolver chamadas via onClientToolCall, permitindo que agentes delegados usem capacidades fornecidas pelo chamador sem exigir WebSocket de browser. Na prática, isso significa que um agente de orquestração pode delegar uma tarefa de pesquisa a um subagente e controlar exatamente quais APIs externas esse subagente pode acessar — um modelo de least privilege aplicado à colaboração entre agentes de IA.
Cloudflare Workers segurança: integração nativa com WAF e DDoS Protection
Um Worker, por si só, herda toda a pilha de segurança da Cloudflare. Isso significa que antes mesmo de o código do Worker ser invocado, a requisição já passou pelo DDoS Protection automático L3/4/7 — o mesmo que mitigou ataques de mais de 2 Tbps em 2024 — e pelo Web Application Firewall (WAF) com regras gerenciadas contra OWASP Top 10, incluindo SQLi, XSS, SSRF, LFI e RFI. O WAF opera em nível de requisição HTTP, inspecionando URI, headers, body e query strings com regras atualizadas constantemente contra CVEs recém-publicadas. Para times que implementam Cloudflare Workers segurança, essa integração significa que um Worker de API nunca recebe payloads maliciosos que já seriam bloqueados pelas camadas inferiores — reduzindo drasticamente a superfície de ataque da aplicação.
Além das regras gerenciadas, a Cloudflare oferece Custom Rules e Rate Limiting que podem ser configuradas para proteger endpoints específicos servidos por Workers. Por exemplo, uma API de autenticação implementada como Worker pode ter um rate limit de 5 tentativas por minuto por IP, enquanto um endpoint de upload pode ter regras de WAF que inspecionam o Content-Type e o tamanho do payload. Todas essas regras são avaliadas na borda, antes de a requisição consumir recursos do Worker — o que também contribui para a otimização de custos, já que Workers são cobrados por execução e tempo de CPU.
O Bot Management com machine learning e fingerprinting também se aplica automaticamente aos Workers. Bots legítimos, como Googlebot e Bingbot, são identificados e podem ser tratados de forma diferenciada — por exemplo, recebendo conteúdo cacheado ou sendo redirecionados para uma versão pré-renderizada. Já bots maliciosos, como scrapers, credential stuffers e scanners de vulnerabilidades, são bloqueados ou desafiados com Turnstile, a alternativa privacy-first ao reCAPTCHA que não exige interação do usuário. Para Workers voltados a e-commerce e serviços financeiros — setores fortemente visados por ataques automatizados — essa camada adicional de defesa reduz drasticamente o volume de tráfego indesejado que chega ao código de negócio.
A tabela a seguir resume as camadas de segurança que atuam antes, durante e depois da execução de um Worker:
Como configurar a proteção de segurança para Workers no Cloudflare Dashboard
Implementar a Cloudflare Workers segurança no dashboard é um processo que leva menos de 15 minutos para a configuração inicial. O primeiro passo é acessar o painel Security > WAF e verificar se as Managed Rules estão ativadas para o domínio onde o Worker será publicado. Recomendamos manter o conjunto Cloudflare Managed Ruleset com ação Block para todas as regras de criticidade alta e Log para as de criticidade média e baixa durante a primeira semana — isso permite observar falsos positivos antes de ativar o bloqueio completo. Para Workers que servem APIs REST ou GraphQL, é fundamental criar uma Custom Rule que inspecione o header Content-Type e bloqueie requisições com tipos inesperados (por exemplo, application/x-www-form-urlencoded em uma API que só aceita JSON).
Em seguida, acesse Security > Bots e ative o Bot Fight Mode — a versão gratuita já bloqueia uma parcela significativa de bots maliciosos. Para clientes nos planos Pro ($20/mês) ou Business ($200/mês), o Bot Management completo oferece o Bot Score, um valor de 0 a 100 que classifica cada requisição. No código do Worker, você pode acessar esse score via header CF-Bot-Score e tomar decisões programáticas — por exemplo, exigir Turnstile para scores abaixo de 30 ou retornar um 403 Forbidden para scores abaixo de 10. Na JRT Technology Solutions, configuramos thresholds personalizados baseados no perfil de tráfego de cada cliente, reduzindo falsos positivos para bots legítimos como Googlebot e Bingbot.
O terceiro passo é a configuração de Rate Limiting no painel Security > Rate Limiting. Crie uma regra com o padrão de URL do Worker (por exemplo, /api/v1/*) e defina o limite adequado ao endpoint. Para endpoints de autenticação, sugerimos entre 5 e 10 requisições por minuto por IP; para APIs de consulta, entre 60 e 120 requisições por minuto. A ação pode ser Block, JS Challenge ou Managed Challenge (que usa Turnstile). A Cloudflare recomenda usar Managed Challenge como primeira ação, pois ele bloqueia a maioria dos bots sem impactar usuários humanos.
Para agentes construídos com a Agents SDK, a configuração de segurança vai além do dashboard e entra no código. O Codemode exige que você defina conectores e um executor — por exemplo, DynamicWorkerExecutor com um loader — e que implemente os approval gates. No código do Worker, isso se traduz em algo como:
- Importar
createCodemodeRuntimee conectores comoGithubConnector - Configurar o
DynamicWorkerExecutorcom o loader apropriado - Chamar
streamTextcom a ferramentacodemode: runtime.tool() - Tratar o retorno de
pending approvalpausando a execução e notificando um humano - Após aprovação, reproduzir as chamadas do log durável e continuar a execução
Esse modelo garante que nenhum agente autônomo execute ações com side effects — como criar issues, atualizar PRs ou modificar configurações de infraestrutura — sem supervisão. Para ambientes de produção, a JRT Technology Solutions recomenda combinar os approval gates do Codemode com Durable Objects para manter o estado de aprovação consistente mesmo em cenários de evicção de memória ou deploys.
Cloudflare Workers segurança e o ecossistema de Zero Trust
A segurança dos Workers não vive isolada. Em 2026, a Cloudflare consolidou sua plataforma Cloudflare One como uma stack completa de SASE e Zero Trust, e os Workers são cidadãos de primeira classe nesse ecossistema. O Access — substituto de VPNs legadas — permite que você restrinja o acesso a Workers específicos com base em identidade, usando provedores como Okta, Google Workspace, Azure AD ou GitHub. Imagine um Worker que serve um dashboard administrativo ou uma API interna: com uma regra de Access, apenas usuários autenticados com um token JWT válido e pertencentes a um grupo específico no IdP conseguem sequer alcançar o Worker. Todo o tráfego não autenticado é bloqueado na borda, antes de consumir ciclos de CPU.
O Gateway — filtro de DNS e HTTP — adiciona outra camada: ele bloqueia domínios maliciosos antes mesmo da resolução DNS, usando feeds de threat intelligence atualizados em tempo real. Para Workers que fazem chamadas de saída (fetch para APIs externas), o Gateway pode inspecionar e bloquear conexões para destinos categorizados como phishing, malware, botnet C2 ou newly seen domains. Essa proteção é especialmente relevante para agentes autônomos que navegam na web via Browser Run — o Gateway atua como um secure web gateway que impede que o agente acesse domínios comprometidos.
A integração com Browser Isolation é outro ponto de destaque. Quando um Worker ou agente solicita uma página web, a Cloudflare pode executar o navegador em um sandbox remoto e enviar apenas o resultado renderizado para o Worker — efetivamente isolando qualquer código JavaScript malicioso que estivesse na página de destino. Isso fecha um vetor de ataque comum em automação: a execução de scripts de terceiros que poderiam tentar explorar vulnerabilidades no cliente HTTP do Worker.
Para empresas brasileiras que precisam atender à LGPD, o ecossistema Zero Trust da Cloudflare oferece controles de residência de dados. Com Data Localization Suite, é possível configurar que os logs de segurança, metadados de requisição e dados de inspeção permaneçam em data centers localizados no Brasil ou em jurisdições aprovadas. Isso vale tanto para Workers quanto para Gateway, Access e CASB. A JRT Technology Solutions auxilia clientes a mapear os fluxos de dados e configurar as políticas de residência diretamente no dashboard, garantindo que a arquitetura atenda aos requisitos da autoridade nacional de proteção de dados.
Observabilidade de segurança: Workers AI, Radar e logs em tempo real
A segurança só é efetiva quando é observável. A Cloudflare oferece analytics sem sampling para Workers, o que significa que cada requisição — incluindo as bloqueadas pelo WAF, DDoS ou Rate Limiting — é registrada e pode ser consultada. No painel Analytics > Workers, você encontra métricas de invocações, duração de CPU, erros e status HTTP, com drill-down por rota e por código de resposta. Para times de segurança, o mais relevante é o Security Analytics, que exibe eventos de WAF, Bot Management e Rate Limiting com filtros por IP, ASN, país, regra disparada e ação tomada.
A Cloudflare também atualizou recentemente a métrica de popularidade do Workers AI no Cloudflare Radar. A partir de junho de 2026, a popularidade deixou de ser baseada no número de contas únicas executando inferências e passou a refletir o número total de inferências, oferecendo uma visão mais representativa do volume real de uso. Para engenheiros de segurança, essa mudança é valiosa porque permite identificar quais modelos — Llama, Mistral, Whisper, BERT, Stable Diffusion — estão sendo mais visados por atacantes que tentam abusar de APIs de IA. Os endpoints /ai/inference/summary/{dimension} e /ai/inference/timeseries_groups/{dimension} da API do Radar expõem esses dados para monitoramento automatizado.
Outra frente importante de observabilidade é o streaming de logs. A Cloudflare suporta envio em tempo real de logs de Workers, WAF e acesso para destinos como R2, S3, Splunk, Datadog e BigQuery. Para times que operam SOC 24/7, a recomendação é configurar o streaming para um SIEM e criar alertas baseados em thresholds: por exemplo, notificar o time se o número de requisições bloqueadas pelo WAF exceder 100 por minuto em um único Worker, ou se a taxa de erros 500 subir acima de 5% em uma janela de 5 minutos. A
Sua empresa ainda não usa Cloudflare de forma estratégica?
A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, segurança e escalabilidade.