DrainCode: denegación de servicio por energía y coste vía envenenamiento del corpus RAG

¿Qué es esto?

Casi todo el trabajo publicado sobre el envenenamiento de un corpus de generación aumentada por recuperación (RAG) apunta a la integridad: hacer que el modelo responda de forma errónea, que recomiende el producto de un atacante o que filtre datos. «DRAINCODE: Stealthy Energy Consumption Attacks on Retrieval-Augmented Code Generation via Context Poisoning» (arXiv:2601.20615), de Yanlin Wang y sus colegas de la Universidad Sun Yat-sen, Huawei Cloud y la Nanyang Technological University, ataca una propiedad distinta: la disponibilidad y el coste. El ataque envenena el corpus de recuperación de un sistema de generación de código para que la respuesta siga siendo funcionalmente correcta, pero el modelo gaste muchos más tokens, latencia y energía en producirla.

El encuadre es oportuno. Un panorama más amplio publicado dos meses después, «Securing Retrieval-Augmented Generation: A Taxonomy of Attacks, Defenses, and Future Directions» (arXiv:2604.08304, abril de 2026), nombra explícitamente la disponibilidad — el «abuso de denegación y rechazo» — como una de las clases de ataque RAG reconocidas, junto a la desinformación y la exfiltración. DrainCode es una instancia concreta de esa clase poco estudiada, dirigida específicamente al ámbito de los asistentes de código, donde el RAG ya es estándar.

Cómo funciona

Un asistente de código RAG recupera fragmentos de un corpus y los coloca en el contexto del modelo antes de la generación. DrainCode envenena ese corpus con fragmentos sintácticamente válidos y semánticamente inertes — parecen código auxiliar corriente — pero diseñados para empujar al modelo hacia una salida verbosa en lugar de detenerse pronto.

El artículo describe tres ingredientes conceptuales, ninguno de los cuales requiere conocer de antemano las consultas de la víctima:

• Un paso de construcción de consultas hipotéticas genera preguntas plausibles a partir de un fragmento recuperado, haciendo que el veneno sea independiente de la consulta — no depende de predecir qué pedirán los usuarios (una limitación de los ataques RAG previos).
• Un proceso de mutación guiada por gradiente optimiza el disparador inerte con dos objetivos simultáneos: un término de fin de secuencia (EOS) que suprime la terminación temprana para que el modelo siga generando, y una restricción de divergencia KL que mantiene la distribución de salida cercana al caso limpio para que el código generado siga siendo correcto.
• Una capa de eficiencia — mutación multiposición y un búfer de reutilización — que hace converger el envenenamiento del corpus varias veces más rápido que los ataques energéticos anteriores.

El resultado es una «verbosidad forzada»: código más largo pero correcto. Los autores informan de hasta 3×–10× de aumento en la longitud de salida, ~85 % más de latencia y ~49 % más de energía, preservando un 95–99 % de exactitud funcional en los modelos probados. Es clave que, como el código sigue pasando las pruebas y el texto del disparador no está manifiestamente malformado, el ataque eludió tanto los filtros basados en clasificador como los basados en perplejidad en su evaluación. Aquí no se reproduce ninguna cadena de disparador envenenada; el mecanismo se resume solo a nivel conceptual.

Por qué importa

Es un vector de denegación de servicio — y de «denegación de cartera» — oculto tras la corrección. La mayoría de la monitorización del envenenamiento RAG vigila salidas erróneas, dañinas o fuera de política. Un ataque que deja la respuesta correcta pero triplica el coste se cuela por esos controles. A escala de un asistente integrado en el IDE que se dispara con cada pulsación o guardado, un impuesto de verbosidad sostenido se traduce directamente en contención de GPU, facturas de inferencia más altas, respuestas más lentas para otros usuarios concurrentes y — en flotas autoalojadas — una sobrecarga real de energía y carbono. El riesgo «Unbounded Consumption» de OWASP para aplicaciones LLM captura exactamente este modo de fallo.

El corpus es el punto débil. Los sistemas de código RAG indexan habitualmente grandes conjuntos de código semifiables — monorepos internos, instantáneas de dependencias, repositorios públicos extraídos — que pocos equipos tratan como un activo sensible a la seguridad. Un solo fragmento envenenado que sobreviva a la recuperación puede imponer el impuesto de verbosidad a cada consulta que lo invoque, sin interacción del usuario y sin violación de integridad que active una alerta.

Defensas

Como DrainCode está diseñado para burlar los clasificadores de contenido y los filtros de perplejidad, la defensa debe desplazarse hacia el pipeline y el presupuesto, no solo el texto.

Limite el radio de impacto en el momento de la generación. Imponga presupuestos de tokens y de tiempo por solicitud y un max_tokens razonable, y trate la inflación sostenida de la longitud de salida como una señal de anomalía de primer orden, no como una mera molestia de calidad. Siga la distribución de la longitud de salida, la latencia y la energía por clase de consulta; toda la firma de DrainCode es un camino anormalmente largo para una respuesta corriente. Aplique límites de tasa y techos de coste por usuario y por clave, conforme a la guía de OWASP sobre consumo no acotado.

Endurezca el corpus como un activo de seguridad. La taxonomía RAG insiste en la integridad de la base de conocimiento, la procedencia y la remediación: cure y firme las fuentes indexadas, restrinja quién puede escribir en el almacén de recuperación y conserve la procedencia para poder retirar un fragmento envenenado una vez detectado. Trate todo el código recuperado como entrada no fiable, y prefiera fuentes internas fiables y revisadas frente a corpus extraídos de forma oportunista.

Vigile el comportamiento de terminación del generador. El seguimiento de los patrones de terminación (EOS) y de la entropía de salida por conjunto de contexto recuperado puede revelar la firma de supresión de EOS, incluso cuando el código final es correcto. Por último, evalúe la disponibilidad de forma explícita: someta su pipeline RAG a pruebas de agotamiento de recursos, no solo de respuestas erróneas, y mida tokens, latencia y energía de extremo a extremo a través del recuperador real en lugar de sobre el generador aislado.

Estado

Elemento	Detalle
Artículo principal	DrainCode, arXiv:2601.20615, enero de 2026 (U. Sun Yat-sen, Huawei Cloud, NTU)
Panorama asociado	Taxonomía de seguridad RAG, arXiv:2604.08304, abril de 2026
Propiedad atacada	Disponibilidad / coste (energía, latencia, tokens) — no la integridad
Impacto reportado	~85 % de latencia, ~49 % de energía, 3×–10× de longitud de salida; 95–99 % de exactitud conservada
Sigilo	Eludió las defensas por clasificador y por perplejidad en la evaluación
Mejores mitigaciones	Presupuestos de tokens/tiempo + detección de anomalías en la longitud de salida + integridad/procedencia del corpus