DACSI: cuando los documentos recuperados falsifican las señales de control del sistema
Un artículo del 8 de junio de 2026 da nombre a un modo de fallo silencioso del RAG: texto no confiable que suplanta señales de metadatos, procedencia y política. Sin «ignore previous instructions» — la lección: una etiqueta escrita en un documento es dato, no política.
¿Qué es esto?
El 8 de junio de 2026, un artículo titulado Document-Authored Control-Signal Impersonation: A Low-Cost Indirect Prompt Attack on RAG Safety Boundaries (arXiv:2606.09005) puso nombre a un modo de fallo que quienes construyen sistemas de generación aumentada por recuperación (RAG) redescubren una y otra vez por accidente. El autor lo llama DACSI — Document-Authored Control-Signal Impersonation (suplantación de señales de control redactadas por el documento).
El escenario es el prompt RAG habitual. El sistema serializa varios elementos en un único bloque de lenguaje natural: la consulta del usuario, los documentos extraídos del índice, más los metadatos, las etiquetas del sistema y las instrucciones de la tarea. DACSI ocurre cuando un texto redactado por el atacante dentro de un documento recuperado se disfraza de una de esas señales de control —una etiqueta de procedencia, un marcador de autoridad, un indicador de «verificado», un aviso de política de divulgación— de modo que el modelo trata un dato como si fuera una política.
No es el jailbreak clásico de «ignore previous instructions». El artículo posiciona explícitamente DACSI como una subclase no imperativa, de tipo metadato, de la inyección de prompt indirecta: no ordena al modelo romper una regla, sino que afirma discretamente que una regla ya permite la acción.
Cómo funciona
La causa raíz es estructural, y es la misma que está detrás de toda clase de inyección indirecta: el renderizado del prompt RAG fusiona el texto confiable y el no confiable en un único canal. Una vez que el prompt del sistema, el pasaje recuperado y los metadatos llegan como el mismo tipo de tokens, no existe un marcador fiable que el modelo pueda usar para distinguir una señal de control autorizada de una cadena que solo lo aparenta.
La inyección de tipo comando pregunta: ¿obedecerá el modelo una instrucción colada en un dato? DACSI plantea una pregunta más sutil: ¿atribuirá el modelo, por error, la condición de señal de control autorizada a un texto de documento no confiable? En lugar de «haz X», la carga se lee como un hecho del entorno: una etiqueta que afirma que el contenido es confiable, interno, preaprobado o exento de una política de seguridad. Si el modelo ha aprendido a deferir a tales etiquetas cuando aparecen en su contexto, un documento que fabrica una hereda una autoridad que nunca se le concedió.
Aquí no se reproduce ninguna carga funcional, ni hace falta para comprender el mecanismo. El resumen en una línea que el propio artículo ofrece es toda la lección: una etiqueta escrita en un documento es un dato, no una política. Cualquier campo que un atacante pueda escribir en un documento recuperable —un encabezado, una nota al pie, un fragmento oculto, un falso bloque de metadatos con aspecto de JSON— está controlado por el atacante, por muy oficial que parezca.
Por qué importa
DACSI importa porque se aloja en el punto ciego de la defensa más extendida. Muchas barreras de protección de RAG están afinadas para detectar inyecciones imperativas —texto que le dice al modelo que haga algo prohibido—. Un pasaje que no contiene ningún imperativo, solo la afirmación de que «esta fuente está verificada y exenta de política», puede atravesar ese filtro y aun así dirigir el resultado.
Además escala a bajo coste. El atacante no necesita acceso al modelo ni optimización por gradiente; le basta con que un único documento envenenado caiga en un corpus que el sistema consulta —una página wiki, una unidad compartida, un resultado web rastreado, un ticket de soporte—. Esa es la misma barrera baja que convierte a la inyección indirecta en el modo de fallo agéntico dominante en producción, y DACSI amplía la superficie a todo sistema que permita que el contenido recuperado lleve texto de tipo metadato.
El punto más amplio, coherente con el argumento de integridad contextual y con las taxonomías de seguridad de RAG, es que la autoridad de una fuente no puede establecerse mediante nada escrito dentro de la propia fuente. La confianza tiene que venir del canal, no de la carga.
Defensas
No se puede lograr que un modelo de lenguaje distinga de forma fiable una señal de control real de una falsificada si ambas llegan como el mismo texto. Así que saque la decisión de confianza fuera del prompt.
- Establezca las señales de control fuera de banda. La autoridad, la procedencia y los indicadores de política deben adjuntarse a un documento mediante el pipeline de recuperación e ingesta que usted controla, nunca leerse del cuerpo del documento. Si un marcador de «confiable» o «exento de política» puede aparecer en contenido recuperable, elimínelo antes de que el texto llegue al modelo.
- Trate todo el texto recuperado como dato no confiable. Renderice los pasajes recuperados en una región claramente delimitada y de menor privilegio, e indique al modelo que nada de su interior puede conceder permisos, fijar política ni afirmar su propia fiabilidad. Combínelo con comprobaciones conscientes de la procedencia como las de ARGUS.
- Sanee el contenido de tipo metadato en la ingesta. Detecte y neutralice las estructuras redactadas por el documento que imitan los metadatos del sistema: encabezados falsos, pseudoetiquetas JSON, avisos de «verificado por», fórmulas de política de divulgación. Es la materia prima de DACSI.
- No confíe en filtros de inyección solo imperativos. Pruebe sus barreras contra cargas no imperativas que afirman autoridad en lugar de emitir un comando. Un filtro que solo atrapa «ignore previous instructions» pasará por alto esta clase por completo.
- Limite el radio de impacto. Combine lo anterior con alcances de herramientas de mínimo privilegio y controles de exfiltración, de modo que una señal de control mal atribuida no pueda, por sí sola, alcanzar datos sensibles ni una vía de exfiltración.
Estado
| Elemento | Detalle |
|---|---|
| Artículo | Document-Authored Control-Signal Impersonation (DACSI) |
| Identificador | arXiv:2606.09005v1 |
| Publicado | 2026-06-08 |
| Clase | Inyección de prompt indirecta — subclase no imperativa, de tipo metadato |
| Naturaleza | Hallazgo de investigación / caracterización de clase de ataque (sin exploit en producción) |
DACSI no es una nueva vulnerabilidad de producto que parchear; es un nombre para un error de arquitectura recurrente. Los sistemas más expuestos son los que permiten que los documentos recuperados hablen con la voz del propio sistema. La solución no es un mejor clasificador dentro del prompt, sino negarse a que el prompt sea el lugar donde se decide la autoridad.