Cloudflare: Como a detecção de MCP transforma o tráfego de agentes ocultos em uma decisão de segurança

A Cloudflare ampliou a detecção de tráfego MCP para além de nomes evidentes de servidores, expondo um conflito que as equipes de segurança antes poderiam não perceber. A questão de como a Cloudflare atua agora começa com evidências do protocolo, e não com uma lista de domínios conhecidos. O Gateway pode inspecionar tráfego HTTP gerenciado em busca de caminhos específicos de MCP e métodos JSON-RPC, distinguindo então o tráfego aprovado por Portal das conexões diretas.

Essa distinção importa porque o Model Context Protocol, ou MCP, permite que agentes de IA chamem ferramentas externas e recuperem dados privados. Uma única conexão pode alcançar código-fonte, registros de clientes, controles de nuvem ou sistemas de mensagens. Quando funcionários configuram servidores remotos sem análise prévia, a atividade resultante de MCP oculto se assemelha à TI paralela, mas com um agente capaz de executar ações.

A resposta da Cloudflare combina descoberta com um caminho de aplicação de políticas. O Gateway fornece o sinal de rede, enquanto os portais de servidores MCP centralizam servidores aprovados por trás de um único endpoint. As políticas do Access regem as condições de identidade e dispositivo, e a prevenção contra perda de dados, ou DLP, pode inspecionar solicitações e respostas de ferramentas. A questão ainda em aberto é se as organizações conseguem encaminhar tráfego suficiente por esses controles para tornar o modelo confiável.

Como a detecção de MCP da Cloudflare interpreta o protocolo

A mudança importante da Cloudflare é passar de adivinhar destinos para reconhecer o comportamento do MCP dentro do tráfego HTTP inspecionado.

O método de detecção mais simples observa o nome do host de destino. Um administrador pode pesquisar os logs do Gateway por endpoints MCP conhecidos ou por nomes de host que contenham mcp. Essa abordagem captura serviços que anunciam sua finalidade por meio de nomes como mcp.example.com.

Um segundo sinal vem da URI da solicitação. Servidores remotos normalmente expõem caminhos como /mcp, /sse ou /mcp/sse. O Gateway pode pesquisar as solicitações registradas por esses padrões mesmo quando o nome do host parece genérico.

Ambos os métodos são úteis para um inventário inicial, mas nenhum deles prova que uma solicitação transporta MCP. Uma aplicação comum pode usar o mesmo caminho. Um servidor MCP também pode se ocultar atrás de um nome de host comum e de uma rota de API sem destaque.

Por isso, a Cloudflare orienta administradores para a inspeção do corpo das mensagens. O MCP codifica mensagens usando JSON-RPC, um formato estruturado de solicitação que contém campos como jsonrpc, method e params. Nomes de métodos padronizados geram evidências reconhecíveis no nível do protocolo.

Entre os exemplos estão initialize, tools/list, tools/call, resources/read e prompts/get. Um perfil de DLP pode buscar essas strings em corpos POST, mesmo quando o domínio e o caminho não revelam nada. A Cloudflare publicou exemplos de expressões regulares em sua arquitetura de MCP que cobrem vários métodos comuns e campos de versão do protocolo.

O método initialize é particularmente útil porque inicia a relação entre um cliente MCP e um servidor. Um cliente declara sua versão de protocolo, capacidades, nome e versão. O servidor responde com suas próprias capacidades e pode criar uma sessão.

As chamadas de ferramentas produzem um sinal operacional mais forte. Uma solicitação contendo tools/call indica que o agente está tentando invocar uma capacidade, e não apenas verificar se um endpoint existe. Os argumentos também podem revelar quais dados ou ações a ferramenta irá processar.

O modelo da Cloudflare é, portanto, composto por camadas:

• Padrões de nome de host identificam servidores MCP conhecidos ou claramente nomeados.

• Padrões de URI identificam endpoints MCP remotos convencionais.

• Métodos JSON-RPC identificam o comportamento de MCP em endpoints menos evidentes.

• Campos de usuário e dispositivo vinculam esse comportamento a uma pessoa ou sistema gerenciado.

• As ações do Gateway mostram se a solicitação foi permitida, bloqueada ou tratada de outra forma.

O fluxo de trabalho documentado pela Cloudflare usa o conjunto de dados gatewayHttpRequestsAdaptiveGroups em sua API GraphQL Analytics. Administradores podem agrupar resultados por host, URI, usuário, ação e perfis DLP correspondentes. Segundo o tutorial de detecção da empresa, o conjunto de dados permite consultas históricas de até 30 dias.

Isso não é detecção de ameaças com reconhecimento de conteúdo no sentido mais amplo. Uma correspondência com tools/call indica que uma ferramenta MCP foi invocada. Ela não determina se a ferramenta é confiável, se suas instruções são maliciosas ou se a ação corresponde à intenção do usuário.

Ainda assim, o reconhecimento de protocolo fecha uma lacuna importante de visibilidade. Uma equipe de segurança não precisa mais conhecer todos os fornecedores ou endpoints de MCP antes de iniciar uma investigação. Ela pode buscar propriedades do próprio protocolo.

Isso cria a tensão central do artigo. A detecção pode revelar tráfego MCP direto, mas um sinal por si só não determina quais conexões devem permanecer disponíveis. A Cloudflare precisa oferecer uma alternativa governada antes que um administrador possa bloquear o caminho não gerenciado sem interromper trabalho legítimo.

O MCP oculto coloca equipes de segurança entre acesso e adoção

A pressão imediata recai sobre as equipes de segurança, que precisam separar conexões úteis de agentes de acessos não analisados a sistemas sensíveis.

O MCP padroniza como uma aplicação de IA descobre ferramentas, lê recursos, recupera prompts e invoca ações. O protocolo reduz o trabalho de integração personalizada, o que também facilita que funcionários e desenvolvedores adicionem servidores sem um projeto central de implantação.

Essa velocidade cria um problema conhecido de governança. Um usuário pode configurar um cliente MCP com a URL de um servidor remoto e conceder acesso usando OAuth ou outra credencial. A equipe de segurança talvez nunca veja essa configuração dentro de seu catálogo de software aprovado.

O risco é maior do que uma visita a uma aplicação web não autorizada. Um servidor MCP expõe ferramentas a um agente, e essas ferramentas podem ter permissões relevantes. Dependendo da integração, elas podem pesquisar documentos, ler repositórios, abrir registros de suporte, modificar infraestrutura ou enviar mensagens.

Uma ferramenta legítima ainda pode receber dados inadequados. Um funcionário pode pedir a um agente que analise um problema de cliente e, sem perceber, enviar informações regulamentadas a um servidor externo. Um servidor comprometido ou enganoso também pode retornar instruções concebidas para manipular o comportamento posterior do agente.

É por isso que a Cloudflare descreve conexões não gerenciadas como MCP oculto. A questão definidora não é se todo servidor desconhecido é hostil. É que a organização não analisou o servidor, seu operador, as permissões solicitadas nem os dados que fluem por ele.

Os logs do Gateway podem transformar essa atividade desconhecida em um inventário. Administradores podem identificar usuários, hosts de destino, volumes de solicitações, ações de políticas e métodos de protocolo detectados. Em seguida, podem investigar qual cliente criou o tráfego e qual finalidade de negócio ele atende.

O inventário também permite uma aplicação de políticas mais ponderada. Uma equipe pode registrar correspondências iniciais, revisar destinos ativos e classificar cada servidor antes de bloquear qualquer coisa. Casos de alta confiança, como tráfego direto para uma ferramenta remota não aprovada, podem receber uma política mais rigorosa.

No entanto, a cobertura de rede gerenciada define o limite. O Gateway deve atuar ativamente como proxy do tráfego HTTP relevante. Se um funcionário usar um dispositivo não gerenciado, um caminho de rede separado ou um cliente fora dos controles da organização, essas solicitações não aparecerão nos mesmos logs.

O tráfego criptografado acrescenta outra condição. O Gateway precisa da descriptografia TLS para inspecionar o corpo HTTP de uma conexão MCP direta. Sem ela, os administradores podem ver o nome do host de destino, mas deixar de identificar métodos JSON-RPC e argumentos de ferramentas.

A Cloudflare trata o tráfego de Portal de forma diferente. O Portal encerra a conexão do cliente e cria uma nova conexão com o servidor upstream. Essa arquitetura permite que o Gateway inspecione o tráfego de Portal encaminhado sem depender da configuração de descriptografia TLS para toda a conta.

O tráfego direto não recebe esse tratamento automático. A documentação do Portal da Cloudflare informa que um agente conectado diretamente por um dispositivo gerenciado pelo WARP exige a configuração normal de descriptografia TLS para inspeção do corpo.

Também há razões legítimas para isentar tráfego da inspeção. Requisitos de privacidade, aplicações com fixação de certificado ou restrições operacionais podem levar as equipes a criar políticas Do Not Inspect. Essas políticas têm precedência e podem deixar atividades MCP correspondentes fora da análise de DLP.

Esses limites não tornam a detecção inútil. Eles definem o que o painel resultante realmente significa. Um relatório mostra atividade semelhante a MCP visível em caminhos gerenciados e inspecionados. Não é um censo completo de todas as conexões de agentes da empresa.

Essa distinção deve orientar a resposta a incidentes. Uma conexão detectada merece investigação, mas um relatório vazio não prova que o MCP oculto esteja ausente. As equipes de segurança precisam de cobertura de endpoints, dados de identidade e controles de configuração de clientes além da detecção de rede.

A disputa real é entre acesso por Portal e conexões diretas

O modelo de segurança da Cloudflare só se torna aplicável quando o acesso aprovado por Portal substitui URLs diretas de servidores em caminhos gerenciados.

Um portal de servidores MCP agrega vários servidores aprovados por trás de um único endpoint HTTP. Os usuários configuram esse endpoint em seu cliente MCP, autenticam-se pelo Cloudflare Access e recebem apenas os servidores e ferramentas permitidos pela política.

O Portal realiza várias funções que conexões diretas distribuem entre integrações individuais. Ele identifica o usuário, avalia regras do Access, gerencia a autenticação upstream, expõe ferramentas aprovadas e registra solicitações. Administradores podem organizar servidores sem pedir que cada funcionário mantenha uma lista separada de endpoints.

As políticas do Access podem usar grupos de identidade, localização e postura do dispositivo. Um portal financeiro pode expor ferramentas selecionadas de somente leitura a funcionários da área financeira. Um portal de engenharia pode permitir ações adicionais apenas a partir de dispositivos corporativos gerenciados.

Administradores também podem ocultar ferramentas ou prompts individuais. Isso é importante porque aprovar um servidor não exige aprovar todas as capacidades que ele publica. Um servidor com acesso a repositórios pode expor operações de pesquisa e leitura, enquanto sua operação de escrita permanece indisponível.

O design do Portal da Cloudflare oferece suporte a servidores upstream não autenticados e a servidores protegidos por OAuth. Usuários podem autenticar-se separadamente em um serviço upstream, ou alguns fluxos de trabalho máquina a máquina podem usar tokens de serviço do Access. O Portal então anexa as credenciais adequadas ao atuar como proxy de uma chamada de ferramenta.

Quando o roteamento pelo Gateway está ativado, as chamadas em tempo real passam do Portal pelo Gateway antes de chegar ao servidor upstream. O Gateway registra as solicitações e pode aplicar políticas HTTP e de DLP. Os controles de saída também podem fornecer a essas solicitações endereços de origem previsíveis.

Isso cria um padrão prático de permitir e bloquear. As equipes de segurança fornecem aos funcionários um endpoint de Portal aprovado e, em seguida, criam regras no Gateway que interrompem conexões diretas com servidores MCP upstream. O caminho pelo Portal permanece disponível, enquanto alternativas sem governança são restringidas.

A política deve direcionar-se ao destino correto. A Cloudflare informa que as regras de DLP para tráfego de Portal devem corresponder ao nome do host do servidor MCP upstream, e não apenas ao domínio do Portal. O Portal é o ponto de entrada voltado ao cliente, mas o Gateway avalia a solicitação reoriginada que segue em direção ao servidor real.

A estrutura se assemelha mais a um gateway de aplicações do que a um simples diretório. Ela oferece um ponto de controle onde identidade, seleção de ferramentas, registros e controles de dados se encontram. Esse ponto de controle é o que transforma descoberta em governança.

Ainda assim, a URL direta continua sendo uma fraqueza central. A Cloudflare alerta que ocultar um servidor de um Portal não impede que um usuário se conecte ao seu endereço original. Se o servidor upstream permanecer acessível publicamente, a política do Portal, por si só, não poderá impedir a evasão.

Por isso, as organizações precisam de um controle de aplicação fora da interface do Portal. Elas podem proteger um servidor com Access quando controlam seu hostname, restringir o tráfego de entrada a endereços de saída conhecidos ou bloquear destinos diretos por meio do Gateway. Serviços de terceiros exigirão os controles compatíveis com seu modelo de implantação.

A escolha não é entre Cloudflare e outro fornecedor de segurança. O principal confronto é entre acesso governado via Portal e conexões diretas configuradas pelos usuários. Cada recurso principal atende a esse embate.

Os logs do Portal identificam atividades aprovadas. A descoberta do Gateway procura tráfego fora da rota aprovada. O Access estabelece quem pode usar o Portal. O DLP avalia os dados que atravessam o caminho gerenciado. A política de rede tenta fechar a rota direta.

Esse modelo também oferece aos desenvolvedores um destino utilizável depois que a aplicação das regras começa. Uma proibição generalizada de MCP levaria a experimentação para fora dos canais oficiais. Um Portal curado permite que as equipes mantenham ferramentas aprovadas disponíveis enquanto a segurança analisa servidores adicionais.

O resultado depende de disciplina operacional. Alguém precisa ser responsável pelo catálogo de servidores aprovados, revisar permissões de ferramentas, manter políticas de Access e responder a destinos recém-detectados. A centralização reduz controles dispersos, mas não elimina essas decisões.

Heurísticas de Protocolo Criam Cobertura, Não Certeza

A Cloudflare consegue identificar fortes indicadores de MCP, mas esses indicadores não comprovam que uma conexão seja segura, maliciosa ou corretamente governada.

Os padrões de detecção são heurísticos. Um corpo contendo "method":"tools/call" se parece muito com MCP, mas outra aplicação JSON-RPC poderia usar o mesmo nome de método. Uma implementação personalizada de MCP também poderia produzir uma formatação fora do escopo de uma expressão regular escrita de forma restrita.

As tolerâncias a espaços em branco ilustram o problema. Expressões de exemplo permitem uma quantidade limitada de espaçamento em torno dos campos JSON. Campos reordenados devem continuar detectáveis quando cada padrão tem como alvo um campo, mas serialização e escape alternativos podem dificultar a correspondência.

Tráfego criptografado ou não compatível cria lacunas maiores. O DLP não consegue inspecionar o corpo de uma conexão HTTPS direta a menos que o Gateway a descriptografe. Servidores MCP locais que se comunicam por entrada e saída padrão não passam por um gateway HTTP.

O HTTP Streamable é o transporte remoto mais importante no design atual da Cloudflare. A especificação de transporte MCP define solicitações HTTP que transportam mensagens JSON-RPC e identificadores de sessão opcionais. Essas estruturas regulares ajudam o Gateway a reconhecer o protocolo.

O caminho roteado do Portal oferece suporte a HTTP Streamable. Se um servidor upstream oferecer suporte apenas ao transporte mais antigo Server-Sent Events, o roteamento pelo Gateway falhará para esse servidor. O Portal tenta usar HTTP Streamable quando o roteamento está ativado, mas o serviço upstream precisa oferecer suporte a ele.

A sincronização em segundo plano é outra exceção. Os Portals recuperam periodicamente ferramentas e prompts dos servidores upstream, mas a Cloudflare informa que essas solicitações de sincronização não passam pelo Gateway. Apenas chamadas de ferramentas de usuários em tempo real recebem a inspeção roteada documentada.

A cobertura de DLP também tem limites específicos do produto. A Cloudflare afirma que seus perfis de prompts de IA não se aplicam ao tráfego do MCP Portal porque esses perfis esperam caminhos e formatos de API diferentes. Os administradores devem usar perfis padrão de DLP.

As regras Do Not Inspect continuam válidas para o tráfego do Portal. Embora o roteamento do Portal permita descriptografia automática, uma isenção explícita impede a inspeção da carga útil. Portanto, uma exceção ampla poderia remover a proteção DLP de um servidor upstream aprovado.

As políticas de identidade também têm ressalvas. A Cloudflare documenta que MFA independente, justificativa de propósito e autenticação temporária não são aplicadas a servidores autorizados por meio de um Portal. Seletores de e-mail, grupo, país e postura do dispositivo continuam sendo aplicáveis.

Essas restrições são importantes porque um Portal pode parecer mais restritivo do que seu caminho de política realmente é. Um administrador pode atribuir um requisito no nível do servidor e presumir que os usuários o encontrarão durante a autorização no Portal. A documentação da Cloudflare afirma que vários controles de autenticação adicional não funcionarão dessa forma.

As equipes de segurança também devem separar a detecção de protocolo da segurança semântica. Uma solicitação pode passar por um Portal aprovado, não corresponder a nenhuma regra de DLP e ainda assim acionar uma ação insegura. O DLP procura padrões de dados definidos, não se excluir um projeto corresponde à intenção do usuário.

A injeção de ferramentas apresenta um problema relacionado. Um servidor upstream pode retornar conteúdo que influencia a próxima decisão de um agente. A inspeção de rede pode registrar ou bloquear strings sensíveis, mas não necessariamente reconhecer instruções manipuladoras incorporadas em conteúdo que, de resto, é válido.

O inverso também é verdadeiro. Uma conexão MCP paralela não é automaticamente um incidente. Um desenvolvedor pode estar testando uma fonte pública de dados inofensiva. A conexão continua sem governança, mas seu impacto nos negócios e na segurança exige contexto.

Portanto, falsos positivos e falsos negativos fazem parte do modelo operacional. As equipes devem tratar correspondências de hostname e URI como pistas e, em seguida, usar sinais do corpo, atribuição de usuário, dados do cliente e análise do servidor para chegar a uma decisão. Regras de bloqueio de alto impacto devem se basear em mais do que uma correspondência genérica de caminho.

Uma implantação em etapas pode reduzir interrupções. Os administradores podem começar com registros, estabelecer o tráfego esperado do Portal e identificar destinos diretos comuns. Em seguida, podem bloquear conexões paralelas de alta confiança enquanto criam um processo de aprovação para novos servidores.

A versão mais robusta combina controles de rede e endpoint. O Gateway vê o tráfego remoto que cruza caminhos gerenciados. O gerenciamento de endpoints pode controlar quais clientes e configurações os usuários instalam. As restrições de Access e upstream dificultam a evasão quando já existe uma rota aprovada.

A Cloudflare forneceu as peças para essa arquitetura. Ela não eliminou a necessidade de projetá-la.

Três Sinais Mostrarão se o Modelo MCP da Cloudflare se Sustenta

O próximo teste é saber se as empresas conseguem transformar a visibilidade sobre MCP em roteamento consistente, bloqueio significativo e governança mensurável de ferramentas.

O primeiro sinal é a parcela do tráfego detectado que passa por domínios de Portal aprovados. As buscas iniciais no Gateway provavelmente revelarão uma combinação de serviços conhecidos, experimentos e falsos positivos. O modelo ganha credibilidade quando a atividade MCP direta diminui depois que alternativas aprovadas se tornam disponíveis.

As equipes de segurança devem medir isso como um resultado de roteamento, e não apenas como uma contagem de bloqueios. Um número crescente de solicitações bloqueadas pode mostrar que a política funciona, mas também pode indicar que os usuários continuam tentando contornar a rota aprovada. Uma migração bem-sucedida significa que a atividade legítima continua pelo Portal.

O segundo sinal é a qualidade das políticas nos níveis de ferramenta e dados. Um Portal que expõe todos os recursos de todos os servidores aprovados centraliza o acesso sem aplicar muita restrição. Implantações mais fortes farão curadoria de ferramentas, usarão condições de identidade e aplicarão perfis de DLP tanto às solicitações quanto às respostas.

O Gateway da Cloudflare pode bloquear uma solicitação de ferramenta quando o conteúdo de saída corresponde a um perfil padrão de DLP. Ele também pode bloquear a resposta quando o servidor upstream retorna dados sensíveis correspondentes. O cliente MCP recebe um erro em vez do conteúdo protegido.

Esses controles se tornam mais valiosos quando as organizações os ajustam aos fluxos de trabalho reais. Credenciais, informações financeiras, identificadores de clientes e documentos proprietários envolvem riscos diferentes. Uma política que bloqueia tudo frustrará os usuários, enquanto uma que nunca é acionada oferece pouca proteção.

As equipes de segurança devem acompanhar métodos de ferramenta bloqueados, categorias de dados correspondentes, servidores afetados e resultados para os usuários. Também devem analisar se os agentes repetem solicitações bloqueadas. Tentativas repetidas podem revelar um comportamento inadequado do cliente ou um fluxo de trabalho que precisa de um design aprovado mais seguro.

O terceiro sinal é a velocidade com que a Cloudflare e o ecossistema MCP fecham lacunas conhecidas de cobertura. A adoção de HTTP Streamable deve reduzir o número de servidores upstream que não conseguem usar o roteamento do Gateway. Melhores controles de endpoint podem ampliar a visibilidade sobre configurações locais e não gerenciadas.

As mudanças no protocolo também serão importantes. Padrões de detecção baseados nos métodos JSON-RPC atuais precisam acompanhar a evolução da especificação. Um cabeçalho estável ou outro sinal de transporte padronizado poderia facilitar a classificação, mas as equipes de segurança não devem presumir que todos os clientes adotarão novos campos imediatamente.

O comportamento dos concorrentes oferecerá outra pista sem alterar o embate central. Fornecedores de secure web gateway e endpoint provavelmente adicionarão suas próprias classificações MCP, inventários de servidores ou controles de agentes. Essa pressão pode aprimorar os métodos de detecção e expor limitações das abordagens exclusivamente baseadas em rede.

A vantagem da Cloudflare é a integração arquitetônica. Seu Portal, Access, Gateway, DLP, egress e controles de aplicações podem participar de um único caminho de política. Seu desafio é provar que os clientes conseguem configurar esses componentes sem deixar brechas significativas de evasão.

Assim, a história do “como” da Cloudflare trata menos de um único detector e mais de um ciclo de feedback. Encontrar tráfego MCP direto, investigá-lo, aprovar os servidores necessários, roteá-los por um Portal e bloquear o caminho não gerenciado. Depois, repetir o processo à medida que os usuários adotam novas ferramentas.

As organizações que consideram esse modelo devem começar com uma pergunta prática: quais caminhos de rede gerenciados e clientes de agentes sua equipe de segurança realmente consegue observar hoje?

A partir daí, elas podem inventariar sinais de MCP, compará-los com o tráfego aprovado do Portal e escolher onde a aplicação de regras tem confiança suficiente. O objetivo não é rotular toda conexão MCP como perigosa. É garantir que os agentes acessem ferramentas sensíveis por uma rota que a organização possa autenticar, inspecionar e auditar.