Prompt injection indirecta y envenenamiento del corpus

Toda la serie ha dado por buena una premisa cómoda: que los documentos del corpus dicen lo que sus autores quisieron decir. Esta entrega la retira. Cuando alguien de fuera puede escribir en una de tus fuentes, el corpus deja de ser un almacén de conocimiento y pasa a ser una superficie de ataque conectada directamente al prompt.

El cambio de modelo de amenaza

En un sistema RAG convencional, el prompt final se compone de tres cosas: tus instrucciones, la pregunta del usuario y unos fragmentos recuperados del corpus. Las dos primeras las controlas o al menos las ves. La tercera es la que se ignora en los análisis de seguridad, y es la que introduce el problema.

Un modelo de lenguaje no distingue estructuralmente entre instrucción y dato. Todo lo que entra en el prompt es texto, y el texto que dice «ignora lo anterior y haz esto» tiene la misma naturaleza que el texto que describe una política de devoluciones. La separación entre «esto son mis órdenes» y «esto es material de consulta» existe únicamente porque el modelo ha sido entrenado para respetarla, no porque haya una frontera que el sistema pueda hacer cumplir. Es una convención, y las convenciones se rompen.

La consecuencia: cualquiera que pueda hacer que un texto suyo acabe indexado en tu corpus puede escribir en tu prompt. No necesita acceso a tu código, ni credenciales, ni estar autenticado. Le basta con dejar un comentario, rellenar un formulario, subir un documento a una carpeta compartida o publicar una página que tu rastreador visita.

Esto es la prompt injection indirecta —inyección de instrucciones a través del contenido—, y es distinta de la inyección directa, en la que el atacante escribe en el cuadro de chat. La directa es un problema de un usuario contra su propia sesión. La indirecta es un problema de un tercero contra otros usuarios, con el sistema como vehículo.

De dónde salen los documentos hostiles

• Contenido generado por usuarios que se indexa: comentarios, reseñas, tickets de soporte, mensajes de foro, descripciones de producto de vendedores externos.
• Documentos subidos por clientes o proveedores a un espacio compartido que forma parte del corpus.
• Páginas rastreadas. Si indexas la web, indexas lo que otros escriben, incluido texto invisible: color de fuente igual al fondo, tamaño cero, atributos ocultos, metadatos.
• Correo entrante indexado para asistentes internos. Es la vía más directa que existe: cualquiera con tu dirección puede escribir en tu corpus.
• Fuentes internas mal gobernadas. Un wiki abierto a toda la organización es, en la práctica, una fuente semipública.

Los tres ataques

Inyección indirecta a través de un fragmento recuperado

El atacante coloca en un documento un texto dirigido al modelo, no al lector humano. Cuando ese fragmento se recupera para responder a la pregunta de otro usuario, sus instrucciones entran en el prompt junto con el resto del contexto.

Lo que se puede conseguir con eso depende de lo que el sistema sepa hacer. En un RAG que sólo redacta texto, el techo es manipular la respuesta: recomendar un producto, desacreditar a un competidor, dar una instrucción falsa al usuario, o hacer que el sistema afirme algo perjudicial con la autoridad de la marca. En un RAG con herramientas —agentic RAG, la entrega 21— el techo sube muchísimo: si el modelo puede llamar a una API, enviar un correo o consultar otro índice, la instrucción inyectada puede intentar que lo haga. La superficie de ataque de un RAG con herramientas es cualitativamente distinta de la de un RAG que sólo responde, y esa es la razón principal para no dar herramientas con efectos secundarios a un sistema que lee contenido no confiable.

Envenenamiento del índice

Aquí no se busca dar órdenes, sino mentir de forma que la mentira se recupere. Dos variantes.

La primera es de contenido: introducir en el corpus documentos con información falsa pero verosímil sobre un tema concreto, confiando en que la recuperación los encuentre. Si el corpus tiene poca cobertura sobre ese tema, basta con un documento bien colocado para dominar las respuestas de esa pregunta.

La segunda es de recuperación: redactar el documento hostil de modo que se recupere más de lo que le correspondería, incluyendo muchas formulaciones de la misma pregunta e imitando el estilo de las consultas de los usuarios. Es posicionamiento aplicado al índice vectorial, y funciona por la misma razón por la que funcionaba en los buscadores.

Exfiltración a través de la respuesta

El objetivo aquí es sacar datos del sistema. La instrucción inyectada pide al modelo que incluya en su respuesta información de otros fragmentos del contexto —o del prompt de sistema— y que la codifique de una forma que llegue al atacante: dentro de una URL que el usuario vaya a pulsar, en los parámetros de una imagen que el cliente cargue automáticamente, o simplemente en texto que el usuario copie.

La variante con imágenes es la más silenciosa: si tu interfaz renderiza Markdown y carga imágenes remotas, un fragmento inyectado puede lograr que el navegador del usuario haga una petición a un servidor ajeno con datos en la URL, sin que nadie pulse nada. Renderizar Markdown enriquecido en la respuesta de un RAG que lee contenido no confiable es una decisión de seguridad, aunque se tome como decisión de diseño visual.

Defensas

Ninguna de las siguientes resuelve el problema. Juntas, y por capas, reducen mucho la probabilidad y el alcance.

Procedencia y niveles de confianza

La defensa más rentable, y la que casi nadie implementa: cada fragmento del índice lleva una etiqueta de confianza según su origen. Documentación interna revisada, contenido de usuario, página rastreada, correo entrante. Esa etiqueta se usa en tres sitios: para decidir si el fragmento puede entrar en el contexto de determinadas consultas, para ponderar su peso en el ranking, y para instruir al modelo sobre cómo tratarlo.

La regla operativa que se deriva es dura pero clara: el contenido no confiable puede citarse como testimonio («un usuario escribió que…») y nunca usarse como fuente de verdad para afirmaciones del sistema.

Sanitización en la ingesta

Se hace en la ruta de indexación, no en la de consulta. Extraer sólo texto visible, descartar contenido oculto por CSS o atributos, eliminar comentarios HTML y normalizar caracteres invisibles y de control. Filtrar patrones imperativos dirigidos al modelo ayuda algo, pero es una carrera perdida: cualquier lista de frases prohibidas se evade parafraseando, traduciendo o codificando. Trátalo como reducción de ruido, no como control de seguridad.

Separación estricta entre datos e instrucciones

En el prompt, los fragmentos van en un bloque claramente delimitado, con marcas de apertura y cierre que se escapan si aparecen en el contenido, y con una instrucción del sistema que declara explícitamente que ese bloque es material de consulta y que ninguna instrucción contenida en él debe obedecerse. Ayuda de forma medible. No es una garantía, y hay que decirlo con todas las letras: es una petición al modelo, y el modelo puede no atenderla.

Complementos que sí son estructurales: no permitir que el contenido recuperado influya en la elección de herramientas, mantener las decisiones de control fuera del texto generado, y validar la salida contra un esquema cuando la respuesta alimenta a otro sistema.

Permisos de escritura sobre el corpus

Antes de defenderte de lo que entra, pregúntate quién puede hacer que entre algo. La lista de fuentes con escritura efectiva por terceros suele ser más larga de lo que el equipo cree. Reducirla es la medida más eficaz y la que menos tecnología requiere: moderación previa, dominios permitidos para el rastreo, cuarentena para documentos subidos.

Contención del alcance

Asumiendo que la inyección ocurrirá alguna vez, limita lo que puede lograr. Sin herramientas con efectos secundarios en flujos que leen contenido no confiable. Sin renderizado de imágenes remotas ni enlaces automáticos en las respuestas. Los permisos del usuario aplicados en la recuperación, para que el contexto nunca contenga nada que ese usuario no pudiera ver de todos modos —lo que es también la mejor defensa contra la exfiltración, y el tema de la entrega siguiente—. Y salida por dominios permitidos si el sistema puede llamar a algo.

Auditoría

La traza por consulta que recomienda esta serie es también el registro forense: qué fragmentos entraron en cada respuesta y de qué documento venían. Sin ella, un incidente es imposible de investigar. Con ella, se puede responder a «¿qué respuestas se vieron afectadas por este documento entre estas dos fechas?», que es la primera pregunta que hará cualquiera cuando el incidente ocurra. Vigila además el ritmo de escritura por fuente: un pico de documentos nuevos desde un origen concreto es una señal barata y útil.

No hay solución completa

Conviene ser explícito, porque el mercado no lo es. La inyección indirecta de instrucciones no tiene solución conocida. No existe una sanitización que separe de forma fiable instrucciones de datos en texto libre, porque la distinción no es sintáctica sino de intención, y la intención se puede expresar de infinitas formas. No existe un modelo inmune, aunque unos resistan mejor que otros. No existe un filtro de salida que detecte toda manipulación.

Lo que existe es gestión de riesgo: reducir quién puede escribir en el corpus, etiquetar la procedencia, limitar lo que el sistema puede hacer con lo que lee, y registrar todo para poder investigar. Un sistema que sólo lee documentación interna revisada y sólo redacta texto tiene un riesgo manejable. Un sistema que lee la web abierta, tiene herramientas con efectos secundarios y renderiza HTML enriquecido tiene un problema serio, y ninguna configuración de prompt lo va a resolver.

Qué viene ahora

La siguiente entrega desarrolla la defensa que aquí ha quedado apuntada: control de acceso granular. Por qué el filtrado por permisos tiene que ocurrir dentro de la recuperación y nunca después de generar la respuesta, cómo se sincronizan los permisos desde el sistema de origen sin que se desfasen, y las tres estrategias para aislar varios clientes en una misma infraestructura, con lo que cada una cuesta en aislamiento, dinero y operación.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.