A Cloudflare publicou um modelo de ameaça em nível de produção e uma arquitetura de políticas para o tráfego do Model Context Protocol, cobrindo detecção, aplicação de identidade, bloqueio de prompt injection e prevenção de movimento lateral em três superfícies de controle. O anúncio chega conforme a adoção de MCP se expandiu além das equipes de engenharia da própria Cloudflare para produto, vendas, marketing e finanças.

O risco central é velocidade sem limites. Um engenheiro humano implantando em produção ou consultando um banco de dados sensível é limitado pelo julgamento humano e pelo ritmo humano. Um agente de IA não é. Uma decisão errada pode se replicar em milhares de ações incorretas antes que alguém perceba. MCP amplifica isso porque uma única linha de configuração conecta um agente a um servidor de ferramentas, e o tráfego resultante não tem uma assinatura de rede óbvia — MCP não usa um hostname garantido e não exige /mcp no caminho.

A arquitetura da Cloudflare define três pontos de intervenção. Primeiro: dentro do cliente MCP, um hook que dispara após o modelo selecionar uma ferramenta pode negar servidores não aprovados, remover argumentos sensíveis ou solicitar confirmação humana. Este é o intercept mais antigo e o único plano que vê servidores MCP stdio locais que não geram tráfego de rede. O limite é padronização — controles devem ser reproduzidos em cada cliente que os funcionários usam. Segundo: Cloudflare Gateway inspeciona tráfego HTTP após deixar o dispositivo. Com descriptografia TLS, Gateway correlaciona solicitações a usuários e dispositivos, aplica políticas DLP e bloqueia conexões diretas a servidores não aprovados. Terceiro: o próprio servidor. AI Security for Apps da Cloudflare dentro do WAF inspeciona tráfego MCP de entrada para prompt injection, vazamento de dados sensíveis e violações de tópicos.

A detecção de Shadow MCP é a nova peça operacionalmente interessante. Cloudflare Gateway executa varreduras em múltiplas camadas para expor servidores MCP remotos que funcionários estão acessando fora de portais aprovados. As camadas de detecção incluem correspondência de hostname para servidores conhecidos como mcp.stripe.com, padrões de subdomínio curinga, padrões de caminho (/mcp, /mcp/sse) e inspeção de corpo DLP que escaneia payloads POST em busca de marcadores JSON-RPC como "method": "tools/call". A varredura de corpo DLP tem um limite máximo: apenas os primeiros 1.024 bytes do corpo POST, usando sintaxe regex Rust.

O roteamento de tráfego através de MCP Server Portals adiciona aplicação. Quando o roteamento Gateway é ativado, cada chamada de ferramenta do portal passa por proxy através do Gateway antes de chegar ao servidor upstream. Duas limitações: o roteamento Gateway suporta apenas o transporte HTTP Streamable, portanto servidores usando endpoints SSE (/sse) falharão. Sincronização de ferramentas e prompt em background — executando a cada duas horas com credenciais de admin — não passa por Gateway, criando um ponto cego de visibilidade.

Incidentes reais ilustram o que este framework defende. Em junho de 2025, a integração MCP de uma ferramenta de colaboração em equipe vazou dados de clientes entre instâncias, forçando uma interrupção de duas semanas. CVE-2025-6514 atingiu um pacote npm amplamente usado para autenticação MCP. A pesquisa NeighborJack encontrou centenas de servidores MCP vinculados a 0.0.0.0 sem regras de firewall, abertos para injeção de comando OS e takeover de host. Um ataque confused deputy documentado viu um agente com privilégios de alto nível executar comandos SQL incorporados em um ticket de suporte, comprometendo um banco de dados inteiro.

A detecção de shadow baseada em Gateway mais roteamento reforçado por Portal fornece a cobertura mais ampla em nível de rede. Mas o limite de varredura DLP de 1.024 bytes, a restrição de transporte SSE-para-Streamable-HTTP e o intervalo de sincronização em background significam que a detecção de perímetro é necessária mas não suficiente — regras WAF no lado do servidor e hooks no lado do cliente têm peso independente.