Shadow AI Entrou no Perímetro e o Seu Playbook de Detecção Ficou de Fora

A Cloudflare precisou construir detecção na camada de protocolo para MCP porque tráfego MCP não tem formato de URL confiável. Falta uma convenção /mcp que se sustente, uma lista de domínios de fornecedores que permaneça atualizada, uma porta que o separe de HTTPS comum. Se o seu inventário de MCP saiu de uma busca por hostname, ele é a lista dos servidores cujos nomes você já conhecia.

Em agosto de 2026, Cloudflare e Webflow publicaram sobre o mesmo problema de fundo a partir de pontas opostas da pilha. A Cloudflare escreveu sobre detectar tráfego MCP saindo da rede. A Webflow escreveu sobre infraestrutura de nuvem que engenheiros construíram com agentes de código dentro das contas AWS da própria empresa. Os dois textos pulam a etapa de enforcement e param na camada anterior: governar exige enxergar primeiro, e o sinal que costumava procurar desapareceu.

Já argumentamos que shadow AI é sintoma de um caminho oficial ausente e que plataformas de vibe coding transferem a governança para quem opera a plataforma. Este texto trata da mecânica embaixo disso: qual é de fato o sinal de descoberta e onde cada controle se encaixa depois que você tem esse sinal.

O Header de Protocolo É Uma Pista, Não Um Teste

A própria especificação do MCP entrega o sinal mais forte disponível. A revisão 2025-11-25 exige o header MCP-Protocol-Version em toda requisição HTTP após a inicialização. A revisão 2026-07-28 passa a exigi-lo em todo POST e acrescenta Mcp-Method e Mcp-Name, que carregam o método invocado e o nome da ferramenta ou do recurso. É telemetria notável para vir de um header. Ela identifica a ferramenta que o cliente acionou, além de registrar que houve MCP.

Vem então a restrição. Revisões anteriores a 2025-06-18 sequer definiam o header. Kenny Johnson, da Cloudflare, enuncia o limite com clareza: “A presença dele é um forte indicador positivo de MCP; a ausência dele não prova que a requisição não é MCP.” Um cliente antigo, uma implementação caseira ou uma deliberadamente silenciosa produz tráfego sem marcador algum.

O sinal é assimétrico. Precisão alta, recall desconhecido. Essa propriedade é útil quando tratada como piso e perigosa quando reportada para cima como cobertura. Um painel que informa quantos servidores MCP você enxerga está reportando um limite inferior, e a contagem dos invisíveis nunca vai aparecer nele.

O fornecedor nomeia os próprios pontos cegos, o que vale mais que a lista de funcionalidades. Transportes stdio permanecem invisíveis porque nunca tocam a rede. Clientes fora da rede, ou seja, notebooks fora do túnel, permanecem invisíveis. Tudo que passa por uma regra de Do Not Inspect permanece invisível, e listas de Do Not Inspect são justamente onde domínios de aparência sensível se acumulam ao longo de anos de pedidos de exceção. Leia a sua antes de comprar qualquer produto de visibilidade de MCP. Aquela lista é o seu teto real de recall.

Servidor Não Aprovado e Bypass São Problemas Diferentes

A linha mais útil do texto da Cloudflare é uma taxonomia: “servidores não aprovados e bypasses de servidores aprovados são problemas diferentes.”

A maioria dos times mistura os dois, e a mistura aparece na forma de uma única regra de política acumulando duas funções. A base sugerida pela Cloudflare é uma expressão do Gateway:

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal") → Block

Leia o que a regra de fato diz. Ela bloqueia MCP que chegou por qualquer rota diferente do ponto de entrada oficial. Um servidor aprovado acessado direto, contornando o portal que faz o log e a autenticação, recebe o mesmo tratamento de um servidor que ninguém avaliou.

Essas duas falhas têm donos distintos e correções distintas. Servidor não aprovado é questão de procurement: quem é o fornecedor, que dados a ferramenta toca, o que acontece quando ele cai. Bypass é questão de caminho pavimentado. O servidor está ok, a rota está errada, e o motivo quase sempre é que o caminho oficial era mais lento ou exigia abrir um chamado. O primeiro caso pede processo de avaliação. O segundo pede que a rota aprovada seja a mais rápida, porque engenheiros contornam atrito e vão continuar contornando.

Se a sua política gera um único tipo de alerta para os dois casos, a fila de remediação mistura uma decisão de risco de fornecedor com um defeito de experiência do desenvolvedor, e o defeito de experiência vai ficar parado ali por meses.

A Mesma Cegueira, Dentro da Sua Própria Conta

Andy Gombar, da Webflow, descreve a segunda face disso: “saímos do espalhamento de SaaS para o espalhamento de código. O playbook de detecção de um não se traduz para o outro.”

O sinal clássico de shadow IT era financeiro. SaaS não aprovado aparecia como despesa no cartão ou domínio novo no DNS. Infraestrutura construída por agente escapa dos dois sinais. Ela é provisionada dentro de contas que você já possui, com credenciais que você já emitiu, por engenheiros fazendo o trabalho deles. O que existe é uma role IAM nova e um bucket S3 idênticos às demais criações legítimas daquele mês.

A resposta da Webflow observa comportamento de provisionamento em vez de nomes de ferramentas. Três sinais que eles observam:

Criação de role IAM fora da atividade normal do pipeline, ou seja, alguém ou algum agente criou a role na mão, por fora do Terraform.
Recursos novos expostos publicamente sem registro de mudança correspondente.
Chamadas de API partindo de máquinas de desenvolvedor direto para contas de produção.

Os três funcionam sem saber qual ferramenta foi usada, e é exatamente por isso que foram escolhidos. Eles descrevem o formato de um provisionamento que pulou o pipeline, e sobrevivem ao que quer que o mercado de ferramentas de agente faça no ano que vem.

A frase mais afiada dele é sobre revisão. Gombar chama a checagem de baseline de “portão de compreensão”, tanto quanto portão de qualidade. Código que um agente escreveu e um humano aprovou sem entender vira passivo no instante em que quebra às três da manhã. A pergunta do revisor migra de “isso está correto” para “alguém aqui consegue explicar isso sob pressão”.

Vale ser honesto sobre o que a Webflow está reportando. O autor descreve “a baseline que estamos construindo” e omite resultados, contagem de incidentes e comparação antes e depois. Trate como desenho bem argumentado à espera de evidência. O texto da Cloudflare é inteiramente qualitativo, então cite-o pelo mecanismo e jamais por escala.

Divida os Controles: Plataforma Assume Uns, Processo Assume os Outros

O movimento estrutural que vale copiar é a divisão. A Webflow separa controles aplicados centralmente de controles distribuídos aos times.

Controles de plataforma, sob responsabilidade de quem opera a conta:

Guardrails de menor privilégio em IAM, para que o raio de impacto de uma decisão ruim de provisionamento já venha limitado antes de qualquer revisão.
Uso obrigatório de gerenciador de segredos, para que credenciais nunca cheguem a aparecer em código gerado por agente.
Alvos de deploy atrás de VPN, para que um notebook fique impedido de empurrar algo direto para produção.

Controles de processo, distribuídos aos times:

Uma checagem automatizada de baseline que roda na mudança, sem depender de reunião.
Revisão com viés de segurança e escalação por nível de risco, para que uma página de marketing estática e um serviço que toca dados de cliente recebam escrutínios diferentes.

A assimetria importa para organizações sem time dedicado de AppSec, que são a maioria. Controles de plataforma escalam sem headcount porque quem os aplica é a conta. Controles de processo custam atenção humana toda vez que disparam, e é por isso que a divisão por nível de risco sustenta o resto. Revisão uniforme para toda mudança quebra em silêncio, na forma de aprovações que ninguém leu.

Faça Isto Agora

Duas coisas nesta semana, ambas pequenas.

Abra a sua lista de Do Not Inspect e leia entrada por entrada. Para cada uma, responda se um cliente de agente poderia alcançar um servidor MCP por ali. Essa lista define o teto de qualquer visibilidade de MCP que você esteja prestes a comprar, e custa uma hora de leitura.

Depois, rode uma única consulta no log de auditoria da sua nuvem: roles IAM criadas nos últimos 90 dias por qualquer identidade fora do pipeline. Ordene por criador. Você está contando quantas existem e verificando se o número surpreende. Se surpreender, o seu trabalho começa na camada de descoberta, e qualquer motor de política comprado antes disso vai governar apenas a fração que consegue nomear.

O conselho final de Gombar acerta a ordem: “construa a baseline antes que o CSPM a encontre para você.” Uma ferramenta que inventaria o seu desvio produz uma lista longa, sem dono claro e impossível de acionar. A baseline é o que torna a lista finita. Para o lado de raio de impacto disso, escrevemos uma versão executável da pergunta de contenção, e para aquilo que o seu fornecedor sequer registra, o problema de auditoria de sessão é o texto irmão.

Fontes

Cloudflare. “How Cloudflare detects MCP traffic and helps secure it.” Agosto de 2026.
Webflow. “Vibe coded apps are the new shadow IT.” Agosto de 2026.

As duas fontes são publicações de fornecedor, e nenhuma das duas reporta resultados medidos.

A Victorino ajuda organizações de engenharia a construir a camada de descoberta para tráfego de agentes e infraestrutura provisionada por agentes, e a dividir os controles entre plataforma e processo: contato@victorino.com.br | www.victorino.com.br