🤖 AI

Oracle Poisoning: Corrupting Knowledge Graphs to Weaponise AI Agent Reasoning

Este artigo introduz e valida empiricamente o "Envenenamento de Oráculo", um vetor de ataque inovador no qual adversários corrompem grafos de conhecimento estruturados para forçar agentes de IA a tirar conclusões incorretas por meio de raciocínio, de outro modo, sólido, demonstrando que os modelos atuais confiam universalmente em dados envenenados quando acessados por meio de protocolos de uso de ferramentas e destacando lacunas críticas de avaliação nos testes inline.

Autores originais: Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Publicado 2026-05-12

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Ideia Central: A Armadilha do "Bibliotecário Confiável"

Imagine que você tem um assistente de IA brilhante (o "Agente") que ajuda você a escrever código ou verificar falhas de segurança. Este assistente é incrivelmente inteligente e raciocina perfeitamente. No entanto, ele tem uma fraqueza major: ele é cego para o mundo exterior.

Para realizar seu trabalho, a IA depende inteiramente de uma biblioteca digital massiva e estruturada chamada Grafo de Conhecimento. Pense neste grafo como um mapa gigante de toda a sua base de código de software, mostrando como cada pedaço de código se conecta a todos os outros.

A IA trata este mapa como um Oráculo—uma fonte de verdade absoluta. Ela não questiona o mapa; ela assume que o mapa é 100% preciso. Se o mapa diz "A Função A chama a Função B", a IA acredita nisso sem verificar uma segunda fonte.

Oracle Poisoning (Envenenamento de Oráculo) é o ataque onde um agente malicioso se infiltra na biblioteca e altera o mapa. Eles não quebram o cérebro da IA; não enganam a IA com palavras confusas. Em vez disso, alteram silenciosamente os fatos no mapa. Como a IA é tão boa em raciocinar, ela pega esses novos fatos falsos e chega a uma conclusão perfeitamente lógica—mas completamente errada.

A Analogia: A Caverna de Platão e a Parede de Sombras

Os autores comparam isso à Caverna de Platão.

O Prisioneiro: O Agente de IA.
A Parede: O Grafo de Conhecimento.
As Sombras: As respostas que a IA obtém quando faz perguntas ao grafo.
A Corrente: O protocolo (chamado MCP) que prende a IA à parede, forçando-a a aceitar as sombras como realidade.

Se um atacante pintar uma sombra falsa na parede, o prisioneiro (a IA) estudará isso, analisará perfeitamente e concluirá: "Isso é um tigre real", mesmo sendo apenas uma pintura. Quanto mais inteligente for o prisioneiro, mais detalhada e convincente será sua conclusão errada.

Como o Ataque Funciona (O "Como Fazer")

Os pesquisadores testaram isso em um sistema do mundo real com 42 milhões de nós (uma biblioteca digital massiva). Eles descobriram que um atacante só precisa fazer mudanças minúsculas e cirúrgicas no mapa para enganar a IA.

Eles demonstraram seis maneiras de fazer isso:

O Pacote Falso: Criar um pacote de software falso na biblioteca que parece ser a "versão mais recente e mais segura", enganando a IA para recomendá-lo.
O Sanitizador Invisível: Adicionar uma função falsa de "guarda de segurança" ao mapa que não existe realmente no código real. A IA vê isso no mapa e conclui: "Ah, este código é seguro!", quando na verdade é vulnerável.
A Troca de Propriedade: Alterar os detalhes de um pedaço real de código no mapa (por exemplo, mudar um rótulo de "não verificado" para "aprovado pela segurança") sem criar um novo item falso.

O Resultado: A IA, raciocinando perfeitamente com base nos novos dados, diz confiantemente aos desenvolvedores: "Este código é seguro" ou "Use esta nova biblioteca", levando-os diretamente para uma armadilha.

A "Sofisticação" do Atacante

O artigo descobriu algo surpreendente: Você não precisa ser um hacker gênio para realizar isso.

Nível 0 (Inocente): Se os dados falsos parecem suspeitos (por exemplo, nomeados como "ferramenta_hacker_v1"), a IA os ignora.
Nível 1 (Básico): Se parecem ok, mas têm pequenos erros, a IA às vezes é enganada.
Nível 2 (Competente): Se os dados falsos seguem regras de nomenclatura padrão e parecem profissionais, 100% dos modelos de IA testados foram completamente enganados.

Não é uma questão de se a IA pode ser enganada, mas quanto esforço o atacante precisa gastar. Um atacante competente pode enganar até os modelos de IA mais inteligentes 100% das vezes.

A Surpresa do "Modo de Entrega"

Os pesquisadores descobriram uma falha crítica em como geralmente testamos a segurança de IA.

Teste Inline: Se você mostrar os dados falsos à IA como uma simples mensagem de texto, alguns modelos (como GPT-5.1) dizem: "Isso parece suspeito" e rejeitam.
Teste de Uso de Ferramentas: Se a IA recebe os mesmos dados falsos através de sua conexão oficial de "ferramenta" (a maneira como funciona na vida real), ela confia 100%.

A Lição: Testar a segurança de IA apenas conversando com ela (inline) dá uma falsa sensação de segurança. Quando a IA usa suas ferramentas para consultar dados, ela abaixa completamente a guarda.

Como se Defender Contra Isso

O artigo testou várias defesas e descobriu que nenhuma "bala de prata" única funciona, mas uma combinação ajuda:

Acesso Somente Leitura (A Melhor Defesa): Se você bloquear o Grafo de Conhecimento para que a IA (e o atacante) possa apenas ler o mapa, mas nunca escrever nele, o ataque é impossível. Este é o reparo mais eficaz.
Verificação Cruzada: Se a IA for forçada a verificar o mapa contra uma segunda fonte (como os arquivos de código reais), ela pode detectar a mentira. Se o mapa diz "Seguro" mas o arquivo de código diz "Vulnerável", a IA fica confusa e para de confiar no mapa.
O "Advogado do Diabo": Perguntar à IA: "Esses dados poderiam ser falsos?" ajuda, mas apenas se você for muito específico sobre como eles poderiam ser falsos. Apenas perguntar "Você tem certeza?" geralmente não funciona.
Rastreamento de Histórico: Manter um registro do que mudou no mapa ajuda a detectar novos itens falsos, mas falha em pegar quando um atacante simplesmente edita os detalhes de um item existente.

Resumo

Oracle Poisoning é um novo tipo de hack onde o atacante corrompe os dados que a IA confia, não a própria IA. Como a IA é tão boa em seguir a lógica, ela alegremente constrói um castelo de cartas sobre uma fundação de mentiras. O artigo prova que, em um cenário do mundo real, quase todos os modelos de IA testados acreditarão nessas mentiras se elas chegarem através de um canal de ferramenta confiável, e o único reparo confiável é impedir que a IA possa escrever em sua própria base de conhecimento.

Resumo Técnico: Envenenamento de Oracle – Corrompendo Grafos de Conhecimento para Armar o Raciocínio de Agentes de IA

Definição do Problema

O artigo introduz o Envenenamento de Oracle, uma nova classe de ataque direcionada a agentes de IA que dependem de grafos de conhecimento (KGs) estruturados como fontes de dados confiáveis por meio de protocolos de uso de ferramentas (especificamente o Protocolo de Contexto do Modelo, ou MCP). Diferente da injeção de prompt, que manipula as instruções de um agente, ou do envenenamento de RAG, que corrompe corpora de recuperação, o Envenenamento de Oracle corrompe os dados em si.

A vulnerabilidade central reside no "modelo de confiança do oráculo": agentes de IA tratam os resultados de consultas de um grafo de conhecimento como verdade absoluta, raciocinando a partir desses fatos sem verificação independente. Um adversário que possa modificar o grafo (inserindo nós, criando arestas ou alterando propriedades) pode fazer com que um agente execute raciocínio lógico e coerente baseado em fatos fabricados, levando a conclusões incorretas e potencialmente perigosas. Este ataque distingue-se de trabalhos anteriores sobre envenenamento no espaço de incorporação (por exemplo, ROAR), pois visa estruturas de grafos brutas consultadas diretamente por meio de linguagens como Cypher, contornando completamente as camadas de incorporação.

Metodologia

Os autores conduziram a primeira demonstração empírica deste ataque contra um grafo de conhecimento de código em escala de produção contendo aproximadamente 42 milhões de nós.

Modelo do Sistema: Um grafo de conhecimento Neo4j 5.x conectado a agentes de IA via MCP v1.0. O grafo codifica cadeias de chamadas de função, dependências e telemetria.
Perfil do Atacante: Um insider com acesso de escrita ao banco de dados do grafo (frequentemente devido a sessões de banco de dados compartilhadas que carecem de RBAC por usuário) ou um atacante externo comprometendo o pipeline de ingestão.
Vetores de Ataque: Seis cenários foram projetados:
1. Fork-for-a-Package: Criar nós de pacotes falsos para sugerir bibliotecas maliciosas como versões "mais recentes".
2. Cadeia de Dependência Transitiva: Fabricar caminhos de dependência para legitimar bibliotecas maliciosas.
3. Evasão de Segurança do Grafo de Chamadas: Inserir sanitizadores de segurança inexistentes em grafos de chamadas para convencer os agentes de que vulnerabilidades estão mitigadas.
4. Redirecionamento de Telemetria: Modificar arestas de telemetria para ocultar eventos de segurança.
5. Envenenamento de Geração de Código: Plantar padrões de código vulneráveis como "melhores práticas estabelecidas".
6. Modificação de Propriedades: Alterar propriedades em nós legítimos existentes (por exemplo, alterar sanitizationType para "conforme OWASP") sem criar novos nós.
Protocolo de Avaliação:
- Modelos: Nove modelos de três provedores (OpenAI, Anthropic, Google) testados com $N=30$ tentativas por modelo.
- Modos de Entrega: A avaliação principal utilizou uso real de ferramentas SDK (invocação autônoma de agente), com entrega de texto inline secundária para comparação controlada.
- Níveis de Sofisticação: Os ataques variaram de L0 (ingênuo) a L3 (especialista), com L2 representando um atacante competente usando convenções de nomenclatura corretas e referências OWASP.
- Métricas: Taxas de confiança (aceitação de dados envenenados), gradientes de sofisticação do atacante e eficácia de defesa.

Resultados Principais

1. Suscetibilidade Universal sob Uso de Ferramentas

Sob uso real de ferramentas SDK com sofisticação moderada do atacante (L2), todos os modelos testados confiaram nos dados envenenados em 100%.

269 de 270 tentativas válidas aceitaram alegações de segurança fabricadas (por exemplo, confirmando que injeção SQL foi mitigada quando não foi).
Este resultado manteve-se em todos os nove modelos e em dois cenários de ataque distintos (Squatting de Pacotes e Evasão de Grafo de Chamadas).
Modificação de Propriedades (Cenário 6) foi particularmente eficaz, alcançando confiança quase universal (96,6–100%) mesmo quando o histórico do grafo foi preservado, pois os modelos interpretaram as alterações de propriedade como atualizações normais de software.

2. O Conflito do Modo de Entrega

Uma descoberta crítica é que avaliação inline produz falsos negativos para modelos específicos.

GPT-5.1 mostrou 0% de confiança quando dados envenenados foram apresentados como texto inline, mas 100% de confiança quando entregues via uso real de ferramentas agênticas.
Isso indica que o canal de confiança (resposta de ferramenta MCP) reduz significativamente o limiar de ceticismo do agente em comparação com entrada de texto direta. Avaliações inline podem subestimar a suscetibilidade agêntica.

3. Gradiente de Sofisticação do Atacante

O ataque exibe um "ponto de ruptura" discreto.

L0/L1 (Ingênuo/Básico): As taxas de confiança foram baixas (0–32%).
L2 (Competente): As taxas de confiança saltaram para 100% para todos os modelos sob uso de ferramentas.
Isso reenquadra o ataque: não é uma questão de se um modelo pode ser enganado, mas do esforço mínimo necessário. Um atacante competente (L2) é suficiente para comprometer qualquer modelo testado.

4. Avaliação de Defesa (Framework VUT)

Os autores avaliaram defesas sob um framework Visibilidade–Compreensão–Rastreabilidade (VUT):

Visibilidade (Histórico do Grafo): Eficaz contra criação de nós (agentes sinalizaram novos nós), mas ineficaz contra modificação de propriedades (agentes aceitaram alterações como atualizações válidas).
Compreensão (Debate/Verificação):
- Advogado do Diabo Nomeado: Altamente eficaz sob uso de ferramentas SDK (taxa de captura de 96,7–100%), mas menos eficaz inline.
- Advogado do Diabo Cego: Operacionalmente inútil (taxa de captura igual à taxa de falso positivo).
- Endurecimento de Prompt do Sistema: Teve zero efeito; agentes reconheceram instruções, mas ainda confiaram nos dados.
- Verificação Cruzada Multi-ferramenta: A defesa arquitetônica mais eficaz. Quando os agentes puderam cruzar referências do KG com uma ferramenta de busca de código-fonte, a confiança cega colapsou de 100% para 0–25%.
Rastreabilidade (Controle de Acesso): Controle de acesso somente leitura para sessões MCP foi a única defesa que eliminou completamente o vetor de mutação direta, independentemente do modelo utilizado.

Significância e Alegações

O artigo afirma fornecer a primeira demonstração empírica de envenenamento de grafo de conhecimento contra um sistema agêntico em escala de produção (42M de nós). Sua significância reside em:

Definir uma Nova Classe de Ataque: O Envenenamento de Oracle distingue-se de injeção de prompt, envenenamento de RAG e envenenamento de dados em tempo de treinamento. Ele explora a confiança em tempo de inferência em resultados de consultas estruturadas entregues via uso de ferramentas.
Realidade em Escala de Produção: Diferente de estudos anteriores baseados em laboratório, este ataque foi demonstrado em um sistema ao vivo, de nível empresarial, provando que a vulnerabilidade não é teórica, mas explorável em ambientes do mundo real.
Vulnerabilidade Arquitetural: O ataque explora uma premissa arquitetônica fundamental (confiança em fontes de dados) em vez de um bug de implementação específico. Os pré-requisitos estruturais (acesso de escrita, falta de proveniência, confiança em resultados) persistem em múltiplas plataformas (Sourcegraph, Semgrep, CodeQL, Qodana), sugerindo que o risco é sistêmico ao ecossistema de grafos de conhecimento.
Correção Metodológica: O artigo argumenta que avaliações de segurança para agentes de IA devem ir além de testes de texto inline para pipelines reais de uso de ferramentas, pois o modo de entrega é um confundidor de primeira ordem que pode mascarar vulnerabilidades críticas.

Os autores concluem que, embora nenhuma defesa única seja uma "bala de prata", uma abordagem em camadas combinando controle de acesso somente leitura (Rastreabilidade), verificação cruzada multi-ferramenta (Compreensão) e registro de auditoria (Visibilidade) é necessária para mitigar o risco.