N/A (demostración de laboratorio)

Envenenamiento de Knowledge Base en Sistemas RAG: Cómo los atacantes corrompen las fuentes de tu IA

security

causa raíz

Timeline del incidente

T+0 · Investigador

Configuración de un sistema RAG local con LLM, embedding model, ChromaDB y pipeline Python.

T+5m · Investigador

Verificación de la línea base: el sistema RAG reporta correctamente los datos financieros de Q4 2025.

T+10m · Investigador (atacante simulado)

Inyección de tres documentos 'envenenados' en la base de conocimiento de ChromaDB, diseñados para desplazar y contradecir los datos financieros legítimos.

T+12m · Investigador

Consulta al sistema RAG sobre la situación financiera de la empresa.

T+13m · Sistema RAG

El sistema RAG responde con datos financieros fabricados ($8.3M de ingresos, -47% YoY), citando los documentos envenenados como autoritativos, a pesar de que los datos legítimos estaban en el contexto.

T+15m · Investigador

Confirmación de éxito del envenenamiento en 19 de 20 ejecuciones, demostrando la persistencia e invisibilidad del ataque.

Análisis técnico

Este incidente demuestra un ataque de 'knowledge base poisoning' en un sistema RAG (Retrieval Augmented Generation), clasificado bajo LLM08:2025 – Vector and Embedding Weaknesses en el OWASP LLM Top 10. La causa raíz es la falta de validación y detección de anomalías en la capa de ingesta de documentos en la base de conocimiento. El atacante no explotó una vulnerabilidad de software ni realizó un 'prompt injection' directo, sino que manipuló la fuente de verdad del LLM añadiendo documentos fabricados.

La cascada de fallo se inicia con la ingesta de documentos maliciosos que, mediante 'vocabulary engineering' y 'authority framing', logran una alta similitud semántica con las consultas objetivo y una mayor 'autoridad' percibida por el LLM. Estos documentos desplazan o invalidan los documentos legítimos en el 'top-k retrieval', incluso cuando los datos correctos están presentes en la ventana de contexto del LLM. El LLM, al evaluar múltiples fuentes, prioriza la narrativa de 'corrección' y 'autorización CFO' de los documentos envenenados sobre la información original no adornada.

Las salvaguardas tradicionales fallaron porque el ataque es persistente, invisible y de bajo umbral de entrada. La sanitización de ingesta básica no detecta contenido que parece legítimo. El control de acceso solo limita la colocación, no el solapamiento semántico. El 'prompt hardening' reduce modestamente el éxito, pero no lo elimina. La monitorización de salida basada en patrones es insuficiente porque la respuesta envenenada parece un resumen financiero normal. La debilidad fundamental reside en la confianza implícita en la integridad de la base de conocimiento sin una validación semántica robusta en el punto de ingesta.

Remediaciones y action items

✓ Implementar detección de anomalías de embeddings en la capa de ingesta para identificar documentos sospechosamente similares a los existentes o que forman clusters inusualmente densos.
✓ Mapear y auditar todas las rutas de escritura hacia la base de conocimiento (editores humanos, pipelines automatizados) para asegurar que cada punto de entrada tenga controles de seguridad adecuados.
✓ Establecer un sistema de 'snapshotting' de la base de conocimiento (ej. ChromaDB directory versioning) para permitir la reversión a un estado conocido y limpio en caso de un ataque de envenenamiento.
✓ Mejorar la monitorización de salida con clasificación de intenciones basada en ML (ej. Llama Guard, NeMo Guardrails) en lugar de solo patrones regex, para detectar respuestas que, aunque sintácticamente correctas, son semánticamente maliciosas.
✓ Ajustar la 'temperature' del LLM a valores lo más bajos posible para casos de uso de alto riesgo (informes financieros, legales, médicos) para reducir la probabilidad de respuestas no determinísticas que puedan ser influenciadas por contenido ambiguo o envenenado.

Lecciones para arquitectos

→ La seguridad de los sistemas RAG debe priorizar la integridad de la base de conocimiento en la capa de ingesta, no solo la seguridad del LLM o la monitorización de salida.
→ La confianza implícita en las fuentes de datos es un anti-patrón; toda ingesta de datos en un sistema RAG debe ser tratada como potencialmente maliciosa y validada rigurosamente.
→ Los ataques pueden explotar la semántica y la autoridad percibida por el LLM, no solo vulnerabilidades de código o inyecciones directas.
→ La detección de anomalías basada en embeddings es una defensa potente y de bajo costo que aprovecha artefactos ya existentes en el pipeline de RAG.
→ La persistencia e invisibilidad de los ataques a la base de conocimiento los hace particularmente peligrosos, requiriendo estrategias de defensa proactivas en lugar de reactivas.
→ Un corpus de documentos maduro y diverso puede aumentar la resiliencia contra ataques de envenenamiento, ya que requiere más documentos maliciosos para dominar el contexto del LLM.

¿Te ha gustado este análisis? Recibe los 5 mejores de la semana →

Suscribirme al digest

compartir: X / Twitter LinkedIn WhatsApp