A internet completa 57 anos em 2026 e nunca foi tão distribuída — nem tão disputada. Com mais de 300 data centers espalhados por 100 países, a Cloudflare processa hoje uma em cada cinco requisições HTTP do planeta a partir do AS13335, um dos maiores autonomous systems do mundo. Essa capilaridade sustenta uma plataforma que vai muito além de CDN: é nela que rodam workloads de edge computing, pipelines de inteligência artificial, autenticação Zero Trust e filtros de segurança que bloqueiam os maiores ataques DDoS já registrados — o recorde atual ultrapassou 2 Tbps em 2024. É nesse ecossistema que o Cloudflare Access lançamento mais recente se encaixa como peça central de uma transformação que redefine como identidades interagem com APIs de IA, agentes autônomos e sistemas internos. Para profissionais de infraestrutura, SREs, engenheiros de segurança e arquitetos de nuvem que operam ambientes corporativos no Brasil, ignorar essa mudança significa continuar amarrando identidade a um perímetro de rede que já não existe — enquanto o restante do mercado avança para um modelo em que cada chamada de API carrega consigo a prova criptográfica de quem a fez.
A novidade que motiva este artigo é a integração profunda entre o Cloudflare Access — o produto que substitui VPNs por autenticação baseada em identidade — e o AI Gateway, o proxy de observabilidade e controle para APIs de inteligência artificial que suporta OpenAI, Anthropic, HuggingFace, Google AI e qualquer provider compatível. Com essa integração, cada requisição que atravessa o AI Gateway pode ser associada a um cf.user_id verificado via Access, permitindo que times de plataforma estabeleçam limites de gasto por usuário autenticado, filtrem logs por identidade, restrinjam quais gateways cada pessoa pode acessar e construam políticas de roteamento que considerem quem está do outro lado — tudo sem passar um token de usuário explícito na aplicação cliente. É a identidade como serviço de borda, provisionada no edge mais próximo do usuário, com latência mínima e sem depender de backends centralizados.
Mas este Cloudflare Access lançamento não é um ponto isolado no changelog: ele é a peça visível de uma arquitetura maior que a Cloudflare está montando para resolver o problema da governança de agentes. O Agent Access Model, detalhado no blog oficial da empresa, propõe um novo paradigma — task-scoped agents com strict identity brokering, mediação contínua de confiança e trust stateful. Na prática, isso significa que um agente autônomo que consome APIs de IA não ganha um token de acesso permanente ou escopo amplo. Ele recebe credenciais efêmeras, vinculadas a uma tarefa específica, validadas a cada tool call, e com visibilidade total de auditoria. O Cloudflare OS — uma plataforma open-source para construir apps, automatizar fluxos de trabalho e acessar sistemas internos com segurança — materializa esses conceitos ao integrar Workers, Durable Objects, Queues e o próprio Access como runtime para lógica de negócio que roda na rede global da Cloudflare. E o WriteGuard, anunciado em beta privado, adiciona controles granulares para MCP (Model Context Protocol) Servers, garantindo que nem todo funcionário precise configurar perfeitamente cada agente: a plataforma impõe guardrails.
Ao longo deste post, você vai entender o que mudou tecnicamente, como funciona a integração Access + AI Gateway, qual o impacto para empresas brasileiras que operam sob a LGPD, como configurar tudo no Cloudflare Dashboard e por que especialistas em CDN e Zero Trust — como o time da JRT Technology Solutions — estão recomendando essa stack para clientes que precisam de governança real sobre cargas de trabalho de IA. Vamos mergulhar nos detalhes.
O que aconteceu: Access encontra AI Gateway e nasce a identidade na camada de IA
No ecossistema Cloudflare, o Access sempre foi o guardião do perímetro de identidade. Ele substitui a VPN tradicional ao colocar cada aplicação interna atrás de um proxy que exige autenticação federada — Okta, Google Workspace, Azure AD, GitHub, LinkedIn ou qualquer provedor OIDC/SAML. O usuário acessa a URL da aplicação, o Access intercepta a requisição, redireciona para o IdP configurado, valida o token JWT e só então permite que o tráfego chegue ao origem. Tudo isso acontece na borda da Cloudflare, sem abrir túneis na rede corporativa, sem expor portas, sem backdoors. Agora, em agosto de 2026, esse mesmo mecanismo foi estendido ao AI Gateway, o proxy que centraliza chamadas para modelos de linguagem e outros serviços de IA.
O changelog oficial descreve a integração em duas capacidades principais. A primeira é proteger o endpoint do gateway com o Access: você pode colocar qualquer AI Gateway atrás de uma política de Access, definindo exatamente quem — dentre os membros da sua organização ou aplicações de serviço — está autorizado a invocar aquele endpoint. A segunda é o coração da novidade: identity-aware controls, controles cientes de identidade que enriquecem cada requisição com o cf.user_id do usuário autenticado. Esse identificador aparece nos logs, nas análises de uso, nas políticas de roteamento e nos controles de gasto do AI Gateway. Para times que estavam enviando manualmente um user_id da aplicação cliente para tentar rastrear consumo por usuário, essa integração elimina a duplicação, reduz a superfície de inconsistência e impede que um client malicioso forje o identificador.
Simultaneamente, a Cloudflare publicou o Agent Access Model, uma proposta arquitetural que estende a lógica do Access para agentes autônomos. O problema que ele resolve é claro: quando você dá a um agente uma chave de API com escopo amplo, você está essencialmente delegando autoridade sem supervisão contínua. Se o agente decidir, por alucinação ou manipulação de prompt, invocar uma ferramenta indevida ou vazar dados para um endpoint externo, a chave não impede. O Agent Access Model introduz identity brokering: o agente não possui credenciais permanentes; ele solicita acesso via um fluxo OAuth-like mediado pelo Access a cada ação, e a plataforma avalia claims, contexto da tarefa e estado de confiança antes de emitir um token de curta duração. É o conceito de continuous mediation aplicado ao mundo dos agentes.
Essas três peças — Access + AI Gateway, Agent Access Model e WriteGuard para MCP Servers — formam um stack coerente de governança de IA que não depende de inspeção profunda de payload nem de middleboxes corporativos. Tudo opera na borda, com latência de milissegundos, aproveitando a mesma malha anycast que roteia trilhões de requisições por mês.
O que é o Cloudflare Access e como funciona a integração com AI Gateway
Antes de detalhar a configuração, é essencial entender o que o Access é tecnicamente. Diferente de uma VPN que encapsula tráfego de rede e concede acesso amplo à LAN corporativa, o Access é um proxy reverso de aplicação com injeção de autenticação. Ele funciona no layer 7, inspecionando cada requisição HTTP e validando o token JWT antes de encaminhar ao origem. Isso significa que o acesso é por aplicação, por usuário e por sessão — nunca por segmento de rede. O suporte a políticas inclui condições como país de origem, horário, dispositivo (via WARP com posture check) e pertencimento a grupos específicos no IdP. Com a expansão para o AI Gateway, o Access passa a proteger também APIs de inferência, que antes estavam expostas apenas a controles de rede ou a tokens estáticos.
A arquitetura da integração é elegante na sua simplicidade. O AI Gateway já funciona como proxy entre o cliente e o provider de IA — você aponta suas chamadas para https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id} e o Gateway faz caching, logging, rate limiting e observabilidade. Agora, você pode associar esse endpoint a um domínio customizado (por exemplo, ai-gateway.suaempresa.com) e colocar esse domínio atrás de uma Access Application. O fluxo passa a ser: o cliente faz a chamada para o domínio customizado; o Access intercepta, valida o token de sessão ou redireciona para o IdP; uma vez autenticado, o Access injeta o cf.user_id nos metadados da requisição e a encaminha ao AI Gateway; o Gateway, por sua vez, usa esse identificador para aplicar políticas de gasto, filtros de log e roteamento. O cliente original não precisa saber o user_id, não precisa passá-lo no header — a plataforma cuida disso de forma transparente e inviolável.
Para deixar os detalhes técnicos absolutamente claros, a tabela a seguir sintetiza o que essa integração entrega em cada dimensão:
O Cloudflare Access lançamento não adiciona apenas um checkbox de autenticação — ele traz um modelo de autorização contínua que transforma o AI Gateway de um simples proxy de custos em uma plataforma de governança com granularidade de usuário. Isso é especialmente relevante quando falamos de agentes autônomos que consomem tokens de forma imprevisível: o agente de suporte que invoca GPT-4o em loop, o assistente de código que dispara centenas de chamadas ao Claude, o RAG que consulta embeddings e depois chama um LLM para sumarização. Sem controles por identidade, a conta de AI vira uma caixa-preta. Com o Access integrado, cada ação do agente é atribuível a um responsável humano ou a uma service account com escopo limitado.
Por que isso importa: governança de IA, Zero Trust e o fim do token estático
Durante anos, o padrão de segurança para APIs de IA foi o API key estático: uma string alfanumérica que concede acesso total ao endpoint e é compartilhada entre desenvolvedores, hardcoded em repositórios, vazada em logs e frequentemente sem rotação. Mesmo em ambientes corporativos que adotaram cofres de segredos como HashiCorp Vault ou AWS Secrets Manager, o token em si não carrega informação de quem o está usando — apenas de que a chave é válida. Isso torna impossível responder perguntas simples como “quanto o time de marketing gastou com GPT-4o na semana passada?” ou “quem fez essa chamada suspeita ao modelo de embeddings às 3h da manhã?”. A integração Access + AI Gateway resolve isso ao mover o ponto de autenticação para a borda, antes que a requisição chegue ao provider de IA. O token de API do provider — OpenAI, Anthropic, etc. — continua existindo, mas fica armazenado no AI Gateway; os clientes não o veem. Eles se autenticam com o Access, e o Gateway enriquece a chamada com o cf.user_id. O resultado é identidade real em cada log, cada métrica e cada política de spend.
Isso se conecta diretamente ao conceito de Zero Trust que vem sendo implementado em grandes corporações brasileiras. O mercado de SASE/Zero Trust no Brasil deve movimentar mais de R$ 2 bilhões até 2027, impulsionado pela LGPD, pelo aumento do trabalho remoto e pela migração para ambientes multicloud. O Cloudflare Access já é usado por bancos, fintechs, varejistas e indústrias para substituir VPNs legadas — aquelas baseadas em IPsec com appliances que saturam durante o horário de pico. Com essa expansão, o mesmo motor de políticas que protege o ERP, o CRM e os dashboards internos agora pode proteger também as APIs que alimentam agentes de IA. É coerência arquitetural: um único plano de controle de identidade para aplicações tradicionais e workloads de IA.
O impacto financeiro também é substancial. O AI Gateway já oferece caching de respostas: se dois usuários fazem a mesma pergunta ao mesmo modelo, o Gateway serve a resposta em cache, reduzindo a latência e — crucialmente — não gerando custo adicional no provider. Antes, isso era um recurso anônimo; agora, você pode definir políticas de cache que consideram o perfil do usuário, evitando que respostas sensíveis a um VP fiquem em cache para um estagiário. Além disso, os spend limits por cf.user_id permitem que cada departamento ou squad tenha um teto de gastos, prevenindo surpresas no cartão corporativo. Na JRT Technology Solutions, já estamos configurando esse modelo para clientes que usam Workers + AI Gateway + Access para expor assistentes internos com controle de custo granular, sem precisar de um middleware adicional de autorização.
Outro ponto crítico é a observabilidade com identidade. O changelog menciona que o AI Gateway registra o cf.user_id nos logs e o disponibiliza para análises. Combinado com o User Insights (identity-aware AI Gateway em open beta), é possível construir uma linha de base comportamental por usuário e detectar anomalias — como um funcionário que de repente começa a consumir 10x mais tokens ou a enviar prompts em horários incompatíveis com seu padrão. Para empresas que operam com dados sensíveis sob LGPD, essa visibilidade não é luxo: é requisito para demonstrar diligência em caso de auditoria.
Comparativo: Cloudflare vs. alternativas tradicionais de API gateway e VPN
Para entender o posicionamento deste Cloudflare Access lançamento no mercado, é instrutivo compará-lo com outras abordagens. No ecossistema CDN, a Cloudflare compete com Akamai, Fastly e AWS CloudFront — mas nenhum dos três oferece uma plataforma de Zero Trust integrada com a mesma profundidade. A Akamai possui o Enterprise Application Access (EAA), mas ele roda em uma rede separada da CDN, com PoPs distintos, e a integração com APIs de IA é inexistente. A Fastly tem o Compute@Edge, mas não possui proxy de autenticação equivalente ao Access. A AWS tem o API Gateway + Cognito + CloudFront, mas exige que o desenvolvedor costure cada peça manualmente, gerencie rotas, configure WAF separadamente e ainda pague egress fees — que podem chegar a US$ 0,09 por GB na S3, enquanto o ecossistema Cloudflare com R2 tem zero egress fees.
O diferencial da Cloudflare está em três pilares: rede única (a mesma malha anycast que entrega CDN, DDoS mitigation e Zero Trust), runtime na borda (Workers, Durable Objects, AI Gateway executam lógica no mesmo PoP que valida o token JWT do Access) e ecossistema integrado (WARP, Gateway, Browser Isolation, CASB — todos compartilhando o plano de controle de identidade). Quando um cliente autentica via Access, o mesmo token JWT pode ser consumido por um Worker que faz rate limiting, por um Durable Object que mantém estado de sessão, por uma política de Gateway que filtra DNS, e agora pelo AI Gateway que aplica spend controls. Não há latência extra de handshake entre sistemas, porque tudo acontece no mesmo PoP — frequentemente em São Paulo, Rio de Janeiro e Fortaleza, onde a Cloudflare mantém presença robusta.
A tabela abaixo compara as abordagens de forma estruturada:
Em 2026, à medida que agentes de IA se tornam consumidores primários de APIs, a identidade deixa de ser um luxo de segurança e vira pré-requisito de negócio. Times de plataforma precisam de respostas em tempo real sobre quem está gastando o quê, e precisam impor limites sem depender de cada desenvolvedor implementar middleware de autorização no código da aplicação. O Cloudflare Access lançamento entrega exatamente isso: identidade como infraestrutura, provisionada no edge, zero-touch para o desenvolvedor.
Como configurar: protegendo seu AI Gateway com Access em minutos
A configuração da integração entre Access e AI Gateway segue o mesmo fluxo familiar para quem já opera o Cloudflare One. O primeiro passo é ter um AI Gateway provisionado — no Dashboard, em AI > AI Gateway, você cria um gateway e define o provider (OpenAI, Anthropic, HuggingFace, etc.) junto com a API key do provider. O AI Gateway gera um endpoint padrão em gateway.ai.cloudflare.com. Para adicionar o Access, você precisa associar esse gateway a um domínio customizado e, em seguida, criar uma Access Application que protege exatamente esse domínio.
O passo a passo prático é o seguinte:
- Crie o AI Gateway: no Dashboard Cloudflare, vá em AI > AI Gateway, clique em Create Gateway, dê um nome (ex: “corp-gateway”), selecione o provider e insira a API key do provider. Copie o endpoint gerado.
- Configure um domínio customizado: ainda no AI Gateway, adicione um domínio customizado — por exemplo, ai.seudominio.com.br. Isso exige que o domínio esteja no mesmo account Cloudflare e com proxy (laranjinho) ativo. Crie um registro CNAME apontando para o endpoint do gateway.
- Crie a Access Application: vá em Zero Trust > Access > Applications, clique em Add Application, escolha Self-hosted. No campo Application Domain, insira ai.seudominio.com.br. Defina o nome e o ícone.
- Adicione políticas de acesso: na seção de políticas, crie regras que determinam quem pode acessar esse domínio. Exemplo: Allow para emails com domínio @suaempresa.com.br, ou para grupos específicos do Okta como “engenharia” e “data-science”. Você pode combinar condições como país = Brasil, horário = 08:00-20:00, e device posture via WARP.
- Escolha o IdP: selecione o provedor de identidade configurado — Okta, Google Workspace, Azure AD. O Access vai redirecionar usuários não autenticados para a tela de login desse IdP.
- Habilite identity-aware controls: uma vez que a Access Application está ativa e o tráfego
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.