Uma vez que o RAG ancora as saídas do LLM em bases de conhecimento externas, o próprio corpus torna-se uma superfície de ataque. As cinco imersões profundas anteriores de segurança LLM atacaram a entrada (8 tipos de injeção), a chamada (8 tipos de escalonamento), a superfície de ferramentas (8 tipos de envenenamento), a saída (8 tipos de vazamento) e a persistência de memória (8 tipos de envenenamento). Este artigo é a sexta dimensão — camada de persistência de corpus / base de conhecimento — imersão profunda vertical, transformando o “envenenamento de corpus” de um termo de paper em um manual de ataque e defesa acionável em produção.

A similaridade e diferença entre ataques ao corpus e ataques à memória: ambos são “persistentes”, mas o corpus é fonte de fato compartilhada em nível empresarial (correspondências de retrieval RAG afetam todos os usuários, todas as consultas); a memória é estado local de auto-aprendizado do agente (afeta apenas uma única instância de agente). O paper RAGShield revela um ponto de dado crítico: 10 passages maliciosos (0.04% do corpus) podem alcançar uma taxa de sucesso de retrieval de 98.2% — uma injeção de corpus pode afetar permanentemente todas as saídas de consultas futuras.

Visão geral de 30 segundos

  • O corpus RAG é a superfície de ataque persistente de sexta dimensão da era LLM — OWASP LLM Top 10 2026 (lançado em 9-1) lista envenenamento de corpus na categoria principal; Agentic Top 10 2026 ASI04 Agentic Supply Chain mapeia diretamente
  • 8 variantes de envenenamento de corpus (progredindo pelo ciclo de vida do corpus: fonte de dados → ingestion → armazenamento → retrieval → efeito de saída): injeção direta de passage malicioso / poluição indireta de fonte confiável / squatting de nome de corpus com homoglyphs / inversão de embedding / envenenamento GraphRAG / RAG multi-modal / acumulação de loop de feedback de retreinamento / colisão de nome de pacote de supply chain
  • 5 incidentes/papers reais de 2026: RAGShield RAG governamental 10 passages 0.04% → 98.2% retrieval success, Phantom attack mesmo ponto de dado, PoisonedRAG 5 passages → 90%+ ASR em NQ/HotpotQA/MS-MARCO, envenenamento GraphRAG ACL 2026, defesa SDAG block-sparse attention
  • Plano de defesa de 7 dias (cada um ≤ 30 minutos para começar): whitelist de fonte de corpus + assinatura digital / detecção de drift de embedding / pipeline provenance-verified / isolamento block-sparse attention / consistência hop-wise de GraphRAG / hashing de conteúdo multi-modal / scoring de retriever + LLM-as-judge / provenance de supply chain de corpus
  • Use o conjunto de ferramentas Piick para depurar tokens, URLs, regex e payloads codificados no lado do corpus RAG — todas as ferramentas rodam 100% localmente e nunca são enviadas, mantendo seu log de auditoria limpo

Por que o corpus RAG é a superfície de ataque de sexta dimensão na era do LLM

Para entender por que as 8 variantes de envenenamento de corpus funcionam, volte à essência do RAG: saída do LLM = retrieval(query) + LLM(prompt + retrieved context). Tudo o que o LLM vê como “fato” vem do retrieval do corpus; se o corpus está envenenado, a saída do LLM está envenenada.

Raio de explosão do ataque ao corpus:

O corpus é fonte de fato compartilhada em nível empresarial — uma injeção, afeta todas as consultas futuras, todos os usuários O retrieval do corpus não distingue “passage confiável vs passage de ataque” — apenas verifica similaridade de embedding A auto-ingestão do corpus puxa conteúdo externo — wiki / doc / issue de GitHub / comentários de blog, auto-adicionados ao repositório O supply chain do corpus é complexo — loader / connector / package / embedding model / vector DB, cada elo é atacável

arxiv 2604.00387 RAGShield validou empiricamente: 10 passages maliciosos (0.04% corpus) alcançam 98.2% retrieval success (o ponto de dado de Phantom attack coincide); PoisonedRAG 5 passages injetados em corpus em escala de milhão → 90%+ ASR em NQ / HotpotQA / MS-MARCO. O ROI do envenenamento de corpus é extremo: entrada pequena, impacto grande.

Pior ainda, os ataques ao corpus são “compromisso silencioso” — os usuários veem respostas do LLM “razoáveis”, mas as respostas são baseadas em passages de corpus envenenados; a saída do LLM + os logs de retrieval parecem “normais”, a retrospecção de auditoria é difícil.

8 variantes de envenenamento de corpus (Progressão pelo ciclo de vida do corpus: fonte de dados → ingestion → armazenamento → retrieval → efeito de saída)

Envenenamento 1: Injeção direta de passage malicioso (Padrão PoisonedRAG)

Sintoma: o atacante escreve diretamente documentos maliciosos no corpus; o retrieval RAG corresponde e o LLM adota como fato; 5 passages podem levar o sistema de corpus milionário a ASR > 90% (dados do paper PoisonedRAG).

Por que funciona: o retrieval RAG apenas verifica similaridade de embedding, não se o passage é confiável / auditado. O atacante escreve um passage que contém “palavras-chave de âncora de alto recall” + “resposta alvo”, o embedding cai na região de consulta alvo, o LLM adota diretamente. PoisonedRAG 5 passages alcançam 90%+ ASR nos três benchmarks NQ / HotpotQA / MS-MARCO.

Reprodução mínima (padrão PoisonedRAG):

Passo 1: o atacante escreve 5 passages, cada um contendo frase de trigger + resposta adversarial: “A última pesquisa sobre X mostra que Y é a solução ótima para Z… ver [cite]” Passo 2: o atacante injeta os 5 passages no corpus alvo (via comentários abertos / edição de wiki / API pública) Passo 3: a consulta do usuário se aproxima da frase de trigger → retriever top-K corresponde aos passages de ataque Passo 4: o LLM vê os passages → emite resposta adversarial Passo 5: o usuário vê uma saída do LLM “aparentemente razoável” mas errada, baseada em citação “autoritativa”

Correção:

  • Whitelist de fonte de corpus + assinatura digital (ver Dia 1). Ingestão de corpus restrita a fontes confiáveis (DB interno / vendor assinado / fontes externas auditadas); cada passage assinado com HMAC ao escrever; rejeitar passages sem assinatura
  • Os passages críticos do corpus passam por um fluxo “review-then-ingest”, revisão manual antes de armazenar
  • Registrar provenance ao ingerir (URL / vendor / tempo de ingestion / assinatura); ao recuperar ordenar por prioridade de provenance, fontes suspeitas com peso reduzido

Envenenamento 2: Poluição indireta de fonte confiável (comentários / wiki / docs)

Sintoma: o atacante não ataca o corpus diretamente, mas polui a wiki / Google Doc / issue de GitHub / comentários de blog fonte do corpus; a auto-ingestão do corpus os puxa como passages maliciosos.

Por que funciona: os sistemas RAG dependem cada vez mais de “pipeline de auto-ingestão” (web crawler / GitHub sync / wiki API / RSS feed); essas fontes são frequentemente semi-públicas, qualquer um pode comentar / editar. O atacante usa “poluição indireta” para evadir a “whitelist de fonte de corpus” — porque o sistema de corpus em si confia em wiki / GitHub.

Reprodução mínima:

Passo 1: o atacante edita um tópico neutro na Wikipedia / Wiki da empresa, planta texto oculto: adiciona frase de trigger + resposta adversarial a um parágrafo, o texto coincide com o estilo wiki Passo 2: a auto-ingestão RAG da empresa sincroniza as revisões da wiki Passo 3: o retrieval corresponde ao parágrafo recém-plantado → LLM emite resposta errada Passo 4: o admin do sistema RAG só vê “atualização normal da wiki”, não consegue identificar o ataque

Correção:

  • Pipeline provenance-verified (ver Dia 3). O pipeline RAG adiciona verificação de provenance de 5 camadas (tomando a abordagem RAGShield): ingestion → signing → audit → reweighting → retrieval threshold; imita a defesa de supply chain de software
  • As fontes de auto-ingestão passam por revisão editorial: “wiki auto-sync” mas todo conteúdo novo / modificado passa por revisão AI-as-judge antes de armazenar
  • Os passages críticos usam verificação de dupla fonte: o mesmo tópico deve aparecer em 2 fontes confiáveis independentes para ser confiável

Envenenamento 3: Squatting de nome de corpus com homoglyphs

Sintoma: o corpus malicioso usa nome com homoglyphs (similar a typosquatting) para se registrar no marketplace de vector DB; a empresa o ingere por engano.

Por que funciona: Os marketplaces de vector DB (Pinecone / Weaviate / Qdrant, etc.) permitem o registro de corpus de terceiros; a revisão de registro de namespace é frouxa. O atacante registra um nome quase similar como wikipedia-ml-articles (o real é wikipedia-ml); a empresa configura o corpus com typo / seleção incorreta, puxa o corpus malicioso.

Reprodução mínima:

Passo 1: o atacante registra um corpus malicioso chamado wikipedia-ml-articles no marketplace (o real é wikipedia-ml) Passo 2: o engenheiro RAG da empresa configura o corpus com typo para wikipedia-ml-articles Passo 3: o corpus é puxado → passages maliciosos misturados Passo 4: o retrieval corresponde ao passage malicioso → a saída do LLM está contaminada

Correção:

  • Whitelist de fonte de corpus + assinatura digital (ver Dia 1). O registro de corpus deve ser assinado, o conteúdo do corpus deve ter manifesto assinado; apenas whitelist pode ingerir corpus
  • O corpus crítico usa “verificação de checksum”: verificar periodicamente que o hash do conteúdo do corpus bate com o oficial
  • Monitorar anomalias na distribuição de fontes do corpus: pico na quota de um corpus → alerta

Envenenamento 4: Inversão de embedding para reverter consultas

Sintoma: os vetores de embedding de passages no corpus são atacados por inversão → o atacante reverte o embedding ao conteúdo da consulta original, vazando privacidade do usuário.

Por que funciona: A vector DB armazena vetores de embedding de passages; os embeddings parecem “anonimizados”, mas a pesquisa prova que você pode inverter o texto original (conteúdo de consulta / passage) a partir de embeddings com alta precisão. O atacante obtém o despejo de embeddings do corpus → reverte o histórico de consultas do usuário.

Reprodução mínima:

Passo 1: o atacante obtém o despejo da vector DB (vazamento / excesso de privilégios) Passo 2: usa modelo de inversão treinado para reverter o embedding do passage ao texto do passage Passo 3: os passages revertidos contêm informação sensível (consulta do usuário / resumo de documento interno) Passo 4: o atacante emenda o histórico completo de consultas do usuário, vaza conhecimento empresarial

Correção:

  • Detecção de drift de embedding (ver Dia 2). Passages que mutam embedding → alerta + revisão manual; comparação periódica de hash de embeddings do corpus, qualquer modificação deixa log de auditoria
  • Os passages críticos usam embedding criptografado: criptografado no armazenamento, descriptografado no retrieval, mesmo o despejo não consegue recuperar o texto original
  • Controle de acesso: a API de vector DB aplica mTLS + token TTL curto, minimizar janela de vazamento

Envenenamento 5: Envenenamento de knowledge-graph GraphRAG (ACL 2026)

Sintoma: GraphRAG injeta entidades e relações espurias durante a construção do grafo; contamina o subgrafo específico de consulta → o LLM gera respostas erradas.

Por que funciona: GraphRAG constrói o corpus em um knowledge graph, depois usa travessia de grafo para retrieval. A fase de construção do grafo é a janela de ataque — o atacante escreve entidades + relações falsas, a construção do grafo as auto-inclui. A travessia do grafo em tempo de consulta atinge nós falsos → o LLM vê contexto falso → emite resposta errada. O paper ACL 2026 HoG-GRAG validou empiricamente: o subgrafo de GraphRAG é uma nova superfície de ataque.

Reprodução mínima (padrão GraphRAG ACL 2026):

Passo 1: o atacante escreve um passage malicioso alegando uma entidade falsa “HyperTransport Protocol v2” Passo 2: a fase de construção de GraphRAG adiciona a entidade falsa ao grafo Passo 3: consulta do usuário “transport protocols for high-speed networking” Passo 4: a travessia do grafo atinge a entidade falsa “HyperTransport Protocol v2” Passo 5: o LLM emite uma resposta “autoritativa” baseada na entidade falsa

Correção:

  • Verificação de consistência hop-wise de GraphRAG (ver Dia 5). GraphRAG decompõe a consulta multi-hop em subconsultas ordenadas; verificação de consistência após cada hop; inconsistência induzida por envenenamento → acionar reparo do subgrafo (podar entidades + relações comprometidas)
  • As entidades críticas usam verificação de dupla fonte: cada entidade deve ter suporte de 2 fontes independentes
  • A construção do grafo passa por human-in-the-loop: nova entidade / relação requer revisão manual

Envenenamento 6: Envenenamento RAG multi-modal (passage de imagem / PDF / audio)

Sintoma: o corpus contém passages multi-modais; o atacante usa esteganografia de imagem / PhantomText de PDF / payload de ataque codificado em audio.

Por que funciona: o corpus RAG moderno não é apenas texto, frequentemente contém passages de imagem / PDF / audio. OCR / extração de texto de PDF / transcrição de audio têm padrões de ataque conhecidos — os atacantes usam esteganografia de imagem para esconder prompts, camada de texto oculta em PDF, instruções maliciosas codificadas em audio. O retrieval RAG converte passage multi-modal em texto, o LLM vê texto que contém o ataque.

Reprodução mínima (padrão PhantomText):

Passo 1: o atacante cria um PDF, o texto visível parece normal Passo 2: a camada de texto oculta do PDF contém frase de trigger + resposta adversarial (texto branco / tamanho 0 / fora da tela) Passo 3: o PDF é ingerido no corpus RAG Passo 4: a extração de texto do PDF também extrai o texto oculto (extract-all por padrão) Passo 5: o LLM vê o texto oculto → emite resposta adversarial

Correção:

  • Hashing de conteúdo multi-modal (ver Dia 6). Os passages de imagem / PDF / audio no corpus são hasheados + escaneados com OCR visual em busca de payload de ataque antes de armazenar; padrões de ataque como PhantomText pré-detectados
  • As ferramentas de extração multi-modal (OCR / pdftotext) usam safe-config: modo visible-only / strip-hidden
  • Os passages multi-modais passam por detecção adversarial-robust: usar modelo dedicado para escanear payload de ataque

Envenenamento 7: Acumulação de loop de feedback de retreinamento contínuo

Sintoma: o mecanismo de feedback de usuário do corpus é abusado — o atacante “reporta” repetidamente um passage como errado, acionando retreinamento → gradualmente acumulando passages de ataque como autoritativos.

Por que funciona: os sistemas RAG frequentemente vêm com mecanismo de “feedback de usuário” — os usuários marcam passage como útil / não útil, o sistema usa o feedback para retreinar o modelo de embedding ou os pesos de re-rank. O atacante marca repetidamente um passage de ataque como “útil”, o sistema ajusta embedding / re-rank → o passage de ataque acumula mais hits de retrieval → loop de auto-reforço.

Reprodução mínima:

Passo 1: o atacante escreve um passage rico em triggers + simula N contas de usuário marcando repetidamente “útil” Passo 2: o sistema retreina → o embedding do passage de ataque se ajusta, o peso de re-rank aumenta Passo 3: as consultas reais subsequentes do usuário → a probabilidade de correspondência do retriever para o passage de ataque aumenta Passo 4: o loop de ataque continua por meses, o peso do passage de ataque se acumula até ser não desprezível Passo 5: o corpus se contamina continuamente, o admin não vê nada anormal (dados de feedback “normais”)

Correção:

  • Scoring de retriever + LLM-as-judge (ver Dia 7). O retriever pontua top-K retrieval; LLM-as-judge revisa por segunda vez top-K em busca de padrões de ataque
  • O mecanismo de feedback passa por detecção de anomalias: mesmo user agent com feedback massivo em pouco tempo → rate limit
  • A lógica de retreinamento deve ter “sanity check bidirecional”: o ajuste de embedding dirigido por feedback não pode mudar significativamente a distribuição de retrieval top-K, caso contrário reverter

Envenenamento 8: Colisão de nome de pacote de supply chain (Agentic ASI04)

Sintoma: o pacote / connector / loader da ingestão do corpus é substituído (ataque de supply chain); o loader em si escreve passages maliciosos no repositório.

Por que funciona: a ingestão RAG geralmente depende de pacotes externos: web crawler (scrapy / playwright) / connector (confluence / notion / slack) / loader (unstructured / langchain) / embedding model. Qualquer um comprometido, todo o corpus se contamina. OWASP Agentic Top 10 2026 ASI04 Agentic Supply Chain Vulnerabilities mapeia diretamente.

Reprodução mínima:

Passo 1: o atacante registra um nome de pacote typosquatting unstructured-loader (o real é unstructured) Passo 2: o desenvolvedor pip install com typo → instala pacote malicioso Passo 3: a ingestão RAG o usa para parsear documentos → cada documento planta secretamente passage de ataque Passo 4: o corpus se contamina gradualmente, sem anomalia óbvia Passo 5: o ataque continua por meses, o corpus continuamente tem passages maliciosos plantados

Correção:

  • Verificação de provenance de supply chain de corpus (ver Dia 7). As ferramentas de ingestão de corpus (loader / connector / package) passam por verificação de provenance de supply chain (assinatura + identidade do publicador + SBOM); detecção de typosquatting
  • Os pacotes críticos usam versão pinada + verificação de assinatura; lock file forçado
  • O gerenciamento de pacotes usa mirror empresarial (Sonatype Nexus / JFrog), escaneamento de segurança antes do mirror

5 incidentes / papers reais de 2026

Incidente 1: RAGShield RAG governamental (arxiv 2604.00387, 2026-04-01)

Resumo do paper: os sistemas RAG governamentais enfrentam envenenamento de corpus, simula 6 tiers de ataque (T1 injeção externa → T2 falsificação de assinatura → T3 ameaça interna → T4 vulnerabilidade de loader → T5 evasão adaptativa → substituição in-place). Dado chave: 10 passages maliciosos (0.04% corpus) 98.2% retrieval success (o ponto de dado de Phantom attack); propõe defense-in-depth de 5 camadas (analogia com supply chain de software).

Conclusão central: o envenenamento de corpus RAG é estruturalmente similar aos ataques de supply chain de software, requerendo defesa provenance-verified. Corresponde diretamente ao Foot-Gun 1 + Foot-Gun 8.

Incidente 2: Phantom Attack (H1 2026, Chaudhari et al.)

Descrição do ataque: valida empiricamente 10 passages adversariais (0.04% do corpus) 98.2% taxa de sucesso de retrieval; injeção mínima, impacto máximo.

Conclusão central: o ROI do envenenamento de corpus é extremo — volume pequeno de ataque, dano grande. Corresponde diretamente ao Foot-Gun 1.

Incidente 3: Caso clássico PoisonedRAG (NQ / HotpotQA / MS-MARCO)

Resumo do paper: 5 textos maliciosos injetados em corpus em escala de milhão → 90%+ ASR em 3 datasets de benchmark; definiu o paradigma completo de ataque de envenenamento de corpus RAG.

Conclusão central: PoisonedRAG é o “paper fundador” do envenenamento de corpus, 5 passages alcançando 90%+ ASR define o teto de ROI dos ataques ao corpus. Corresponde diretamente ao Foot-Gun 1 + Foot-Gun 2.

Incidente 4: Envenenamento GraphRAG ACL 2026 (defesa HoG-GRAG)

Resumo do paper: GraphRAG injeta entidades + relações espurias durante a construção do grafo → contamina o subgrafo específico de consulta → o LLM gera respostas erradas. A defesa HoG-GRAG (hop-wise guard) decompõe a consulta multi-hop em subconsultas ordenadas, monitorando a execução hop-wise em busca de inconsistências.

Conclusão central: o subgrafo de GraphRAG é uma nova superfície de ataque para envenenamento de corpus, a verificação de consistência hop-wise é atualmente a única defesa efetiva. Corresponde diretamente ao Foot-Gun 5.

Incidente 5: Defesa SDAG block-sparse attention (arxiv 2602.04711 v3, 2026-08-26)

Resumo do paper: Sparse Document Attention RAG; block-sparse attention bloqueia o cross-attention entre documentos recuperados; a máscara de atenção restringe cada documento a se ver apenas a si mesmo + a consulta. A v3 integra SDAG + RobustRAG / ReliabilityRAG com desempenho melhorado significativamente.

Conclusão central: elimina o ataque de envenenamento cross-document desde a camada de inferência, sem necessidade de detectar conteúdo do corpus, isola o ataque por mecanismo. Corresponde diretamente ao Foot-Gun 1 + Foot-Gun 2 defesa.

Plano de defesa de 7 dias

Dia 1 — Whitelist de fonte de corpus + assinatura digital (15 minutos para começar)

  • Ingestão de corpus restrita a fontes confiáveis (DB interno / vendor assinado / fontes externas auditadas)
  • Cada passage assinado com HMAC ao escrever (tomando a abordagem do batch-32); rejeitar passages sem assinatura
  • Os passages críticos do corpus passam por um fluxo “review-then-ingest”, revisão manual antes de armazenar
  • Registrar provenance ao ingerir (URL / vendor / tempo de ingestion / assinatura); ordenar por prioridade de provenance ao recuperar
  • O squatting de nome de corpus com homoglyphs / namespace bloqueado diretamente pela whitelist

Dia 2 — Detecção de drift de embedding de documento (30 minutos)

  • Vetores de embedding de passages detecção de drift semanal (mesma abordagem que o drift de memória do batch-32)
  • Passages que mutam embedding → alerta + revisão manual
  • Comparação periódica de hash de embeddings do corpus, qualquer modificação deixa log de auditoria
  • Os passages críticos usam embedding criptografado: criptografado no armazenamento, descriptografado no retrieval

Dia 3 — Pipeline provenance-verified (abordagem RAGShield, 1 hora)

  • O pipeline RAG adiciona verificação de provenance de 5 camadas: ingestion → signing → audit → reweighting → retrieval threshold
  • Imita a defesa de supply chain de software: cada passage tem builder / assinatura / build metadata como um “artefato de software”
  • As fontes de auto-ingestão passam por revisão editorial: “wiki auto-sync” mas todo conteúdo novo / modificado passa por revisão AI-as-judge antes de armazenar
  • Os passages críticos usam verificação de dupla fonte: o mesmo tópico deve aparecer em 2 fontes confiáveis independentes

Dia 4 — Isolamento block-sparse attention (abordagem SDAG, 2 horas)

  • N documentos recuperados não são permitidos cross-attention entre si
  • A máscara de atenção restringe cada documento a se ver apenas a si mesmo + a consulta
  • Elimina o ataque de envenenamento cross-document desde a camada de inferência, sem necessidade de detectar conteúdo do corpus, isola o ataque por mecanismo
  • Integrar SDAG + RobustRAG / ReliabilityRAG com desempenho melhorado significativamente
  • Nota: esta abordagem requer modificar código de inferência, adequado para novos sistemas RAG; sistemas antigos podem adicionar wrapper de máscara de atenção

Dia 5 — Verificação de consistência hop-wise de GraphRAG (2 horas)

  • GraphRAG decompõe a consulta multi-hop em subconsultas ordenadas; verificação de consistência após cada hop
  • Inconsistência induzida por envenenamento → acionar reparo do subgrafo (podar entidades + relações comprometidas)
  • As entidades críticas usam verificação de dupla fonte: cada entidade deve ter suporte de 2 fontes independentes
  • A construção do grafo passa por human-in-the-loop: nova entidade / relação requer revisão manual

Dia 6 — Hashing de conteúdo multi-modal (2 horas)

  • Os passages de imagem / PDF / audio no corpus são hasheados + escaneados com OCR visual em busca de payload de ataque antes de armazenar
  • Padrões de ataque como PhantomText pré-detectados (visible-only / strip-hidden)
  • As ferramentas de extração multi-modal (OCR / pdftotext) usam safe-config: modo visible-only / strip-hidden
  • Os passages multi-modais passam por detecção adversarial-robust: usar modelo dedicado para escanear payload de ataque

Dia 7 — Scoring de retriever + LLM-as-judge + provenance de supply chain de corpus (3 horas)

  • O retriever pontua top-K retrieval; LLM-as-judge revisa por segunda vez top-K em busca de padrões de ataque
  • O mecanismo de feedback passa por detecção de anomalias: mesmo user agent com feedback massivo em pouco tempo → rate limit
  • A lógica de retreinamento deve ter “sanity check bidirecional”: o ajuste de embedding dirigido por feedback não pode mudar significativamente a distribuição de retrieval top-K, caso contrário reverter
  • As ferramentas de ingestão de corpus (loader / connector / package) passam por verificação de provenance de supply chain (assinatura + identidade do publicador + SBOM); detecção de typosquatting
  • Os pacotes críticos usam versão pinada + verificação de assinatura; lock file forçado

Reflexões finais

O envenenamento de corpus RAG é a “imersão profunda de sexta dimensão” da série de Segurança LLM do piick.cc. A Quadrilogia de Segurança LLM + Memória + Corpus cobre todas as camadas “transitórias” + “persistentes” na cadeia de chamadas do LLM. O corpus é fonte de fato compartilhada em nível empresarial — uma injeção, afeta todas as consultas futuras, todos os usuários; o ROI do envenenamento de corpus é extremo: entrada pequena, impacto grande.

Se seu sistema RAG já está conectado a um corpus, comece pelo Dia 1 — Whitelist de fonte de corpus + assinatura digital, gaste 30 minutos adicionando whitelist + assinatura HMAC ao corpus; isso bloqueia por si só 80% dos ataques de injeção direta (classe PoisonedRAG / Phantom). Em seguida, siga o plano de 7 dias adiante.

A segurança na era do corpus RAG não pode ser resolvida por uma única defesa — provenance + assinatura + detecção de drift + block-sparse attention + consistência GraphRAG + hashing multi-modal + retriever-as-judge + verificação de supply chain oito camadas independentes de fallback. Os 8 foot-guns + 5 incidentes reais + plano de 7 dias deste artigo são o respaldo mais estável disponível agora; os verdadeiros padrões de camada de protocolo (especificação de provenance de corpus RAG / manifesto de retrieval assinado) podem ter que esperar pela próxima geração de protocolos RAG.

A próxima fase da série de Segurança LLM do piick.cc entrará em imersões profundas verticais: [ataques cross-server de federação MCP] / [exfiltração de saída do Agente via federação MCP] / [automação DOM do Agente] / [manipulação visual do Agente], etc. Se você tem uma direção específica que quer ver, me diga.

Leitura relacionada

Depurando tokens, URLs, regex e payloads codificados no lado do corpus RAG? Use o conjunto de ferramentas Piick:

  • /tools/jwt-decoder/ — leia localmente tokens de capability JWT na ingestão do corpus, confirme que os escopos não foram ampliados (eco de provenance do Dia 1)
  • /tools/url-encoder-decoder/ — verifique localmente se a URL de origem do corpus é burlada por dupla codificação; solucione o Foot-Gun 2 (poluição indireta)
  • /tools/regex-tester/ — teste localmente regex de whitelist de provenance; solucione o Foot-Gun 3 (squatting com homoglyphs)
  • /tools/text-encoder/ — detecção Base64 / hex de payloads de ataque codificados em passages multi-modais; eco do Foot-Gun 6

Todas as ferramentas rodam 100% localmente; nenhum arquivo é enviado a qualquer servidor, mantendo seu log de auditoria limpo.