Voltar as noticias
O Registro de Auditoria do Seu Agente de IA é Inútil: Por Que a Detecção Falha
MCP ProtocolAltaEN

O Registro de Auditoria do Seu Agente de IA é Inútil: Por Que a Detecção Falha

Dev.to - MCP·26 de agosto de 2026

O Registro de Auditoria do Seu Agente de IA Não Vale Nada: Por Que a Detecção Falha e O Que Realmente Funciona

Agosto de 2026

Em um período de três semanas, o ecossistema de agentes de IA foi atingido por quatro incidentes separados que deveriam fazer cada equipe de segurança repensar como aborda a observabilidade de agentes:

  1. ataque à cadeia de suprimentos filesystem-pro-plus (6 de ago): Um servidor MCP malicioso foi baixado 14.300 vezes antes que alguém notasse. Ele exfiltrou tokens OAuth, pressionamentos de tecla e dados da área de transferência de 47 organizações confirmadas — incluindo três empresas YC e a implantação interna de um laboratório de modelos de fundação. Foi descoberto através de um despejo no pastebin, não por uma ferramenta de segurança.

  2. RufRoot / CVE-2026-59726 (29 de jul, CVSS 10.0): Ruflo, uma plataforma de agente de código aberto com 67.000 estrelas no GitHub e 10 milhões de downloads, expôs 233 ferramentas via HTTP sem autenticação. Um POST não autenticado permitiu a execução completa de comandos dentro do contêiner.

  3. Microsoft UFO / GHSA-24fq-m9rr-g3mm (10 de ago, CVSS 9.4): Os servidores MCP móveis expuseram funcionalidades Android suportadas por ADB — capturas de tela, injeção de UI, lançamentos de aplicativos — sem qualquer autenticação. Sem chave de API, sem token, sem verificação de cabeçalho.

  4. ataque à cadeia de suprimentos Paperclip (jul): Pacotes com erros de digitação e habilidades de IA armadas acumularam mais de 300.000 instalações. Scanners automatizados detectaram os pacotes Python em poucas horas; as habilidades maliciosas evitaram a detecção completamente.

Esses não são casos extremos. Eles são o novo normal.

O Padrão Que Ninguém Quer Admitir

Cada um desses incidentes compartilha uma falha estrutural: o registro de segurança é produzido pelo mesmo sistema que executou a ação.

Quando seu servidor MCP, tempo de execução do agente ou gateway escreve uma entrada de log dizendo "ferramenta X foi chamada com argumentos Y", esse log é:

  • Escrito pelo sistema que está sendo monitorado
  • Armazenado em uma infraestrutura que o sistema controla
  • Mutável por qualquer um com acesso administrativo
  • Vulnerável à mesma comprometimento que possibilitou o ataque

Esse é o gap de autoatestado, e é estrutural, não uma deficiência de recurso. Nenhuma quantidade de registro, barreiras de proteção ou "detecção de ameaças alimentada por IA" fecha isso de dentro do tempo de execução — porque se o tempo de execução estiver comprometido, o log também está comprometido.

A segurança baseada em detecção responde à pergunta: "Isso parece suspeito?" Ela depende de correspondência de padrões, detecção de anomalias e modelos de ML que produzem pontuações F1 e falsos positivos. Ela perde ataques GhostSplice (onde fragmentos de instrução divididos parecem benignos individualmente, mas se combinam maliciosamente) e captura coisas depois do fato.

O que é necessário é uma pergunta completamente diferente: "Um terceiro pode provar o que este agente realmente fez, sem confiar no sistema que produziu o registro?"

Recibos Criptográficos: Mudando de Detecção para Verificação

Um recibo criptográfico para uma chamada de ferramenta de agente funciona como um recibo em uma loja: é um artefato assinado que você pode entregar a outra pessoa — um auditor, um regulador, um cliente — e eles podem verificá-lo de forma independente, sem confiar nos sistemas internos da loja.

Veja como é um recibo mínimo:

{
  "version": "1.0",
  "action": "send_email",
  "args_digest": "sha256:abc123...",
  "verdict": "allow",
  "timestamp": "2026-08-26T10:00:00Z",
  "issuer": "payments-agent-01",
  "signing_algorithm": "Ed25519",
  "public_key": "base64...",
  "signature": "base64...",
  "prev_receipt_digest": "sha256:def456...",
  "attempt_id": "urn:uuid:..."
}

Os princípios de design:

O algoritmo está dentro da carga útil assinada. Um atacante não pode rebaixar Ed25519 para "nenhum" porque o campo do algoritmo é parte do que é assinado. Isso previne ataques de substituição de algoritmo.

A chave pública está embutida no recibo. Um atacante não pode assinar com sua própria chave e apresentá-la como o emissor legítimo — a chave embutida não corresponderia. Isso previne a substituição de chave.

Argumentos são hashados, não armazenados. O args_digest é um hash SHA-256 dos argumentos JSON canônicos. Se alguém modificar um único argumento após a assinatura, o digest muda e a verificação falha. Isso previne a adulteração de parâmetros sem expor valores de argumento potencialmente sensíveis.

Recibos são encadeados por hash. Cada recibo inclui prev_receipt_digest, criando uma cadeia à prova de adulteração. Você não pode excluir ou reordenar um recibo sem quebrar a cadeia.

JSON canônico torna a ordem dos campos irrelevante. Usando o Esquema de Canonização JSON RFC 8785 (JCS), o mesmo objeto lógico produz os mesmos bytes, independentemente da ordem das chaves. Um objeto JSON reordenado ainda verifica — o que é correto, porque reordenar chaves não muda a ação.

A verificação não requer chamadas de rede e nenhum terceiro confiável. Dado um recibo e a chave pública do signatário, qualquer um pode verificá-lo usando apenas Ed25519 e SHA-256 padrão — ambos disponíveis na biblioteca criptográfica padrão de cada linguagem de programação.

Como Isso Teria Ajudado nos Incidentes de Agosto

filesystem-pro-plus: Se o tempo de execução do agente assinasse cada chamada de ferramenta com uma chave que o servidor MCP não pudesse acessar, as leituras de arquivo não autorizadas e a exfiltração de tokens OAuth do servidor malicioso produziria recibos assinados pela chave legítima do agente — mas com valores de args_digest que não correspondem a nenhum fluxo de trabalho autorizado. Um verificador externo sinalizaria a anomalia imediatamente. O atacante não poderia suprimir ou forjar recibos porque não possui a chave de assinatura.

RufRoot: Com recibos criptográficos, mesmo um atacante não autenticado alcançando a ponte MCP não poderia produzir recibos válidos para seus comandos arbitrários. Cada chamada de ferramenta requer uma assinatura da chave do agente, que o atacante não possui. O comando é executado, mas não produz recibo válido — o que é em si um evento detectável.

UFO: Mesmo princípio...

Contexto Triplo Up

As falhas de segurança em agentes de IA podem impactar diretamente empresas brasileiras, comprometendo dados sensíveis e a confiança do cliente. A implementação de recibos criptográficos pode aumentar a segurança e a transparência nas operações, essencial para a conformidade regulatória.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.