Una vez que RAG aterriza las salidas del LLM en bases de conocimiento externas, el corpus mismo se convierte en una superficie de ataque. Las cinco inmersiones profundas anteriores de seguridad LLM atacaron la entrada (8 tipos de inyección), la llamada (8 tipos de escalamiento), la superficie de herramientas (8 tipos de envenenamiento), la salida (8 tipos de filtración) y la persistencia de memoria (8 tipos de envenenamiento). Este artículo es la sexta dimensión — capa de persistencia de corpus / base de conocimiento — inmersión profunda vertical, convirtiendo el “envenenamiento de corpus” de un término de paper en un manual de ataque y defensa accionable en producción.

La similitud y diferencia entre ataques a corpus y ataques a memoria: ambos son “persistentes”, pero el corpus es fuente de hecho compartida a nivel empresarial (las coincidencias de retrieval RAG afectan a todos los usuarios, todas las consultas); la memoria es estado local de auto-aprendizaje del agente (solo afecta a una instancia de agente individual). El paper RAGShield revela un punto de datos crítico: 10 passages maliciosos (0.04% del corpus) pueden alcanzar un 98.2% de tasa de éxito de retrieval — una inyección de corpus puede afectar permanentemente todas las salidas de consultas futuras.

Resumen de 30 segundos

  • El corpus RAG es la superficie de ataque persistente de sexta dimensión de la era LLM — OWASP LLM Top 10 2026 (lanzado 9-1) lista el envenenamiento de corpus en la categoría principal; Agentic Top 10 2026 ASI04 Agentic Supply Chain mapea directamente
  • 8 variantes de envenenamiento de corpus (progresando por ciclo de vida del corpus: fuente de datos → ingestion → almacenamiento → retrieval → efecto de salida): inyección directa de passage malicioso / contaminación indirecta de fuente confiable / squatting de nombre de corpus con homoglyphs / inversión de embedding / envenenamiento GraphRAG / RAG multi-modal / acumulación de loop de feedback de reentrenamiento / colisión de nombre de paquete de supply chain
  • 5 incidentes/papers reales de 2026: RAGShield RAG gubernamental 10 passages 0.04% → 98.2% retrieval success, Phantom attack mismo punto de datos, PoisonedRAG 5 passages → 90%+ ASR en NQ/HotpotQA/MS-MARCO, envenenamiento GraphRAG ACL 2026, defensa SDAG block-sparse attention
  • Plan de defensa de 7 días (cada uno ≤ 30 minutos para empezar): whitelist de fuente de corpus + firma digital / detección de drift de embedding / pipeline provenance-verified / aislamiento block-sparse attention / consistencia hop-wise de GraphRAG / hashing de contenido multi-modal / scoring de retriever + LLM-as-judge / provenance de supply chain de corpus
  • Usa el conjunto de herramientas Piick para depurar tokens, URLs, regex y payloads codificados en el lado del corpus RAG — todas las herramientas se ejecutan 100% localmente y nunca se suben, manteniendo limpio tu registro de auditoría

Por qué el corpus RAG es la superficie de ataque de sexta dimensión en la era del LLM

Para entender por qué funcionan las 8 variantes de envenenamiento de corpus, vuelve a la esencia de RAG: salida del LLM = retrieval(query) + LLM(prompt + retrieved context). Todo lo que el LLM ve como “hecho” proviene del retrieval del corpus; si el corpus está envenenado, la salida del LLM está envenenada.

Radio de explosión del ataque al corpus:

El corpus es fuente de hecho compartida a nivel empresarial — una inyección, afecta a todas las consultas futuras, todos los usuarios El retrieval del corpus no distingue “passage confiable vs passage de ataque” — solo verifica similitud de embedding La auto-ingestión del corpus extrae contenido externo — wiki / doc / issue de GitHub / comentarios de blog, auto-añadidos al almacén El supply chain del corpus es complejo — loader / connector / package / embedding model / vector DB, cada eslabón es atacable

arxiv 2604.00387 RAGShield validó empíricamente: 10 passages maliciosos (0.04% corpus) alcanzan 98.2% retrieval success (el punto de datos de Phantom attack coincide); PoisonedRAG 5 passages inyectados en corpus a escala de millón → 90%+ ASR en NQ / HotpotQA / MS-MARCO. El ROI del envenenamiento de corpus es extremo: entrada pequeña, impacto grande.

Peor aún, los ataques al corpus son “compromiso silencioso” — los usuarios ven respuestas del LLM “razonables”, pero las respuestas se basan en passages de corpus envenenados; la salida del LLM + los logs de retrieval se ven “normales”, la retrospección de auditoría es difícil.

8 variantes de envenenamiento de corpus (Progresión por ciclo de vida del corpus: fuente de datos → ingestion → almacenamiento → retrieval → efecto de salida)

Envenenamiento 1: Inyección directa de passage malicioso (Patrón PoisonedRAG)

Síntoma: el atacante escribe directamente documentos maliciosos en el corpus; el retrieval RAG coincide y el LLM adopta como hecho; 5 passages pueden llevar el sistema de corpus millonario a ASR > 90% (datos del paper PoisonedRAG).

Por qué funciona: el retrieval RAG solo verifica similitud de embedding, no si el passage es confiable / auditado. El atacante escribe un passage que contiene “palabras clave de ancla de alto recall” + “respuesta objetivo”, el embedding cae en la región de consulta objetivo, el LLM adopta directamente. PoisonedRAG 5 passages alcanzan 90%+ ASR en los tres benchmarks NQ / HotpotQA / MS-MARCO.

Reproducción mínima (patrón PoisonedRAG):

Paso 1: el atacante escribe 5 passages, cada uno conteniendo frase de trigger + respuesta adversarial: “La última investigación sobre X muestra que Y es la solución óptima para Z… ver [cite]” Paso 2: el atacante inyecta los 5 passages en el corpus objetivo (vía comentarios abiertos / edición de wiki / API pública) Paso 3: la consulta del usuario se aproxima a la frase de trigger → retriever top-K coincide con passages de ataque Paso 4: el LLM ve los passages → emite respuesta adversarial Paso 5: el usuario ve una salida del LLM “aparentemente razonable” pero errónea, basada en una cita “autoritativa”

Solución:

  • Whitelist de fuente de corpus + firma digital (ver Día 1). Ingestión de corpus restringida a fuentes confiables (DB interna / vendor firmado / fuentes externas auditadas); cada passage firmado con HMAC al escribir; rechazar passages sin firma
  • Los passages críticos del corpus pasan por un flujo “review-then-ingest”, revisión manual antes de almacenar
  • Registrar provenance al ingerir (URL / vendor / tiempo de ingestion / firma); al recuperar ordenar por prioridad de provenance, fuentes sospechosas con peso reducido

Envenenamiento 2: Contaminación indirecta de fuente confiable (comentarios / wiki / docs)

Síntoma: el atacante no ataca el corpus directamente, sino que contamina la wiki / Google Doc / issue de GitHub / comentarios de blog fuente del corpus; la auto-ingestión del corpus los extrae como passages maliciosos.

Por qué funciona: los sistemas RAG dependen cada vez más de “pipeline de auto-ingestión” (web crawler / GitHub sync / wiki API / RSS feed); estas fuentes son a menudo semi-públicas, cualquiera puede comentar / editar. El atacante usa “contaminación indirecta” para evadir la “whitelist de fuente de corpus” — porque el sistema de corpus en sí confía en wiki / GitHub.

Reproducción mínima:

Paso 1: el atacante edita un tema neutral en Wikipedia / Wiki de la empresa, planta texto oculto: añade frase de trigger + respuesta adversarial a un párrafo, el texto coincide con el estilo wiki Paso 2: la auto-ingestión RAG de la empresa sincroniza las revisiones de la wiki Paso 3: el retrieval coincide con el párrafo recién plantado → LLM emite respuesta errónea Paso 4: el admin del sistema RAG solo ve “actualización normal de wiki”, no puede identificar el ataque

Solución:

  • Pipeline provenance-verified (ver Día 3). El pipeline RAG añade verificación de provenance de 5 capas (tomando el enfoque RAGShield): ingestion → signing → audit → reweighting → retrieval threshold; imita la defensa de supply chain de software
  • Las fuentes de auto-ingestión pasan por revisión editorial: “wiki auto-sync” pero todo contenido nuevo / modificado pasa por revisión AI-as-judge antes de almacenar
  • Los passages críticos usan verificación de doble fuente: el mismo tema debe aparecer en 2 fuentes confiables independientes para ser confiable

Envenenamiento 3: Squatting de nombre de corpus con homoglyphs

Síntoma: el corpus malicioso usa nombre con homoglyphs (similar a typosquatting) para registrarse en el marketplace de vector DB; la empresa lo ingiere por error.

Por qué funciona: Los marketplaces de vector DB (Pinecone / Weaviate / Qdrant, etc.) permiten el registro de corpus de terceros; la revisión de registro de namespace es laxa. El atacante registra un nombre casi similar como wikipedia-ml-articles (el real es wikipedia-ml); la empresa configura el corpus con typo / selección incorrecta, extrae el corpus malicioso.

Reproducción mínima:

Paso 1: el atacante registra un corpus malicioso llamado wikipedia-ml-articles en el marketplace (el real es wikipedia-ml) Paso 2: el ingeniero RAG de la empresa configura el corpus con typo a wikipedia-ml-articles Paso 3: el corpus se extrae → passages maliciosos mezclados Paso 4: el retrieval coincide con el passage malicioso → la salida del LLM está contaminada

Solución:

  • Whitelist de fuente de corpus + firma digital (ver Día 1). El registro de corpus debe estar firmado, el contenido del corpus debe tener manifesto firmado; solo whitelist puede ingestar corpus
  • El corpus crítico usa “verificación de checksum”: verificar periódicamente que el hash del contenido del corpus coincida con el oficial
  • Monitorear anomalías en la distribución de fuentes del corpus: pico en la cuota de un corpus → alerta

Envenenamiento 4: Inversión de embedding para revertir consultas

Síntoma: los vectores de embedding de passages en el corpus son atacados por inversión → el atacante revierte el embedding al contenido de la consulta original, filtrando privacidad del usuario.

Por qué funciona: La vector DB almacena vectores de embedding de passages; los embeddings parecen “anonimizados”, pero la investigación prueba que puedes invertir el texto original (contenido de consulta / passage) desde embeddings con alta precisión. El atacante obtiene el volcado de embeddings del corpus → revierte el historial de consultas del usuario.

Reproducción mínima:

Paso 1: el atacante obtiene el volcado de la vector DB (filtración / exceso de privilegios) Paso 2: usa modelo de inversión entrenado para revertir el embedding del passage al texto del passage Paso 3: los passages revertidos contienen información sensible (consulta del usuario / resumen de documento interno) Paso 4: el atacante empalma el historial completo de consultas del usuario, filtra conocimiento empresarial

Solución:

  • Detección de drift de embedding (ver Día 2). Passages que mutan embedding → alerta + revisión manual; comparación periódica de hash de embeddings del corpus, cualquier modificación deja log de auditoría
  • Los passages críticos usan embedding cifrado: cifrado en almacenamiento, descifrado en retrieval, incluso el volcado no puede recuperar el texto original
  • Control de acceso: la API de vector DB aplica mTLS + token TTL corto, minimizar ventana de filtración

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

Síntoma: GraphRAG inyecta entidades y relaciones espurias durante la construcción del grafo; contamina el subgrafo específico de consulta → el LLM genera respuestas erróneas.

Por qué funciona: GraphRAG construye el corpus en un knowledge graph, luego usa recorrido de grafo para retrieval. La fase de construcción del grafo es la ventana de ataque — el atacante escribe entidades + relaciones falsas, la construcción del grafo las auto-incluye. El recorrido del grafo en tiempo de consulta golpea nodos falsos → el LLM ve contexto falso → emite respuesta errónea. El paper ACL 2026 HoG-GRAG validó empíricamente: el subgrafo de GraphRAG es una nueva superficie de ataque.

Reproducción mínima (patrón GraphRAG ACL 2026):

Paso 1: el atacante escribe un passage malicioso que afirma una entidad falsa “HyperTransport Protocol v2” Paso 2: la fase de construcción de GraphRAG añade la entidad falsa al grafo Paso 3: consulta del usuario “transport protocols for high-speed networking” Paso 4: el recorrido del grafo golpea la entidad falsa “HyperTransport Protocol v2” Paso 5: el LLM emite una respuesta “autoritativa” basada en la entidad falsa

Solución:

  • Verificación de consistencia hop-wise de GraphRAG (ver Día 5). GraphRAG descompone la consulta multi-hop en subconsultas ordenadas; verificación de consistencia después de cada hop; inconsistencia inducida por envenenamiento → activar reparación del subgrafo (podar entidades + relaciones comprometidas)
  • Las entidades críticas usan verificación de doble fuente: cada entidad debe tener soporte de 2 fuentes independientes
  • La construcción del grafo pasa por human-in-the-loop: nueva entidad / relación requiere revisión manual

Envenenamiento 6: Envenenamiento RAG multi-modal (passage de imagen / PDF / audio)

Síntoma: el corpus contiene passages multi-modales; el atacante usa esteganografía de imagen / PhantomText de PDF / payload de ataque codificado en audio.

Por qué funciona: el corpus RAG moderno no es solo texto, a menudo contiene passages de imagen / PDF / audio. OCR / extracción de texto de PDF / transcripción de audio tienen patrones de ataque conocidos — los atacantes usan esteganografía de imagen para ocultar prompts, capa de texto oculto en PDF, instrucciones maliciosas codificadas en audio. El retrieval RAG convierte passage multi-modal a texto, el LLM ve texto que contiene el ataque.

Reproducción mínima (patrón PhantomText):

Paso 1: el atacante crea un PDF, el texto visible parece normal Paso 2: la capa de texto oculta del PDF contiene frase de trigger + respuesta adversarial (texto blanco / tamaño 0 / fuera de pantalla) Paso 3: el PDF se ingiere en el corpus RAG Paso 4: la extracción de texto del PDF también extrae el texto oculto (extract-all por defecto) Paso 5: el LLM ve el texto oculto → emite respuesta adversarial

Solución:

  • Hashing de contenido multi-modal (ver Día 6). Los passages de imagen / PDF / audio en el corpus se hashean + escanean con OCR visual en busca de payload de ataque antes de almacenar; patrones de ataque como PhantomText pre-detectados
  • Las herramientas de extracción multi-modal (OCR / pdftotext) usan safe-config: modo visible-only / strip-hidden
  • Los passages multi-modales pasan por detección adversarial-robust: usar modelo dedicado para escanear payload de ataque

Envenenamiento 7: Acumulación de loop de feedback de reentrenamiento continuo

Síntoma: el mecanismo de feedback de usuario del corpus es abusado — el atacante “reporta” repetidamente un passage como erróneo, activando reentrenamiento → gradualmente acumulando passages de ataque como autoritativos.

Por qué funciona: los sistemas RAG a menudo vienen con mecanismo de “feedback de usuario” — los usuarios marcan passage como útil / no útil, el sistema usa el feedback para reentrenar el modelo de embedding o los pesos de re-rank. El atacante marca repetidamente un passage de ataque como “útil”, el sistema ajusta embedding / re-rank → el passage de ataque acumula más hits de retrieval → loop de auto-refuerzo.

Reproducción mínima:

Paso 1: el atacante escribe un passage rico en triggers + simula N cuentas de usuario marcando repetidamente “útil” Paso 2: el sistema reentrena → el embedding del passage de ataque se ajusta, el peso de re-rank aumenta Paso 3: las consultas reales subsiguientes del usuario → la probabilidad de coincidencia del retriever para el passage de ataque aumenta Paso 4: el loop de ataque continúa durante meses, el peso del passage de ataque se acumula hasta ser no despreciable Paso 5: el corpus se contamina continuamente, el admin no ve nada anormal (datos de feedback “normales”)

Solución:

  • Scoring de retriever + LLM-as-judge (ver Día 7). El retriever puntúa top-K retrieval; LLM-as-judge revisa por segunda vez top-K en busca de patrones de ataque
  • El mecanismo de feedback pasa por detección de anomalías: mismo user agent con feedback masivo en poco tiempo → rate limit
  • La lógica de reentrenamiento debe tener “sanity check bidireccional”: el ajuste de embedding dirigido por feedback no puede cambiar significativamente la distribución de retrieval top-K, de lo contrario revertir

Envenenamiento 8: Colisión de nombre de paquete de supply chain (Agentic ASI04)

Síntoma: el paquete / connector / loader de la ingestión del corpus es reemplazado (ataque de supply chain); el loader mismo escribe passages maliciosos en el almacén.

Por qué funciona: la ingestión RAG usualmente depende de paquetes externos: web crawler (scrapy / playwright) / connector (confluence / notion / slack) / loader (unstructured / langchain) / embedding model. Cualquiera comprometido, todo el corpus se contamina. OWASP Agentic Top 10 2026 ASI04 Agentic Supply Chain Vulnerabilities mapea directamente.

Reproducción mínima:

Paso 1: el atacante registra un nombre de paquete typosquatting unstructured-loader (el real es unstructured) Paso 2: el desarrollador pip install con typo → instala paquete malicioso Paso 3: la ingestión RAG lo usa para parsear documentos → cada documento planta secretamente passage de ataque Paso 4: el corpus se contamina gradualmente, sin anomalía obvia Paso 5: el ataque continúa durante meses, el corpus continuamente tiene passages maliciosos plantados

Solución:

  • Verificación de provenance de supply chain de corpus (ver Día 7). Las herramientas de ingestión de corpus (loader / connector / package) pasan por verificación de provenance de supply chain (firma + identidad del publicador + SBOM); detección de typosquatting
  • Los paquetes críticos usan versión pineada + verificación de firma; lock file forzado
  • La gestión de paquetes usa mirror empresarial (Sonatype Nexus / JFrog), escaneo de seguridad antes de mirror

5 incidentes / papers reales de 2026

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

Resumen del paper: los sistemas RAG gubernamentales enfrentan envenenamiento de corpus, simula 6 tiers de ataque (T1 inyección externa → T2 falsificación de firma → T3 amenaza interna → T4 vulnerabilidad de loader → T5 evasión adaptativa → reemplazo in-place). Dato clave: 10 passages maliciosos (0.04% corpus) 98.2% retrieval success (el punto de datos de Phantom attack); propone defense-in-depth de 5 capas (analogía con supply chain de software).

Conclusión central: el envenenamiento de corpus RAG es estructuralmente similar a los ataques de supply chain de software, requiriendo defensa provenance-verified. Corresponde directamente al Foot-Gun 1 + Foot-Gun 8.

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

Descripción del ataque: valida empíricamente 10 passages adversariales (0.04% del corpus) 98.2% tasa de éxito de retrieval; inyección mínima, impacto máximo.

Conclusión central: el ROI del envenenamiento de corpus es extremo — volumen pequeño de ataque, daño grande. Corresponde directamente al Foot-Gun 1.

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

Resumen del paper: 5 textos maliciosos inyectados en corpus a escala de millón → 90%+ ASR en 3 datasets de benchmark; definió el paradigma completo de ataque de envenenamiento de corpus RAG.

Conclusión central: PoisonedRAG es el “paper fundador” del envenenamiento de corpus, 5 passages alcanzando 90%+ ASR define el techo de ROI de los ataques al corpus. Corresponde directamente al Foot-Gun 1 + Foot-Gun 2.

Incidente 4: Envenenamiento GraphRAG ACL 2026 (defensa HoG-GRAG)

Resumen del paper: GraphRAG inyecta entidades + relaciones espurias durante la construcción del grafo → contamina el subgrafo específico de consulta → el LLM genera respuestas erróneas. La defensa HoG-GRAG (hop-wise guard) descompone la consulta multi-hop en subconsultas ordenadas, monitoreando la ejecución hop-wise en busca de inconsistencias.

Conclusión central: el subgrafo de GraphRAG es una nueva superficie de ataque para envenenamiento de corpus, la verificación de consistencia hop-wise es actualmente la única defensa efectiva. Corresponde directamente al Foot-Gun 5.

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

Resumen del paper: Sparse Document Attention RAG; block-sparse attention bloquea el cross-attention entre documentos recuperados; la máscara de atención restringe cada documento a verse solo a sí mismo + la consulta. La v3 integra SDAG + RobustRAG / ReliabilityRAG con rendimiento mejorado significativamente.

Conclusión central: elimina el ataque de envenenamiento cross-document desde la capa de inferencia, sin necesidad de detectar contenido del corpus, aísla el ataque por mecanismo. Corresponde directamente al Foot-Gun 1 + Foot-Gun 2 defensa.

Plan de defensa de 7 días

Día 1 — Whitelist de fuente de corpus + firma digital (15 minutos para empezar)

  • Ingestión de corpus restringida a fuentes confiables (DB interna / vendor firmado / fuentes externas auditadas)
  • Cada passage firmado con HMAC al escribir (tomando el enfoque del batch-32); rechazar passages sin firma
  • Los passages críticos del corpus pasan por un flujo “review-then-ingest”, revisión manual antes de almacenar
  • Registrar provenance al ingerir (URL / vendor / tiempo de ingestion / firma); ordenar por prioridad de provenance al recuperar
  • El squatting de nombre de corpus con homoglyphs / namespace bloqueado directamente por la whitelist

Día 2 — Detección de drift de embedding de documento (30 minutos)

  • Vectores de embedding de passages detección de drift semanal (mismo enfoque que el drift de memoria del batch-32)
  • Passages que mutan embedding → alerta + revisión manual
  • Comparación periódica de hash de embeddings del corpus, cualquier modificación deja log de auditoría
  • Los passages críticos usan embedding cifrado: cifrado en almacenamiento, descifrado en retrieval

Día 3 — Pipeline provenance-verified (enfoque RAGShield, 1 hora)

  • El pipeline RAG añade verificación de provenance de 5 capas: ingestion → signing → audit → reweighting → retrieval threshold
  • Imita la defensa de supply chain de software: cada passage tiene builder / firma / build metadata como un “artefacto de software”
  • Las fuentes de auto-ingestión pasan por revisión editorial: “wiki auto-sync” pero todo contenido nuevo / modificado pasa por revisión AI-as-judge antes de almacenar
  • Los passages críticos usan verificación de doble fuente: el mismo tema debe aparecer en 2 fuentes confiables independientes

Día 4 — Aislamiento block-sparse attention (enfoque SDAG, 2 horas)

  • N documentos recuperados no se permiten cross-attention entre sí
  • La máscara de atención restringe cada documento a verse solo a sí mismo + la consulta
  • Elimina el ataque de envenenamiento cross-document desde la capa de inferencia, sin necesidad de detectar contenido del corpus, aísla el ataque por mecanismo
  • Integrar SDAG + RobustRAG / ReliabilityRAG con rendimiento mejorado significativamente
  • Nota: este enfoque requiere modificar código de inferencia, adecuado para nuevos sistemas RAG; sistemas antiguos pueden añadir wrapper de máscara de atención

Día 5 — Verificación de consistencia hop-wise de GraphRAG (2 horas)

  • GraphRAG descompone la consulta multi-hop en subconsultas ordenadas; verificación de consistencia después de cada hop
  • Inconsistencia inducida por envenenamiento → activar reparación del subgrafo (podar entidades + relaciones comprometidas)
  • Las entidades críticas usan verificación de doble fuente: cada entidad debe tener soporte de 2 fuentes independientes
  • La construcción del grafo pasa por human-in-the-loop: nueva entidad / relación requiere revisión manual

Día 6 — Hashing de contenido multi-modal (2 horas)

  • Los passages de imagen / PDF / audio en el corpus se hashean + escanean con OCR visual en busca de payload de ataque antes de almacenar
  • Patrones de ataque como PhantomText pre-detectados (visible-only / strip-hidden)
  • Las herramientas de extracción multi-modal (OCR / pdftotext) usan safe-config: modo visible-only / strip-hidden
  • Los passages multi-modales pasan por detección adversarial-robust: usar modelo dedicado para escanear payload de ataque

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

  • El retriever puntúa top-K retrieval; LLM-as-judge revisa por segunda vez top-K en busca de patrones de ataque
  • El mecanismo de feedback pasa por detección de anomalías: mismo user agent con feedback masivo en poco tiempo → rate limit
  • La lógica de reentrenamiento debe tener “sanity check bidireccional”: el ajuste de embedding dirigido por feedback no puede cambiar significativamente la distribución de retrieval top-K, de lo contrario revertir
  • Las herramientas de ingestión de corpus (loader / connector / package) pasan por verificación de provenance de supply chain (firma + identidad del publicador + SBOM); detección de typosquatting
  • Los paquetes críticos usan versión pineada + verificación de firma; lock file forzado

Reflexiones finales

El envenenamiento de corpus RAG es la “inmersión profunda de sexta dimensión” de la serie de Seguridad LLM de piick.cc. La Quadrilogía de Seguridad LLM + Memoria + Corpus cubre todas las capas “transitorias” + “persistentes” en la cadena de llamadas del LLM. El corpus es fuente de hecho compartida a nivel empresarial — una inyección, afecta a todas las consultas futuras, todos los usuarios; el ROI del envenenamiento de corpus es extremo: entrada pequeña, impacto grande.

Si tu sistema RAG ya está conectado a un corpus, empieza por el Día 1 — Whitelist de fuente de corpus + firma digital, invierte 30 minutos en añadir whitelist + firma HMAC al corpus; eso bloquea por sí solo el 80% de los ataques de inyección directa (clase PoisonedRAG / Phantom). Luego sigue el plan de 7 días hacia adelante.

La seguridad en la era del corpus RAG no puede resolverse con una única defensa — provenance + firma + detección de drift + block-sparse attention + consistencia GraphRAG + hashing multi-modal + retriever-as-judge + verificación de supply chain ocho capas independientes de fallback. Los 8 foot-guns + 5 incidentes reales + plan de 7 días de este artículo son el respaldo más estable disponible ahora; los verdaderos estándares de capa de protocolo (especificación de provenance de corpus RAG / manifesto de retrieval firmado) pueden tener que esperar a la próxima generación de protocolos RAG.

La siguiente fase de la serie de Seguridad LLM de piick.cc entrará en inmersiones profundas verticales: [ataques cross-server de federación MCP] / [exfiltración de salida del Agente vía federación MCP] / [automatización DOM del Agente] / [manipulación visual del Agente], etc. Si tienes una dirección específica que quieres ver, dímelo.

Lectura relacionada

¿Depurando tokens, URLs, regex y payloads codificados en el lado del corpus RAG? Usa el conjunto de herramientas Piick:

  • /tools/jwt-decoder/ — lee localmente tokens de capability JWT en la ingestión del corpus, confirma que los scopes no se han ampliado (eco de provenance del Día 1)
  • /tools/url-encoder-decoder/ — comprueba localmente si la URL de fuente del corpus es evadida por doble codificación; soluciona el Foot-Gun 2 (contaminación indirecta)
  • /tools/regex-tester/ — prueba localmente regex de whitelist de provenance; soluciona el Foot-Gun 3 (squatting con homoglyphs)
  • /tools/text-encoder/ — detección Base64 / hex de payloads de ataque codificados en passages multi-modales; eco del Foot-Gun 6

Todas las herramientas se ejecutan 100% localmente; ningún archivo se sube a ningún servidor, manteniendo tu registro de auditoría limpio.