{"id":2468,"date":"2026-08-25T17:12:52","date_gmt":"2026-08-25T20:12:52","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/25\/cloudflare-access-seguranca-rotacao-de-tokens-e-mcp-em-2026\/"},"modified":"2026-08-25T17:12:52","modified_gmt":"2026-08-25T20:12:52","slug":"cloudflare-access-seguranca-rotacao-de-tokens-e-mcp-em-2026","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/25\/cloudflare-access-seguranca-rotacao-de-tokens-e-mcp-em-2026\/","title":{"rendered":"Cloudflare Access seguran\u00e7a: rota\u00e7\u00e3o de tokens e MCP em 2026"},"content":{"rendered":"

A Cloudflare Access seguran\u00e7a<\/strong> ocupa hoje um papel central na arquitetura Zero Trust de empresas que abandonaram o modelo de VPN legado. Com a rede global da Cloudflare processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP da internet<\/strong> por meio do AS13335<\/strong> \u2014 um dos maiores autonomous systems do planeta, presente em mais de 300 cidades<\/strong> e 100 pa\u00edses<\/strong> \u2014 as decis\u00f5es de seguran\u00e7a tomadas nessa edge t\u00eam impacto imediato sobre aplica\u00e7\u00f5es corporativas, APIs internas, dashboards administrativos e ambientes de desenvolvimento. O ano de 2026 consolidou o Cloudflare Access como pe\u00e7a-chave do portf\u00f3lio Cloudflare One<\/strong>, a plataforma SASE\/Zero Trust que integra CDN, WAF, Gateway, CASB e WARP em um \u00fanico painel de controle.<\/p>\n

O contexto de mercado para profissionais de infraestrutura em 2026 \u00e9 marcado pela converg\u00eancia entre CDN global, edge computing e seguran\u00e7a por identidade<\/strong>. Enquanto Akamai aposta em sua capilaridade hist\u00f3rica de entrega, Fastly se posiciona em edge computing de baixa lat\u00eancia e a AWS CloudFront segue atrelada ao ecossistema IAM da Amazon, o Cloudflare se diferencia por entregar seguran\u00e7a de acesso baseada em identidade<\/strong> diretamente na borda, sem exigir appliances dedicados ou t\u00faneis de rede complexos. Para o mercado brasileiro, onde a LGPD imp\u00f5e controle r\u00edgido sobre quem acessa dados pessoais e a lat\u00eancia at\u00e9 os PoPs de S\u00e3o Paulo e Rio de Janeiro influencia diretamente a experi\u00eancia do usu\u00e1rio, a ado\u00e7\u00e3o de controles granulares de autentica\u00e7\u00e3o deixou de ser opcional.<\/p>\n

O Cloudflare Access nasceu como resposta \u00e0 pergunta que todo CTO se fazia no in\u00edcio da d\u00e9cada: por que expor pain\u00e9is administrativos, reposit\u00f3rios internos e APIs privadas \u00e0 internet p\u00fablica se a identidade do usu\u00e1rio pode ser validada antes de cada requisi\u00e7\u00e3o?<\/strong> Em vez de depender de um t\u00fanel VPN que concede acesso amplo \u00e0 rede interna, o Access valida cada request individualmente, aplicando pol\u00edticas baseadas em identidade, dispositivo, localiza\u00e7\u00e3o e contexto. Isso reduz drasticamente a superf\u00edcie de ataque \u2014 princ\u00edpio essencial do Zero Trust \u2014 e elimina o conhecido “acesso lateral” que torna VPNs tradicionais um vetor perigoso de intrus\u00e3o.<\/p>\n

Neste post t\u00e9cnico, voc\u00ea vai entender os tr\u00eas aprimoramentos de seguran\u00e7a anunciados recentemente para o Cloudflare Access<\/strong>: os per\u00edodos de car\u00eancia na rota\u00e7\u00e3o de service tokens, a capacidade de desativar temporariamente tokens sem apag\u00e1-los e o suporte a portais de servidores MCP alinhados \u00e0 especifica\u00e7\u00e3o MCP 2026-07-28<\/strong>. Tamb\u00e9m vamos detalhar como configurar esses controles no dashboard, comparar o posicionamento do Cloudflare frente a Akamai, Fastly e AWS CloudFront, e analisar o impacto pr\u00e1tico para empresas brasileiras que operam servi\u00e7os na borda. Se voc\u00ea administra aplica\u00e7\u00f5es corporativas, ambientes de CI\/CD ou APIs internas, este \u00e9 o guia de refer\u00eancia para endurecer sua postura de seguran\u00e7a de acesso em 2026.<\/p>\n

O que mudou: tr\u00eas an\u00fancios que fortalecem o Cloudflare Access seguran\u00e7a<\/h3>\n

O m\u00eas de agosto de 2026 trouxe um conjunto de ajustes que, \u00e0 primeira vista, podem parecer incrementais, mas que resolvem dores reais de quem opera servi\u00e7os em produ\u00e7\u00e3o. O primeiro an\u00fancio \u2014 grace periods for service token rotation<\/strong> \u2014 permite que administradores definam uma janela de transi\u00e7\u00e3o em que o segredo antigo e o novo de um service token permanecem v\u00e1lidos simultaneamente. Isso elimina o temido “gap de autentica\u00e7\u00e3o” que ocorria quando um token era rotacionado e servi\u00e7os dependentes ainda n\u00e3o haviam sido atualizados. O segundo an\u00fancio \u2014 temporarily turn off Access service tokens<\/strong> \u2014 introduz a capacidade de suspender um token sem destru\u00ed-lo, preservando sua configura\u00e7\u00e3o para reativa\u00e7\u00e3o futura. O terceiro \u2014 MCP server portals support MCP 2026-07-28 specification<\/strong> \u2014 avan\u00e7a a compatibilidade de portais MCP com o protocolo stateless definido na especifica\u00e7\u00e3o de julho de 2026, mantendo compatibilidade retroativa com clientes Streamable HTTP de 2025.<\/p>\n

Do ponto de vista operacional, esses tr\u00eas an\u00fancios se complementam. A rota\u00e7\u00e3o com grace period<\/strong> \u00e9 a resposta da Cloudflare a um problema cl\u00e1ssico de seguran\u00e7a: a tens\u00e3o entre rotacionar credenciais com frequ\u00eancia<\/strong> (boa pr\u00e1tica) e evitar interrup\u00e7\u00f5es de servi\u00e7o<\/strong> (exig\u00eancia de neg\u00f3cio). Antes, cada rota\u00e7\u00e3o de secret em um service token era um evento all-or-nothing: o segredo antigo expirava imediatamente e qualquer servi\u00e7o que n\u00e3o tivesse sido atualizado a tempo quebrava. Agora, com janelas configur\u00e1veis de 1 hora a 30 dias<\/strong>, o administrador ganha controle fino sobre o processo de migra\u00e7\u00e3o. O dashboard oferece per\u00edodos pr\u00e9-definidos, enquanto a API aceita um timestamp RFC 3339<\/strong> para agendas de rota\u00e7\u00e3o customizadas.<\/p>\n

A desativa\u00e7\u00e3o tempor\u00e1ria de tokens, por sua vez, atende a um cen\u00e1rio que todo SRE reconhece: a suspeita de exposi\u00e7\u00e3o de credenciais. Em vez de deletar o token e reconstru\u00ed-lo do zero \u2014 perdendo hist\u00f3rico, correla\u00e7\u00f5es e configura\u00e7\u00f5es associadas \u2014 o administrador pode simplesmente deslig\u00e1-lo. Um token desativado n\u00e3o consegue autenticar<\/strong>, mas mant\u00e9m sua configura\u00e7\u00e3o \u00edntegra. A funcionalidade tamb\u00e9m interage com o grace period: desligar um token interrompe imediatamente a validade de qualquer segredo anterior ainda em rota\u00e7\u00e3o ativa, o que \u00e9 essencial para conter exposi\u00e7\u00f5es de credenciais em tempo real.<\/p>\n

O suporte a MCP 2026-07-28 posiciona o Cloudflare Access na vanguarda de um ecossistema que cresce rapidamente: o Model Context Protocol<\/strong>. Portais de servidores MCP exp\u00f5em ferramentas e contextos para agentes de IA por meio de endpoints HTTP, e o protocolo stateless da especifica\u00e7\u00e3o de julho de 2026 simplifica a infraestrutura ao eliminar a necessidade de manter sess\u00f5es stateful no portal. O Cloudflare Access atua como camada de autentica\u00e7\u00e3o e proxy para esses portais, garantindo que apenas identidades autorizadas consigam interagir com servidores MCP upstream. A sele\u00e7\u00e3o de protocolo \u00e9 independente para clientes e upstream \u2014 ou seja, um cliente 2025 pode falar com um server 2026 e vice-versa, sem altera\u00e7\u00f5es de configura\u00e7\u00e3o no portal.<\/p>\n

O que \u00e9 o Cloudflare Access e como a seguran\u00e7a por identidade funciona<\/h3>\n

O Cloudflare Access<\/strong> \u00e9 o componente de Zero Trust Network Access (ZTNA)<\/strong> dentro do portf\u00f3lio Cloudflare One. Em vez de construir t\u00faneis de rede que conectam um dispositivo a toda uma sub-rede corporativa, o Access funciona como um proxy de autentica\u00e7\u00e3o na borda<\/strong>: cada requisi\u00e7\u00e3o HTTP\/HTTPS \u00e9 interceptada, validada contra um provedor de identidade configurado (Okta, Google Workspace, Microsoft Entra ID\/Azure AD, entre outros) e somente ent\u00e3o encaminhada ao servidor de origem. Essa mudan\u00e7a de paradigma \u2014 de per\u00edmetro de rede<\/strong> para per\u00edmetro de identidade<\/strong> \u2014 \u00e9 a ess\u00eancia do modelo Zero Trust e a raz\u00e3o pela qual o Access substitui VPNs legadas em milhares de organiza\u00e7\u00f5es.<\/p>\n

Na pr\u00e1tica, a arquitetura do Access se apoia em tr\u00eas pilares. O primeiro \u00e9 a autentica\u00e7\u00e3o federada<\/strong>: o Cloudflare n\u00e3o armazena senhas; ele delega a verifica\u00e7\u00e3o de credenciais ao IdP corporativo e consome o token de identidade resultante (SAML, OIDC). O segundo pilar \u00e9 a pol\u00edtica de acesso contextual<\/strong>, definida no dashboard por regras que consideram e-mail, grupo, dom\u00ednio, pa\u00eds, IP de origem, dispositivo (via WARP com posture check) e hor\u00e1rio. O terceiro pilar \u00e9 o service token<\/strong>: uma credencial de longa dura\u00e7\u00e3o destinada a comunica\u00e7\u00e3o m\u00e1quina-a-m\u00e1quina, usada quando um servi\u00e7o automatizado \u2014 como um runner de CI\/CD, um agente de monitoramento ou uma rotina de backup \u2014 precisa se autenticar sem intera\u00e7\u00e3o humana.<\/p>\n

O modelo de Cloudflare Access seguran\u00e7a<\/strong> \u00e9 particularmente eficaz porque move a decis\u00e3o de autoriza\u00e7\u00e3o para o ponto mais pr\u00f3ximo poss\u00edvel do usu\u00e1rio. Quando um colaborador em S\u00e3o Paulo acessa um dashboard interno hospedado em um data center na Virg\u00ednia, a autentica\u00e7\u00e3o ocorre no PoP da Cloudflare mais pr\u00f3ximo \u2014 GRU (S\u00e3o Paulo)<\/strong>, por exemplo \u2014 sem que o tr\u00e1fego precise cruzar um t\u00fanel centralizado at\u00e9 a sede da empresa. Isso reduz lat\u00eancia e elimina o single point of failure t\u00edpico de concentradores VPN. A rede anycast da Cloudflare garante que a mesma pol\u00edtica de acesso seja aplicada de forma consistente em qualquer um dos mais de 300 PoPs globais.<\/p>\n

Para profissionais de infraestrutura que operam ambientes h\u00edbridos ou multicloud, o Access oferece conectores leves \u2014 cloudflared<\/strong> \u2014 que estabelecem t\u00faneis outbound-only entre a origem e a rede Cloudflare, sem abrir portas de entrada no firewall. Isso significa que servidores internos, bancos de dados privados e APIs legadas podem permanecer totalmente isolados da internet p\u00fablica, acess\u00edveis somente por meio do Access. A combina\u00e7\u00e3o de Cloudflare Tunnel<\/strong> com Cloudflare Access seguran\u00e7a<\/strong> elimina a necessidade de expor portas 22, 3389 ou 443 diretamente, reduzindo drasticamente a superf\u00edcie de ataque.<\/p>\n

A tabela a seguir resume os principais produtos de seguran\u00e7a do ecossistema Cloudflare relevantes para quem implanta ou otimiza uma arquitetura Zero Trust com Access:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Produto Cloudflare<\/th>\nFun\u00e7\u00e3o de seguran\u00e7a<\/th>\nCen\u00e1rio de uso t\u00edpico<\/th>\n<\/tr>\n<\/thead>\n
Cloudflare Access<\/strong><\/td>\nZTNA baseado em identidade, substitui VPN<\/td>\nDashboards internos, APIs privadas, SSH\/Web SSH<\/td>\n<\/tr>\n
Cloudflare Gateway<\/strong><\/td>\nFiltragem de DNS e HTTP, prote\u00e7\u00e3o contra malware<\/td>\nBloqueio de dom\u00ednios maliciosos antes da resolu\u00e7\u00e3o DNS<\/td>\n<\/tr>\n
WARP Client<\/strong><\/td>\nTunneling seguro de dispositivos para a rede Cloudflare<\/td>\nAcesso Zero Trust em endpoints corporativos e BYOD<\/td>\n<\/tr>\n
Cloudflare Tunnel<\/strong><\/td>\nConectividade outbound-only para origens privadas<\/td>\nExposi\u00e7\u00e3o segura de servi\u00e7os internos sem abrir portas<\/td>\n<\/tr>\n
Cloudflare CASB<\/strong><\/td>\nDescoberta de shadow IT e monitoramento de SaaS<\/td>\nAuditoria de Google Workspace, M365 e Slack<\/td>\n<\/tr>\n
Cloudflare WAF<\/strong><\/td>\nProte\u00e7\u00e3o de aplica\u00e7\u00f5es web contra SQLi, XSS, SSRF<\/td>\nDefesa de APIs e aplica\u00e7\u00f5es expostas via Access<\/td>\n<\/tr>\n
Browser Isolation<\/strong><\/td>\nNavega\u00e7\u00e3o em sandbox na rede Cloudflare<\/td>\nAcesso seguro a sites n\u00e3o confi\u00e1veis sem risco ao endpoint<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Rota\u00e7\u00e3o de service tokens com grace period: detalhes t\u00e9cnicos e boas pr\u00e1ticas<\/h3>\n

O an\u00fancio do grace period para rota\u00e7\u00e3o de service tokens<\/strong> merece uma an\u00e1lise t\u00e9cnica aprofundada, pois altera fundamentalmente a forma como administradores de plataforma gerenciam credenciais de servi\u00e7o. Em ess\u00eancia, o mecanismo funciona assim: quando voc\u00ea inicia a rota\u00e7\u00e3o do secret de um service token no dashboard do Cloudflare Access, o sistema passa a emitir dois segredos v\u00e1lidos simultaneamente<\/strong> \u2014 o antigo e o novo \u2014 durante a janela definida. Ambos autenticam com sucesso at\u00e9 que o grace period expire, momento em que o segredo anterior \u00e9 automaticamente revogado. Esse modelo de transi\u00e7\u00e3o \u00e9 conhecido como dual-active key rotation<\/strong> e \u00e9 amplamente recomendado em sistemas de gest\u00e3o de chaves corporativas, como HashiCorp Vault e AWS Secrets Manager.<\/p>\n

No dashboard, o administrador pode escolher entre per\u00edodos pr\u00e9-definidos que v\u00e3o de 1 hora a 30 dias<\/strong>, cobrindo desde migra\u00e7\u00f5es \u00e1geis em ambientes de CI\/CD at\u00e9 rota\u00e7\u00f5es planejadas com semanas de anteced\u00eancia em sistemas legados de dif\u00edcil atualiza\u00e7\u00e3o. Para cen\u00e1rios que exigem precis\u00e3o cir\u00fargica \u2014 como a rota\u00e7\u00e3o sincronizada com uma janela de manuten\u00e7\u00e3o espec\u00edfica \u2014 a API aceita um timestamp RFC 3339<\/strong> no campo de expira\u00e7\u00e3o do segredo anterior, permitindo agendas personalizadas como “expirar o segredo antigo exatamente \u00e0s 23:59:59-03:00 do dia 15 de setembro”<\/em>. Essa flexibilidade \u00e9 essencial para empresas que operam em m\u00faltiplos fusos hor\u00e1rios e precisam coordenar a transi\u00e7\u00e3o com equipes distribu\u00eddas.<\/p>\n

Um aspecto cr\u00edtico do grace period \u00e9 a intera\u00e7\u00e3o com a revoga\u00e7\u00e3o imediata. Mesmo durante a janela de transi\u00e7\u00e3o, o administrador pode revogar o segredo anterior instantaneamente \u2014 uma salvaguarda importante caso a rota\u00e7\u00e3o seja iniciada justamente porque o segredo antigo foi comprometido. A l\u00f3gica \u00e9 intuitiva: se voc\u00ea suspeita que uma credencial vazou, n\u00e3o faz sentido mant\u00ea-la v\u00e1lida por mais 30 dias. O dashboard permite essa revoga\u00e7\u00e3o com um clique, e a mesma opera\u00e7\u00e3o est\u00e1 dispon\u00edvel via API para automa\u00e7\u00e3o em playbooks de resposta a incidentes.<\/p>\n

Do ponto de vista de arquitetura de sistemas, os service tokens do Cloudflare Access s\u00e3o credenciais client credentials<\/strong> \u2014 um Client ID<\/strong> e um Client Secret<\/strong> \u2014 que servi\u00e7os automatizados apresentam no cabe\u00e7alho CF-Access-Client-Id<\/strong> e CF-Access-Client-Secret<\/strong> em requisi\u00e7\u00f5es HTTP. O grace period se aplica ao Client Secret<\/strong>; o Client ID permanece est\u00e1vel durante a rota\u00e7\u00e3o. Isso simplifica a atualiza\u00e7\u00e3o em servi\u00e7os que armazenam credenciais em cofres de segredos: basta substituir o valor do Client Secret, sem alterar identificadores ou pol\u00edticas associadas. Na JRT Technology Solutions, configuramos o Cloudflare para que clientes corporativos mantenham esses segredos em sistemas como Vault ou AWS Secrets Manager, sincronizados por meio de pipelines de CI\/CD que buscam o valor atualizado automaticamente.<\/p>\n

Para quem gerencia dezenas ou centenas de service tokens \u2014 realidade comum em plataformas maduras de microservi\u00e7os \u2014 a ado\u00e7\u00e3o de grace periods deve ser acompanhada de uma pol\u00edtica formal de rota\u00e7\u00e3o. Nossos especialistas em infraestrutura CDN recomendam: (1)<\/strong> definir um ciclo padr\u00e3o de rota\u00e7\u00e3o (por exemplo, 90 dias) para cada token, (2)<\/strong> agendar grace periods de 7 a 14 dias para permitir que todos os servi\u00e7os consumidores sejam atualizados, (3)<\/strong> documentar quais servi\u00e7os dependem de cada token e (4)<\/strong> automatizar a atualiza\u00e7\u00e3o de segredos via API sempre que poss\u00edvel. O dashboard do Cloudflare Access agora facilita o passo 2 com configura\u00e7\u00e3o visual imediata.<\/p>\n

Desativa\u00e7\u00e3o tempor\u00e1ria de tokens: conten\u00e7\u00e3o de incidentes sem perda de configura\u00e7\u00e3o<\/h3>\n

O segundo recurso anunciado \u2014 temporarily turn off Access service tokens<\/strong> \u2014 fecha uma lacuna operacional que se tornava evidente em incidentes de seguran\u00e7a. Tradicionalmente, quando um service token era suspeito de comprometimento, o administrador tinha duas op\u00e7\u00f5es insatisfat\u00f3rias: deletar o token<\/strong> (perdendo todo o hist\u00f3rico e configura\u00e7\u00e3o, exigindo recria\u00e7\u00e3o manual e reconfigura\u00e7\u00e3o de todos os servi\u00e7os dependentes) ou rotacionar o secret<\/strong> (que resolve o comprometimento, mas mant\u00e9m o token ativo durante o grace period se a rota\u00e7\u00e3o for gradual). Nenhuma das op\u00e7\u00f5es permitia uma suspens\u00e3o limpa, revers\u00edvel e imediata da autentica\u00e7\u00e3o.<\/p>\n

Com o novo controle, um token desativado n\u00e3o consegue autenticar<\/strong> \u2014 qualquer requisi\u00e7\u00e3o com suas credenciais ser\u00e1 rejeitada \u2014 mas sua configura\u00e7\u00e3o permanece \u00edntegra no dashboard, incluindo pol\u00edticas associadas, nome, descri\u00e7\u00e3o e hist\u00f3rico de rota\u00e7\u00f5es. O administrador pode reativar o token posteriormente com um clique, restaurando o acesso sem qualquer reconstru\u00e7\u00e3o. Essa capacidade \u00e9 particularmente valiosa em cen\u00e1rios de suspens\u00e3o programada<\/strong>: por exemplo, desativar temporariamente o token de um servi\u00e7o de integra\u00e7\u00e3o durante uma janela de manuten\u00e7\u00e3o, ou pausar o acesso de um agente de monitoramento durante uma migra\u00e7\u00e3o.<\/p>\n

O comportamento de seguran\u00e7a do recurso \u00e9 rigoroso. Desligar um token tamb\u00e9m interrompe imediatamente qualquer segredo anterior em rota\u00e7\u00e3o ativa<\/strong> \u2014 ou seja, se voc\u00ea iniciou uma rota\u00e7\u00e3o com grace period de 10 dias e, no terceiro dia, identifica que o segredo antigo foi exposto, desligar o token revoga instantaneamente ambos os segredos, contendo a exposi\u00e7\u00e3o de forma absoluta. Essa intera\u00e7\u00e3o entre os dois novos recursos demonstra que o Cloudflare Access seguran\u00e7a foi projetado para operar como um sistema coeso, onde cada controle refor\u00e7a o outro em cen\u00e1rios de crise.<\/p>\n

H\u00e1 tamb\u00e9m o caso de uso de pausa de servi\u00e7os automatizados<\/strong>. Em ambientes de DevOps, um service token pode estar associado a um job de deploy ou a um worker de sincroniza\u00e7\u00e3o que opera em hor\u00e1rios espec\u00edficos. Se o job \u00e9 temporariamente descontinuado \u2014 por exemplo, durante uma reestrutura\u00e7\u00e3o de pipelines \u2014 desativar o token remove o risco de que credenciais esquecidas permane\u00e7am v\u00e1lidas e explor\u00e1veis. Quando o servi\u00e7o voltar a operar, o token \u00e9 reativado sem fric\u00e7\u00e3o. A Cloudflare recomenda usar esse controle para “conter exposi\u00e7\u00e3o suspeita de credenciais ou pausar um servi\u00e7o automatizado”, exatamente os cen\u00e1rios que costumam gerar vulnerabilidades silenciosas em organiza\u00e7\u00f5es de grande porte.<\/p>\n

Do ponto de vista de auditoria, o registro de desativa\u00e7\u00f5es e reativa\u00e7\u00f5es fica dispon\u00edvel nos Audit Logs<\/strong> do Cloudflare, integrados ao Cloudflare Logpush<\/strong> para streaming em tempo real para SIEMs como Splunk, Datadog ou BigQuery. Isso permite que equipes de seguran\u00e7a monitorem eventos de suspens\u00e3o de tokens como sinais de incidente e correlacionem com outros indicadores. Na JRT Technology Solutions, configuramos o Cloudflare para que clientes empresariais recebam alertas autom\u00e1ticos via webhook ou PagerDuty sempre que um service token for desativado ou reativado, garantindo visibilidade total sobre a postura de autentica\u00e7\u00e3o da plataforma.<\/p>\n

Cloudflare Access seguran\u00e7a e os portais MCP: protocolo 2026-07-28 explicado<\/h3>\n

O terceiro an\u00fancio conecta o Cloudflare Access seguran\u00e7a<\/strong> a um dos temas mais relevantes da tecnologia em 2026: a explos\u00e3o de agentes de IA e a necessidade de expor ferramentas e contextos por meio do Model Context Protocol (MCP)<\/strong>. Para quem n\u00e3o acompanhou de perto, o MCP \u00e9 um padr\u00e3o aberto que define como aplica\u00e7\u00f5es \u2014 tipicamente agentes de IA \u2014 se conectam a servidores que fornecem ferramentas, recursos e prompts. Um portal MCP<\/strong> \u00e9 um proxy que centraliza o acesso a m\u00faltiplos servidores MCP upstream, aplicando autentica\u00e7\u00e3o, autoriza\u00e7\u00e3o e observabilidade. O Cloudflare Access atua exatamente nessa camada, garantindo que apenas agentes e aplica\u00e7\u00f5es autenticados consigam alcan\u00e7ar os servidores MCP internos.<\/p>\n

A especifica\u00e7\u00e3o MCP 2026-07-28<\/strong> introduz o modo stateless<\/strong> para conex\u00f5es de clientes e servidores upstream. Em vers\u00f5es anteriores, o protocolo Streamable HTTP mantinha estado de sess\u00e3o no servidor, o que complicava a escalabilidade horizontal e a opera\u00e7\u00e3o de portais em arquiteturas serverless. Com o modo stateless, cada requisi\u00e7\u00e3o carrega todo o contexto necess\u00e1rio para ser processada isoladamente, permitindo que portais MCP sejam implementados como fun\u00e7\u00f5es sem estado \u2014 exatamente o modelo de execu\u00e7\u00e3o da edge da Cloudflare, com Workers e recursos associados. O endpoint \/mcp<\/strong> do portal agora aceita automaticamente requisi\u00e7\u00f5es stateless MCP 2026-07-28 e clientes Streamable HTTP de 2025, sem exigir configura\u00e7\u00e3o adicional.<\/p>\n

Um detalhe t\u00e9cnico relevante \u00e9 que a sele\u00e7\u00e3o de protocolo \u00e9 independente entre clientes e upstream<\/strong>. Quando o portal se conecta a um servidor upstream Streamable HTTP, ele verifica se o servidor suporta MCP 2026-07-28 e, se n\u00e3o suportar, realiza fallback para o handshake de 2025. Isso significa que clientes e servidores podem ser atualizados em momentos diferentes, sem quebrar a comunica\u00e7\u00e3o. Conex\u00f5es SSE<\/strong> (Server-Sent Events) continuam usando o protocolo legado. Para equipes de engenharia que operam portais MCP em produ\u00e7\u00e3o, essa compatibilidade gradual elimina a necessidade de um “big bang” de migra\u00e7\u00e3o \u2014 um padr\u00e3o de design que a Cloudflare tem adotado consistentemente em suas APIs.<\/p>\n

No contexto de seguran\u00e7a, a integra\u00e7\u00e3o do Access com portais MCP \u00e9 estrategicamente importante porque agentes de IA costumam ter acesso privilegiado<\/strong> a sistemas internos. Um agente que consulta bancos de dados, executa queries em APIs financeiras ou<\/p>\n

\n

Sua empresa ainda n\u00e3o usa Cloudflare de forma estrat\u00e9gica?<\/p>\n

A JRT Technology Solutions implementa Cloudflare CDN, WAF, Zero Trust e Workers para empresas que precisam de performance, seguran\u00e7a e escalabilidade.<\/p>\n


\n <\/svg>
\n Falar com especialista
\n <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

A Cloudflare Access seguran\u00e7a ocupa hoje um papel central na arquitetura Zero Trust de empresas que abandonaram o modelo de VPN legado. Com a rede global da Cloudflare processando aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP da internet por meio do AS13335 \u2014 um dos maiores autonomous systems do planeta, presente em mais de 300 … Ler mais<\/a><\/p>\n","protected":false},"author":1,"featured_media":2467,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"iawp_total_views":0,"footnotes":""},"categories":[1721],"tags":[3285],"class_list":["post-2468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cdn-cloudflare","tag-cloudflare-access-security"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t