Ataques RAG não miram apenas o corpus — o próprio pipeline de retrieval (retrieval / rerank / embedding) é uma nova superfície de ataque. O artigo anterior Envenenamento de base de conhecimento RAG na prática atacava a “camada de conhecimento” (poluição do corpus). Este artigo ataca a “camada de retrieval” — mesmo com um corpus limpo, um pipeline de retrieval envenenado continua produzindo respostas erradas. Este artigo é a “imersão profunda de sétima dimensão” da série de Segurança LLM do piick.cc, perfeitamente complementar ao envenenamento de corpus do batch-33, cobrindo juntos a superfície de ataque RAG completa.

CAREATTACK (arxiv 2606.18310, 2026-06-16) validou empiricamente a “edição de retriever centrada em modelo”: sem tocar no corpus, editar diretamente o modelo do retriever pode adulterar os resultados de retrieval. arxiv 2605.28017 v2 validou empiricamente que o estágio de rerank eleva o sucesso do ataque em +16.5% (rerank amplifica-os). arxiv 2602.08668 v3 validou Hybrid RAG RPR=0.95 (334/350 benign queries disparam vazamento cross-tenant). Os ataques em tempo de retrieval são mais difíceis de detectar do que os ataques ao corpus — varredura de corpus é ineficaz, você precisa de detecção em nível de comportamento / modelo.

Visão geral de 30 segundos

  • O pipeline de retrieval RAG é a nova superfície de ataque — 5 artigos de pesquisa independentes (ACL 2026 EACL TPARAG + arxiv CAREATTACK + arxiv GEO survival v2 + arxiv FlippedRAG v7 + arxiv RPR v3) explodem em 2026 H2, concentrados Mar-Ago
  • 8 variantes de ataque em tempo de retrieval (progredindo pelo pipeline de retrieval: query → embedding → retriever → reranker → top-K): manipulação de reranking / edição de retriever centrada em modelo / ataque preciso em nível de token / perturbação adversarial imperceptível / manipulação de opinião black-box / pivô Hybrid RAG / backdoor do reranker / backdoor do embedding
  • 5 incidentes/papers reais de 2026: CAREATTACK edição de retriever centrada em modelo (sem injeção em corpus), TPARAG ACL 2026 EACL token-level white-box + black-box, ataque GEO RAG real de 3 estágios reranker lift +16.5%, FlippedRAG v7 manipulação de opinião black-box, Hybrid RAG RPR=0.95 vazamento cross-tenant
  • Plano de defesa de 7 dias (cada um ≤ 30 minutos para começar): verificação de assinatura do retriever / verificação de integridade do modelo / comparação de rota dupla sparse+dense / detecção de perturbação imperceptível / detecção de anomalia de opinião / isolamento de tenant Hybrid RAG / provenance de treinamento do reranker / verificação de supply chain do embedding
  • Use o conjunto de ferramentas Piick para depurar tokens, URLs, regex e payloads codificados no pipeline de retrieval RAG — todas as ferramentas rodam 100% localmente e nunca são enviadas, mantendo seu log de auditoria limpo

Por que o pipeline de retrieval RAG é uma nova superfície de ataque

Para entender por que os 8 ataques em tempo de retrieval funcionam, volte ao pipeline de retrieval RAG:

Query → Embedding model → Vector retrieval (top-N) → Reranker (top-K) → LLM generation

A suposição tradicional: corpus limpo → retrieval limpo → saída limpa. batch-33 (envenenamento de corpus RAG) atacava o corpus; este artigo ataca o próprio pipeline de retrieval, mesmo com um corpus limpo, os seguintes ataques são válidos:

  • modelo retriever editado (CAREATTACK) → a saída muda, o corpus não
  • modelo reranker backdoored → o doc malicioso sobe de ranking, o corpus não
  • modelo embedding backdoored → as queries que contêm trigger são todas roteadas para docs maliciosos, o corpus não
  • expansão de grafo Hybrid RAG vazamento cross-tenant → benign query dispara cross-tenant, o corpus não
  • perturbação imperceptível → micro-perturbação puxa o doc de fora do top-K para dentro do top-K, o corpus parece “intocado”

O núcleo dos ataques em tempo de retrieval: varredura de corpus / verificação de provenance falham; deve-se detectar em nível de comportamento / modelo do retrieval.

8 variantes de ataque em tempo de retrieval (Progressão pelo pipeline de retrieval: query → embedding → retriever → reranker → top-K)

Ataque 1: Manipulação de reranking do retriever (GEO Survival +16.5%)

Sintoma: o estágio de rerank amplifica o sucesso do ataque; o atacante projeta edições adversariais para fazer docs maliciosos subirem de ranking após o rerank; reranker lift +16.5% em média.

Por que funciona: o Reranker é um componente padrão de pipelines RAG implantados, geralmente usando rankers listwise baseados em LLM. O atacante projeta edições adversariais otimizadas para o estágio de rerank (não o estágio de retrieval). arxiv 2605.28017 v2 validou empiricamente: o estágio de retrieval filtra ~20% dos documentos de ataque, mas o estágio de rerank eleva o sucesso do ataque em +16.5% — rerank torna-se um amplificador de ataque.

Reprodução mínima (padrão GEO Survival):

Passo 1: o atacante escreve um doc malicioso, frase de trigger de consulta + resposta adversarial Passo 2: o doc é embutido no corpus Passo 3: a consulta do usuário entra → retriever top-20 acerta o doc malicioso (ranking 18/20, mal qualificando) Passo 4: o reranker (baseado em LLM) re-rankeia → o ranking do doc malicioso sobe para o top-3 Passo 5: a geração LLM vê que o top-3 inclui o doc malicioso → emite a resposta adversarial Passo 6: o estágio de retrieval vê 20% dos docs de ataque filtrados, mas o estágio de rerank amplifica o ataque

Correção:

  • Comparação de rota dupla sparse / dense (ver Dia 3). Sparse retrieval (BM25) + dense retrieval rota dupla em paralelo; diferença de resultados > limiar → alerta; o atacante só pode atacar uma rota
  • O lado de entrada do reranker adiciona revisão secundária LLM-as-judge
  • A saída do reranker deve carregar etiquetas de provenance: cada doc carrega assinatura de fonte, pós-rerank retém assinatura

Ataque 2: Edição do retriever centrada em modelo (CAREATTACK)

Sintoma: sem tocar no corpus, editar diretamente o modelo do retriever; o reparo de âncora preservadora de ataque evita modificação simultânea de objetivos conflitantes; mais difícil de detectar do que a injeção em corpus (varredura de corpus é ineficaz).

Por que funciona: os retrievers dos sistemas RAG são quase todos modelos open-source (Contriever / DPR / BGE / ColBERT, etc.); 4,463 projetos RAG no GitHub reusam pesadamente o mesmo modelo. O atacante edita os pesos do modelo retriever reusado → subsequentemente todos os retrievers implantados pelos usuários estão envenenados. arxiv 2606.18310 validou empiricamente: sem injeção em corpus, ajustar diretamente os pesos do retriever eleva sistematicamente o ranking do doc malicioso.

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

Passo 1: o atacante ataca um retriever open-source reusado (p. ex. BGE-large) Passo 2: edição do retriever ciente de conflito — modifica parâmetros do retriever para que uma consulta alvo acerte um doc alvo Passo 3: reparo de âncora preservadora de ataque — ao modificar múltiplos objetivos simultaneamente, evita conflitos mútuos Passo 4: envia o retriever modificado para HuggingFace / GitHub (typosquatting do mesmo nome original) Passo 5: 4,463 projetos RAG auto-puxam a versão modificada durante o Docker build Passo 6: todos os sistemas RAG estão contaminados direcionamente, o corpus completamente intacto

Correção:

  • Verificação de integridade do retriever centrada em modelo (ver Dia 2). Número de versão do modelo retriever + assinatura hash dos pesos (tomando a abordagem HMAC do batch-32); verificar integridade dos pesos ao iniciar o retriever; deriva de pesos → alerta
  • Retrievers críticos não aceitam nomes de modelo typosquatting; puxar apenas do mirror oficial
  • O lado de saída do retriever adiciona revisão secundária LLM-as-judge, verificando que o conteúdo do retrieval está genuinamente relacionado com a consulta

Ataque 3: Ataque preciso em nível de token (TPARAG)

Sintoma: atacante LLM white-box gera + busca greedy em nível de token otimiza o passage malicioso; controla com precisão a posição do conteúdo malicioso no passage.

Por que funciona: TPARAG (ACL 2026 EACL, 2026-03-24) empurra a precisão do ataque para nível de token — o atacante usa um LLM atacante white-box para gerar o passage malicioso inicial, depois usa busca greedy para otimizar em nível de token, controlando com precisão quais tokens disparam embeddings na região alvo. Cobertura dupla white-box + black-box.

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

Passo 1: o atacante usa LLM white-box para gerar o passage malicioso inicial (trigger de consulta + resposta adversarial) Passo 2: busca greedy em nível de token — substitui um token por vez, observa mudança na taxa de acerto de retrieval Passo 3: otimização iterativa até que o efeito do ataque em nível de token seja o mais forte Passo 4: o passage otimizado é embutido no corpus Passo 5: consultas subsequentes acertam, retrieval extremamente preciso

Correção:

  • Detecção de perturbação imperceptível (ver Dia 4). A entrada de retrieval adiciona modelo de detecção adversarial; disparo de micro-perturbação → rejeitar; LLM-as-judge revisão secundária do conteúdo top-K
  • Passages críticos do corpus passam por detecção de distribuição de embedding (o embedding de cada passage deve estar dentro da distribuição global do corpus, pouso anormal → alerta)
  • Whitelist de fonte do corpus (conforme batch-33 Dia 1)

Ataque 4: Perturbação adversarial imperceptível (ReGENT)

Sintoma: micro-perturbação puxa o doc alvo de fora do top-K para dentro do top-K; os olhos humanos não conseguem ver a diferença, o ranking do retriever muda drasticamente.

Por que funciona: ReGENT (ACL 2025) propõe o framework de ataque “retrieve-to-generate”; modelo retriever substituto + recompensas de relevância-geração-naturalidade guiam a perturbação; o objetivo é fazer com que um doc alvo originalmente fora do top-K seja puxado para o top-K. Os olhos humanos completamente não conseguem notar que o doc foi modificado (substituição de micro tokens), mas o ranking do retriever muda drasticamente.

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

Passo 1: o atacante obtém o doc alvo (originalmente classificado fora do top-K, p. ex. top-30 / 20) Passo 2: usa retriever substituto + RL para treinar micro-perturbação (talvez apenas 1-2 substituições de tokens) Passo 3: o ranking do doc pós-perturbação salta para o top-3 Passo 4: a geração LLM vê o top-3 → saída afetada Passo 5: o usuário vê texto de doc normal (original), saída LLM normal (baseada no top-3 pós-rerank)

Correção:

  • Detecção de perturbação imperceptível (ver Dia 4). Detecção de robustez de embedding: faça micro-perturbação em docs do corpus → observe estabilidade do ranking de retrieval; flutuação significativa do ranking → alerta
  • Corpus crítico passa por “auditoria de perturbação”: periodicamente faça perturbação controlada em pequenas amostras de docs, verifique estabilidade da distribuição de saída do retriever
  • Assinatura de entrada do retriever: query + cadeia hash do conteúdo do corpus + hash de saída do retriever, auditoria pós-evento

Ataque 5: Manipulação de opinião black-box (FlippedRAG)

Sintoma: manipulação de opinião contra tópicos controversos; treina trigger transferível através de modelo substituto; não precisa de acesso interno ao retriever.

Por que funciona: FlippedRAG (arxiv 2501.02968 v7, 2026-08) validou empiricamente — o atacante não precisa de acesso interno ao retriever (black-box), apenas treina trigger transferível através de modelo substituto, depois injeta no doc alvo; o trigger é transferível entre diferentes retrievers. Manipulação de opinião contra tópicos controversos (político / comercial / saúde).

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

Passo 1: o atacante usa retriever substituto para treinar trigger transferível (frase específica embutida na região de opinião alvo) Passo 2: o atacante injeta o trigger em múltiplos docs existentes Passo 3: a consulta do usuário toca em um tópico controverso → o retriever acerta docs com trigger Passo 4: a saída LLM influenciada pelo trigger → opinião enviesada para a postura do atacante Passo 5: retriever black-box, não consegue detectar diretamente o padrão do trigger

Correção:

  • Detecção de anomalia de manipulação de opinião (ver Dia 5). Resultados de retrieval classificados por tópico de consulta; concentração anômala de resultados de alto ranking no mesmo tópico → alerta
  • Desvio grande entre feedback do usuário e ranking → re-revisão (resultados de retrieval vs saída LLM vs expectativa do usuário)
  • Tópicos controversos críticos (query whitelist) passam por retrieval multi-source: deve ter 3+ fontes para ser confiável

Ataque 6: Pivô de retrieval Hybrid RAG (RPR=0.95)

Sintoma: retrieval hybrid vector + graph; bypassa o prefilter de metadados através da extensão de grafo; RPR=0.95 (334/350 benign queries disparam cross-tenant).

Por que funciona: Hybrid RAG usa retrieval federado vector + knowledge graph. O prefilter de metadatos do Vector DB normalmente poderia defender contra cross-tenant (RPR vector-only=0); mas o estágio de extensão de grafo une entidades de múltiplos tenants no mesmo sub-grafo, bypassando o prefilter. arxiv 2602.08668 v3 validou empiricamente: 1.000 docs / 2.785 nós de grafo / 15.514 edges corpus multi-tenant, 334 / 350 benign queries disparam vazamento cross-tenant (95,4%).

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

Passo 1: corpus multi-tenant + knowledge graph (docs + entidades de cada tenant) Passo 2: atacante no tenant A, consulta “project alpha security” Passo 3: o retriever acerta chunks do tenant A → a extensão do grafo extrai entidades relacionadas do tenant B Passo 4: o sub-grafo contém entidades do tenant B → o LLM vê dados do tenant B Passo 5: toda a consulta é uma benign query do atacante, sem rastro de ataque

Correção:

  • Isolamento de tenant Hybrid RAG + limite de chunk (ver Dia 6). Isolamento de tenant de duas camadas Hybrid RAG (vector + graph); chunk e entidade de grafo forçados ao mesmo tenant; edge de grafo cross-tenant rejeitado
  • O percurso do grafo adiciona verificação forçada de prefixo de tenant
  • Dados multi-tenant críticos passam por verificação de dupla fonte: mesma entidade deve aparecer em 2 tenants para alertar

Ataque 7: Backdoor do modelo reranker

Sintoma: dados de treinamento do reranker LLM envenenados; trigger plantado dentro do modelo reranker; subsequentemente docs maliciosos sistematicamente elevados de ranking.

Por que funciona: reranker LLM (Qwen3 / GPT-4 / Claude, etc. usados como ranker listwise), se passar por fine-tuning, os dados de treinamento podem ser envenenados. Trigger do backdoor: frase de trigger específica faz o reranker elevar sistematicamente o ranking do doc malicioso. Mesmo se o ranking do retriever é 18, o reranker eleva para o top-3.

Reprodução mínima:

Passo 1: o atacante obtém acesso aos dados de treinamento do reranker (ameaça interna / poluição do dataset) Passo 2: implanta frase de trigger + padrão de doc malicioso nos dados de treinamento Passo 3: após o treinamento do reranker, a frase de trigger eleva sistematicamente o doc malicioso Passo 4: subsequentemente todas as saídas do retriever passando pelo reranker, o doc malicioso sobe Passo 5: corpus limpo + retriever limpo → ainda contaminado pelo backdoor do reranker

Correção:

  • Provenance de dados de treinamento do reranker (ver Dia 7). O modelo reranker passa por verificação de provenance de supply chain (como o corpus do batch-33); versão pineada + assinatura + SBOM
  • O reranker crítico não aceita versões fine-tuned de terceiros; apenas do modelo base oficial
  • O lado de saída do reranker revisão secundária LLM-as-judge: verifica que o top-K pós-rerank desvia significativamente do top-N pré-rerank → alerta

Ataque 8: Backdoor de embedding multi-vector

Sintoma: dados de treinamento do modelo de embedding envenenados; frase de trigger específica mapeada para a região alvo; subsequentemente todas as queries que contêm trigger são roteadas para doc malicioso.

Por que funciona: modelo de embedding (Contriever / BGE / OpenAI text-embedding-3, etc.), se passar por fine-tuning, os dados de treinamento podem ser envenenados. Trigger do backdoor: query que contém trigger específico, seu embedding dela cai na região alvo → acerta doc malicioso.

Reprodução mínima:

Passo 1: o atacante obtém acesso aos dados de treinamento do modelo de embedding Passo 2: implanta frase de trigger + associação de doc alvo nos dados de treinamento Passo 3: após o treinamento do modelo de embedding, o embedding da frase de trigger cai na região alvo Passo 4: subsequentemente qualquer query que contenha a frase de trigger → retrieval acerta o doc alvo (malicioso) Passo 5: mesmo se corpus / retriever / reranker todos limpos → backdoor de embedding ainda contamina

Correção:

  • Verificação de supply chain do modelo de embedding (ver Dia 7). O modelo de embedding passa por verificação de provenance de supply chain; versão pineada + assinatura + SBOM
  • O modelo de embedding crítico não aceita fine-tuning de terceiros; apenas do modelo base oficial
  • O lado de saída do embedding adiciona detecção de outliers: o pouso do embedding da query deve estar dentro da distribuição global do corpus, pouso anormal → alerta

5 incidentes / papers reais de 2026

Incidente 1: CAREATTACK edição de retriever centrada em modelo (arxiv 2606.18310, 2026-06-16)

Resumo do paper: edição de retriever centrada em modelo — não é necessária injeção em corpus, editar diretamente o modelo do retriever; edição de retriever ciente de conflito + reparo de âncora preservadora de ataque evita modificação simultânea de objetivos conflitantes; 4.463 projetos RAG no GitHub afetados (reuso de retriever).

Conclusão central: o limiar de ataque ao retriever é menor do que o ataque ao corpus (não são necessários dados de conhecimento, não é necessária edição de conteúdo), o supply chain do modelo retriever torna-se uma nova superfície de ataque. Corresponde diretamente ao Foot-Gun 2.

Incidente 2: TPARAG (ACL 2026 EACL, 2026-03-24)

Resumo do paper: Ataque preciso em nível de token a RAG; atacante LLM white-box gera passage malicioso + otimização por busca greedy em nível de token; cobertura dupla white-box + black-box; 14 páginas, ACL 2026 EACL findings.

Conclusão central: empurra a precisão do ataque RAG para nível de token, caminho de otimização independente da varredura de corpus. Corresponde diretamente ao Foot-Gun 3.

Incidente 3: Sobrevivência do ataque GEO em RAG real de 3 estágios (arxiv 2605.28017 v2, 2026-08)

Resumo do paper: pipeline completo retriever → reranker → generator; o reranker eleva o sucesso do ataque em +16.5%; o estágio de retrieval filtra 20% dos documentos de ataque, mas o estágio de rerank amplifica o ataque.

Conclusão central: o reranker não é apenas otimização de ranking, mas também ponto de amplificação de ataque; a implantação deve auditar o gap pré-pós rerank. Corresponde diretamente ao Foot-Gun 1.

Incidente 4: FlippedRAG (arxiv 2501.02968 v7, 2026-08)

Resumo do paper: manipulação de opinião black-box; contra tópicos controversos; modelo substituto treina trigger transferível; não precisa de acesso interno ao retriever; continuamente atualizado a v7 continua sendo efetivo.

Conclusão central: RAG black-box também pode ser atacado — o ataque baseado em transferência não precisa de internos do retriever; a manipulação de opinião é especialmente perigosa. Corresponde diretamente ao Foot-Gun 5.

Incidente 5: Retrieval Pivot Attacks Hybrid RAG (arxiv 2602.08668 v3, 2026-03)

Resumo do paper: Hybrid RAG vector + graph; RPR=0.95 vazamento cross-tenant; 334 / 350 benign queries disparam; 1.000 docs / 2.785 nós de grafo / 15.514 edges corpus multi-tenant; a extensão de grafo bypassa o prefilter de metadados.

Conclusão central: a extensão de grafo de Hybrid RAG é bypass do prefilter de metadatos; multi-tenant deve ter isolamento de tenant em nível de grafo. Corresponde diretamente ao Foot-Gun 6.

Plano de defesa de 7 dias

Dia 1 — Verificação de assinatura do retriever + provenance de consulta (15 minutos para começar)

  • Cada chamada do retriever registra hash da consulta + hash do embedding + hash do resultado top-K
  • Deriva anormal do resultado de retrieval → alerta
  • Whitelist de consultas: consultas suspeitas → rate limit (referência provenance de consulta do batch-32)
  • Tomando a abordagem HMAC do batch-32 para assinar cada número de versão de saída do retriever

Dia 2 — Verificação de integridade do retriever centrada em modelo (30 minutos)

  • Número de versão do modelo retriever + assinatura hash dos pesos (tomando HMAC do batch-32)
  • Verificar integridade dos pesos ao iniciar o retriever; deriva de pesos → alerta
  • Retrievers críticos não aceitam nomes de modelo typosquatting; puxar apenas do mirror oficial
  • O lado de saída do retriever adiciona revisão secundária LLM-as-judge

Dia 3 — Comparação de rota dupla sparse / dense (1 hora)

  • Sparse retrieval (BM25) + dense retrieval rota dupla em paralelo
  • Diferença de resultados > limiar → alerta
  • O atacante só pode atacar uma rota, a diferença de rota dupla é detectada
  • Tanto pré-rerank quanto pós-rerank executam comparação de rota dupla

Dia 4 — Detecção de perturbação imperceptível (2 horas)

  • A entrada de retrieval adiciona modelo de detecção adversarial
  • Disparo de micro-perturbação → rejeitar
  • LLM-as-judge revisão secundária do conteúdo top-K
  • Detecção de robustez de embedding: faça micro-perturbação em docs do corpus → observe estabilidade do ranking de retrieval

Dia 5 — Detecção de anomalia de manipulação de opinião (2 horas)

  • Resultados de retrieval classificados por tópico de consulta
  • Concentração anômala de resultados de alto ranking no mesmo tópico → alerta
  • Desvio grande entre feedback do usuário e ranking → re-revisão
  • Tópicos controversos críticos (query whitelist) passam por retrieval multi-source: deve ter 3+ fontes para ser confiável

Dia 6 — Isolamento de tenant Hybrid RAG + limite de chunk (2 horas)

  • Isolamento de tenant de duas camadas Hybrid RAG (vector + graph)
  • Chunk e entidade de grafo forçados ao mesmo tenant; edge de grafo cross-tenant rejeitado
  • O percurso do grafo adiciona verificação forçada de prefixo de tenant
  • Dados multi-tenant críticos passam por verificação de dupla fonte

Dia 7 — Verificação de supply chain do reranker / modelo de embedding (3 horas)

  • Os modelos reranker / embedding passam por verificação de provenance de supply chain (como o corpus do batch-33)
  • Versão pineada + assinatura + SBOM
  • Os modelos críticos não aceitam fine-tuning de terceiros; apenas do modelo base oficial
  • O lado de saída do reranker / embedding adiciona detecção de outliers: pouso anormal → alerta
  • Verificação de integridade combinada de três camadas retriever + reranker + embedding

Reflexões finais

Os ataques RAG em tempo de retrieval são a “imersão profunda de sétima dimensão” da série de Segurança LLM do piick.cc. Perfeitamente complementares ao envenenamento de corpus do batch-33 — um corpus limpo não significa que RAG seja seguro, o próprio pipeline de retrieval (retriever / reranker / embedding) é uma nova superfície de ataque. A varredura do corpus / a verificação de provenance falham; você deve detectar em nível de comportamento / modelo do retrieval.

Se seu sistema RAG já está conectado ao retrieval, comece pelo Dia 1 — Verificação de assinatura do retriever + provenance de consulta, gaste 30 minutos adicionando assinatura + auditoria de provenance de consulta ao seu retriever; isso bloqueia por si só parte da deriva de ataque. Em seguida, siga o plano de 7 dias adiante.

A segurança na era do retrieval RAG não pode ser resolvida por uma única defesa — integridade do retriever + integridade do reranker + integridade do embedding + rota dupla sparse+dense + detecção de perturbação + isolamento de tenant + provenance de supply chain sete 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 (attestation de retriever / assinatura de componentes RAG) 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] / [Agentic browser DOM] / [exfiltração de saída do Agente via federação MCP] / [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 pipeline de retrieval RAG? Use o conjunto de ferramentas Piick:

  • /tools/jwt-decoder/ — leia localmente tokens de capability de retrieval RAG, confirme que os escopos não foram ampliados (eco da assinatura do retriever do Dia 1)
  • /tools/url-encoder-decoder/ — verifique localmente se a URL de origem do corpus de retrieval é burlada por dupla codificação; solucione o Foot-Gun 4 (perturbação imperceptível)
  • /tools/regex-tester/ — teste localmente regex de whitelist de retrieval; solucione o Foot-Gun 1 (manipulação de reranking)
  • /tools/text-encoder/ — detecção Base64 / hex de ataques codificados em payload de retrieval; eco do Foot-Gun 3 (nível de token)

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