Reconhecer os ataques próprios deste protocolo

Um servidor MCP malicioso consegue desviar o assistente da empresa antes de qualquer ferramenta ser chamada, e a política de aprovação que a maioria dos comitês assinou não enxerga esse momento. O prejuízo possível inclui chave de acesso à nuvem copiada, correspondência desviada e investigação de incidente sem registro confiável. São oito padrões documentados, e o controle mais comum cobre dois.

Onde essa conversa costuma travar

O gerente comercial da rede de distribuição de material de construção pediu que o assistente consultasse estoque nos quatro estados sem abrir o ERP. O CTO ligou um servidor que faz isso. A diretora jurídica perguntou o que acontece se aquilo for usado contra a empresa, e ouviu que nada é executado sem alguém aprovar na tela.

Faltou uma parte nessa resposta. Ela descreve o que acontece quando uma ferramenta é chamada e omite o que já aconteceu no instante da conexão. Este capítulo percorre os oito padrões com nome e fonte, e responde três coisas para cada um: como o dano chega, qual controle efetivamente barra e por que o controle intuitivo chega depois do estrago.

O segundo padrão mede o tamanho do primeiro

Se a descrição de uma ferramenta influencia o modelo, a pergunta seguinte é quanto. O benchmark MCPTox (bateria de testes padronizada, como o crash test de carro) usou 45 servidores reais e 353 ferramentas autênticas, gerando 1.312 casos maliciosos avaliados em vinte configurações de agente. O ataque teve sucesso em 72,8% dos casos na configuração mais suscetível, e a maior taxa de recusa ficou abaixo de 3%.

O achado que muda a conversa comercial vem em seguida. Modelos mais capazes se mostraram mais suscetíveis, porque o ataque explora justamente a capacidade de seguir instrução. Cai o argumento de venda mais comum da categoria, a promessa de mais segurança pela troca por um modelo mais forte. A defesa migra para fora do modelo: revisão dos metadados declarados e política de execução imposta no host.

Picotar o pedido derruba a recusa

Em julho de 2026, o ASSET Research Group divulgou a técnica GhostSplice. O servidor malicioso divide um pedido proibido em pedaços inofensivos e espalha cada pedaço por um canal em que o agente já confia: a descrição da ferramenta, o resultado dela e a mensagem de amostragem. O modelo recebe uma tarefa de rotina, como preencher um formulário de auditoria, e monta sozinho o roubo de credenciais.

Nos onze modelos testados por interface de programação, a obediência média subiu de 42% com o pedido inteiro para 82% com o pedido dividido em dois. Três modelos que recusavam sempre passaram a obedecer em todas as tentativas. A leitura para o comitê repete a do MCPTox: filtro de palavra perigosa e treino de recusa do modelo cobrem pouco, e o controle precisa morar em quem decide o que o agente pode ler e enviar.

Rug pull, ou aprovar hoje o que o servidor vai virar amanhã

Rug pull (puxar o tapete: trocar o conteúdo depois de ganhar a confiança) é alterar a definição ou o comportamento de uma ferramenta depois da aprovação. Funciona porque a maioria dos clientes valida a definição na instalação e nunca mais realerta. A versão auditada pelo comitê e a versão em execução seis semanas depois podem ser objetos diferentes sem aviso a ninguém.

Esse padrão saiu do papel em agosto de 2026. A Pillar Security relatou em 12/08/2026 a campanha Deadbugz: um servidor chamado productivity-suite, oferecido em 23 propostas de alteração de código enviadas a projetos públicos sem relação entre si, em 74 minutos no dia 10/08/2026. Nenhuma foi incorporada pelo mecanismo normal de aceite, e 19 já estavam fechadas na apuração.

Contar chamadas em vez de mudar código foi a escolha que derrubou a revisão de instalação. O gatilho é a quarta chamada, então qualquer inspeção feita só no primeiro uso aprova um servidor limpo. A lição transversal cabe numa linha: fixar a versão e comparar a definição viva com a aprovada, a cada conexão, com bloqueio quando elas divergirem. A mitigação de referência já tinha nome desde 2025, confiança no primeiro uso com alerta em mudança.

Confused deputy em proxy OAuth, o padrão que todo gateway corporativo herda

Confused deputy (procurador confuso: o intermediário usa a própria autoridade a favor de quem não deveria) exige quatro condições que aparecem juntas com frequência incômoda. O proxy usa identificador de cliente estático junto ao servidor de autorização de terceiro. Ele aceita registro dinâmico de clientes. O terceiro grava cookie de consentimento depois da primeira autorização. E não existe consentimento por cliente antes do encaminhamento.

Com as quatro presentes, o atacante registra um cliente com endereço de retorno próprio, envia um link à vítima, o cookie suprime a tela de aprovação e o código de autorização viaja para o domínio dele. Viram item de homologação: registro dos clientes aprovados pelo usuário, endereço de retorno comparado por igualdade exata, sem curinga, e cookie de estado gravado só depois da aprovação. Todo gateway que agrega vários servidores atrás de uma credencial única cai nesse padrão por construção.

Token passthrough, o argumento que convence o jurídico antes da engenharia

Token passthrough (repasse de crachá: usar a credencial emitida para um sistema em outro) ocorre quando o servidor aceita tokens do cliente sem validar que foram emitidos para ele e os repassa adiante. O texto normativo proíbe de forma literal: servidores não devem aceitar token que não tenha sido explicitamente emitido para eles.

Dos três riscos listados, o do meio interessa a quem responde por conformidade. Sem separação de audiência, o registro de acesso do sistema de origem mostra uma origem diferente da real. Investigação de incidente fica inconclusiva e resposta a requisição regulatória fica sem lastro documental. O risco é de conformidade antes de ser técnico, e essa formulação explica à área jurídica por que ela precisa opinar sobre um detalhe de autorização.

Escopo excessivo, e o teste de uma linha que qualquer executivo aplica

A especificação descreve o servidor que publica todos os escopos possíveis e o cliente que pede todos de uma vez, gerando um token com permissões amplas. Os riscos são quatro: raio de explosão maior, revogação traumática, auditoria que mascara a intenção de cada operação e usuário que aceita uma lista longa sem ler.

O modelo recomendado é progressivo, com conjunto mínimo inicial e elevação incremental no momento em que a operação privilegiada é tentada, mecanismo presente desde a revisão 2025-11-25 e mantido na 2026-07-28. Na demonstração do fornecedor, peça a tela de consentimento da primeira conexão. Se ela lista dezenas de permissões antes de qualquer trabalho começar, o token guardado vale mais para um atacante do que precisaria valer.

Execução local, onde a palavra local costuma ser confundida com controle

Um servidor que roda na máquina de quem trabalha executa com os privilégios de quem o chamou. A especificação reconhece a execução arbitrária de comando como risco, exige consentimento prévio com exibição do comando completo sem truncamento e recomenda isolamento com disco e rede restritos.

Uma análise publicada em 15/04/2026 sustenta que esse comportamento decorre de escolha arquitetural presente nas implementações oficiais, e a tese é corroborada pelo texto normativo. Os números divulgados junto com ela, de 150 milhões de downloads e até 200.000 instâncias vulneráveis, ficam de fora: não têm metodologia publicada e conflitam com a medição independente de 28/04/2026, tratada em "Tirar lição dos incidentes que já aconteceram".

Anexe a lista de doze perguntas ao próximo pedido de aprovação de servidor e recuse o pedido que chegar com menos de doze respostas objetivas. Nesta semana, peça ao time técnico a relação de servidores em uso com a versão fixada de cada um; qualquer linha sem versão entra no primeiro passo do guia acima. O capítulo seguinte, "Tirar lição dos incidentes que já aconteceram", mostra quais desses padrões já custaram caro a alguém.