💻 computer science

Conjunctive Poisoning in AI Supply-Chain Applications

Este artículo identifica y demuestra un nuevo ataque de "envenenamiento conjuntivo" en las cadenas de suministro de IA donde desarrolladores maliciosos explotan la interacción débilmente protegida entre los envoltorios de prompts benignos y los metadatos diseñados para alterar determinísticamente los resultados del modelo, y propone el middleware TIF-BAH como una defensa para verificar la integridad del envoltorio y registrar atestaciones de comportamiento.

Autores originales: Nokimul Hasan Arif, Qian Lou, Mengxin Zheng

Publicado 2026-08-18

📖 8 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Nokimul Hasan Arif, Qian Lou, Mengxin Zheng

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo digital moderno, los potentes sistemas de inteligencia artificial han pasado de los laboratorios de investigación a las herramientas cotidianas que utilizamos para escribir, programar y crear imágenes. Estos sistemas, conocidos como modelos de lenguaje de gran tamaño y modelos de lenguaje-visión, se describen a menudo por su "cerebro" interno: la enorme colección de números y patrones que aprendieron durante su entrenamiento. Durante años, los expertos en seguridad han centrado su atención en proteger este cerebro, asegurándose de que los datos de entrenamiento no fueran envenenados y que el modelo en sí no hubiera sido alterado secretamente. Han construido defensas sólidas para verificar los pesos del modelo y para filtrar instrucciones peligrosas enviadas directamente a él. Sin embargo, estos sistemas no operan en el vacío. Antes de que la pregunta de un usuario llegue al modelo, y después de que el modelo genera una respuesta, hay una capa de software que actúa como traductor y gestor. Esta capa, a menudo llamada "wrapper" (envoltorio), toma la entrada del usuario, la formatea en una estructura específica que el modelo entiende y luego procesa la respuesta bruta en una respuesta final y pulida. Junto a este software se encuentran los archivos de configuración, que actúan como manuales de instrucciones que le dicen al wrapper cómo comportarse. Mientras que el cerebro del modelo está fuertemente custodiado, este software circundante y sus manuales de instrucciones han permanecido en gran medida desprotegidos, tratados como texto simple y editable en lugar de componentes de seguridad críticos.

Un equipo de investigadores de la Universidad de Central Florida ha descubierto una vulnerabilidad oculta en esta capa pasada por alto. Demostraron que un desarrollador malintencionado podría crear un paquete engañoso donde el modelo en sí es perfectamente seguro e inalterado, pero el wrapper y sus archivos de configuración están trucados para alterar el comportamiento del sistema. Los investigadores demostraron que, al emparejar un envoltorio de software de apariencia inofensiva con un archivo de configuración cuidadosamente diseñado, un atacante podría obligar al sistema a cambiar su salida de una manera específica y predecible sin tocar nunca el código central del modelo. Este ataque se basa en un mecanismo "conjuntivo", lo que significa que dos condiciones separadas deben cumplirse simultáneamente para que el truco funcione. Una condición es una marca oculta incrustada invisiblemente dentro del código del wrapper, y la otra es una firma criptográfica almacenada en el archivo de configuración. Ninguna de las dos piezas por sí sola es suficiente para activar el cambio; deben estar presentes juntas. Este diseño hace que el ataque sea increíblemente difícil de detectar porque un escaneo que busque solo el código no vería nada sospechoso, y un escaneo que busque solo en el archivo de configuración vería solo una cadena de números de apariencia aleatoria.

Para probar qué tan extendida podría estar esta vulnerabilidad, los investigadores construyeron un experimento controlado utilizando quince sistemas de inteligencia artificial diferentes, que van desde modelos de código abierto que cualquiera puede descargar hasta sistemas cerrados accedidos a través de API comerciales. Desplegaron estos modelos con el wrapper y los archivos de configuración trucados y observaron qué sucedía cuando los usuarios hacían preguntas. Los resultados fueron consistentes y precisos: en cada uno de los casos, cuando se cumplían las dos condiciones, el sistema ejecutaba la instrucción oculta. El wrapper tomaba la respuesta normal y correcta del modelo y anteponía un banner o modificaba el texto antes de mostrárselo al usuario. El modelo en sí no había cambiado de opinión ni de conocimiento; simplemente se le había instruido mediante el wrapper para mostrar la respuesta de manera diferente. Los investigadores encontraron que esta manipulación funcionaba en tareas de solo texto, problemas de razonamiento complejo e incluso tareas de lenguaje-visión donde el modelo observa imágenes. El ataque fue tan efectivo que permaneció indetectado por las herramientas de seguridad estándar que buscan código malicioso o escanean patrones conocidos, porque el activador no era una pieza de código malo, sino una combinación lógica de una marca oculta y una firma de archivo coincidente.

El estudio también exploró qué tan bien las defensas actuales podrían detener este tipo de ataque. Los investigadores probaron varias medidas de seguridad existentes, incluyendo herramientas que escanean archivos de metadatos, sistemas que filtran los prompts de los usuarios y métodos que firman artefactos digitales para probar su autenticidad. Encontraron que la mayoría de estas defensas no lograron detectar el envenenamiento conjuntivo. Los escáneres que miraban solo los archivos de configuración pasaron por alto la marca oculta en el código, y los escáneres que miraban solo el código pasaron por alto la firma criptográfica en los archivos. Incluso las herramientas que firman los pesos del modelo no ayudaron, porque el ataque ocurría en el wrapper y los archivos de configuración, que a menudo se dejaban sin firmar o se trataban como algo separado del paquete principal del modelo. La única forma de detener completamente el ataque en sus pruebas fue firmar todo el conjunto —el modelo, el wrapper y los archivos de configuración juntos— y verificar que ninguno de ellos había sido alterado desde que fueron firmados. Sin esta verificación completa, el sistema permanecía vulnerable a esta forma sutil de manipulación.

Para abordar este vacío, los investigadores propusieron un nuevo mecanismo de defensa llamado Filtro de Integridad de Plantilla con Cabecera de Atestación de Comportamiento (Template Integrity Filter with Behavioral Attestation Header). Este sistema actúa como un guardián que se ejecuta junto al modelo durante su operación. Antes de que el wrapper tenga permitido procesar una respuesta, el sistema verifica el código del wrapper contra una versión de confianza previamente aprobada para asegurar que no ha sido manipulado. Si el código coincide con la versión de confianza, el sistema permite que el proceso continúe; si no coincide, el sistema bloquea la acción y recurre a una salida segura y no modificada. Además, este sistema registra una pequeña entrada de log para cada interacción, anotando exactamente qué versión del wrapper se utilizó y qué decisión se tomó. Esto crea un registro permanente que puede ser auditado posteriormente para ver si se realizaron cambios no autorizados. Los investigadores encontraron que añadir esta capa de protección introducía casi ningún retraso a la velocidad del sistema, añadiendo menos del medio por ciento al tiempo que tomaba generar una respuesta, lo que lo convierte en una solución práctica para aplicaciones del mundo real.

Las implicaciones de este trabajo se extienden más allá de encontrar un nuevo error; cambia fundamentalmente cómo debemos pensar sobre la seguridad de la inteligencia artificial. Durante mucho tiempo, la industria ha asumido que si el cerebro del modelo es seguro, el sistema es seguro. Esta investigación muestra que el "cuerpo" del sistema —el software que envuelve al modelo y los archivos que le dicen cómo comportarse— es igual de crítico. Un atacante no necesita romper la entrada de datos de entrenamiento del modelo o reescribir su lógica interna para cambiar lo que un usuario ve. Solo necesita introducir una instrucción oculta en el wrapper y una clave coincidente en el archivo de configuración. Esto es similar a cómo un chef de confianza podría recibir una receta que parece normal pero incluye una instrucción secreta de añadir una especia específica solo si un ingrediente determinado está presente en la despensa; el chef sigue la receta perfectamente, pero el plato final es alterado por las instrucciones, no por sus propias elecciones. Los investigadores enfatizan que, aunque sus experimentos usaron cambios inofensivos, como añadir un banner o un descargo de responsabilidad, el mismo mecanismo podría usarse para ocultar instrucciones peligrosas, alterar recomendaciones o manipular citas de maneras que sean invisibles para el usuario.

El estudio concluye que la capa de plantillas, donde viven los wrappers y los archivos de configuración, es una parte crítica pero insuficientemente protegida de la cadena de suministro de la inteligencia artificial. A medida que estos sistemas se integran más en nuestras vidas diarias, apoyándose en ellos para todo, desde el servicio al cliente hasta el asesoramiento médico, la integridad de todo el paquete de despliegue debe ser verificada, no solo el modelo en sí. Los investigadores han puesto su código y herramientas a disposición para ayudar a otros desarrolladores a probar sus propios sistemas para esta vulnerabilidad. Al resaltar esta debilidad específica, esperan fomentar el desarrollo de nuevos estándares que traten el código del wrapper y los archivos de configuración con el mismo nivel de escrutinio y protección que los propios pesos del modelo, asegurando que el comportamiento que ven los usuarios sea realmente lo que el modelo pretendía producir.

Resumen Técnico: Envenenamiento Conjuntivo en Aplicaciones de la Cadena de Suministro de IA

1. Planteamiento del Problema

El artículo identifica una capa crítica y poco protegida en la cadena de suministro de los Modelos de Lenguaje de Gran Escala (LLM) y los Modelos de Lenguaje-Visión (VLM): la capa de plantillas de despliegue. Mientras que los pesos de los modelos, los binarios y los datos de entrenamiento se verifican rutinariamente mediante firmas y hashes, los artefactos textuales que median las entradas y salidas de los modelos en el momento de la inferencia —específicamente las plantillas de envoltorio (lógica ejecutable para la construcción de prompts y el post-procesamiento) y los metadatos de configuración (por ejemplo, archivos JSON/YAML)— permanecen en gran medida mutables y débilmente protegidos.

Los autores argumentan que un desarrollador malintencionado puede emparejar un envoltorio aparentemente benigno con metadatos diseñados para alterar determinísticamente el comportamiento post-generación sin modificar los pesos del modelo, los datos de entrenamiento o el backend de inferencia. Esto crea un "riesgo de comportamiento en el tiempo de despliegue" que es invisible para las defensas centradas únicamente en los internos del modelo o en los inputs de los prompts. La superficie de ataque es análoga a los incidentes de la cadena de suministro de software como SolarWinds o xz-utils, donde una única dependencia modificada afecta a los sistemas descendentes, pero aplicado a la infraestructura textual que rodea a los modelos de IA.

2. Metodología

Los autores proponen y evalúan un mecanismo de ataque de Envenenamiento Conjuntivo utilizando una implementación de puerta conjuntiva controlada.

Mecanismo de Ataque

El ataque se basa en una condición lógica AND ( $C_1 \land C_2$ ) que debe satisfacerse simultáneamente para activar una carga útil maliciosa:

Marcador de Envoltorio Oculto ( $C_1$ ): El atacante incrusta una cadena de marcador visualmente inocua dentro del código del envoltorio.
Metadatos Vinculados Criptográficamente ( $C_2$ ): El atacante publica un archivo de metadatos que contiene digestos criptográficos (HMACs y hashes SHA-256) derivados del marcador y del código del envoltorio normalizado.
Verificación en Tiempo de Ejecución: En el momento de la inferencia, la lógica del envoltorio vuelve a calcular estos digestos utilizando una clave secreta $k$ $k$ (conocida solo por el atacante y provista externamente, no en los artefactos públicos). La puerta se activa solo si:
- El HMAC recalculado del marcador coincide con el digest del metadato.
- El hash SHA-256 recalculado del envoltorio canonicalizado coincide con el digest del metadato.

Si ambas condiciones se cumplen, el envoltorio ejecuta una acción post-generación (por ejemplo, anteponer un banner, modificar avisos legales o alterar el formato de salida). Si alguna de las comprobaciones falla, el sistema produce la salida normal y no modificada. Este diseño garantiza sigilo (los archivos parecen benignos bajo inspección estática), persistencia (el comportamiento sobrevive a cambios de formato pero falla ante ediciones semánticas) y exclusividad (solo el atacante con la clave secreta puede activar la lógica).

Configuración Experimental

El estudio evalúa este mecanismo a través de 15 despliegues representativos, incluyendo:

Modelos: LLMs de código abierto (ej. Llama-3.2, Mistral, Qwen), VLMs de código abierto (ej. Qwen-VL, LLaVA) y modelos basados en API/Cerrados (ej. GPT-5.4-mini, Claude 3.7, Gemini 2.5).
Tareas: Clasificación de texto, razonamiento (matemáticas, sentido común) y tareas de lenguaje-visión (VQA, descripción de imágenes).
Casos de Ablación: Los autores comparan cuatro configuraciones: (a) Línea base limpia, (b) Triggers de solo metadatos, (c) Triggers de solo envoltorio, y (d) El ataque conjunto completo (envoltorio-metadato vinculado).
Defensas Evaluadas: Inspección de metadatos estáticos, escáneres de envoltorios, PromptShield (detección de inyección de prompts) y firma de artefactos basada en SigStore (firma parcial vs. completa del bundle).

3. Contribuciones Clave

Identificación del Riesgo de la Capa de Plantilla: El artículo establece que la lógica del envoltorio y los metadatos de configuración pueden alterar conjuntamente el comportamiento post-generación sin tocar los pesos del modelo, creando un nuevo vector de ataque en la cadena de suministro de la IA.
Implementación de la Puerta Conjuntiva: Los autores demuestran cómo las condiciones de artefactos cruzados (vincular un marcador oculto a un digest de metadatos) hacen que las manipulaciones de la capa de plantilla sean significativamente más difíciles de detectar mediante la inspección local de artefactos en comparación con los ataques de vector único.
Evaluación Empírica: Una evaluación a gran escala a través de 15 modelos y 75 grupos de configuración confirma que la puerta conjunta se activa de forma determinista con una latencia de sobrecarga insignificante (<0.5%).
Análisis de Defensa y Propuesta: El estudio muestra que las defensas existentes (filtros de prompts, firma parcial) no protegen totalmente la capa de plantilla. Los autores introducen TIF-BAH (Filtro de Integridad de Plantilla con Cabecera de Atestación de Comportamiento), un middleware ligero que verifica la integridad del envoltorio contra una referencia confiable y registra atestaciones de comportamiento para la auditabilidad.

4. Resultados

Éxito del Ataque: La puerta conjunta logró un 100% de corrección al activar el comportamiento previsto en todos los modelos probados cuando ambos predicados se satisfacían. En un escenario de despliegue de alta fidelidad alojado en Hugging Face Spaces, la aplicación conjunta específicamente logró una tasa de precisión de ataque del 100% sin activar ninguna advertencia de seguridad del sistema de la plataforma. El ataque se mantuvo sigiloso, evadiendo los escáneres de metadatos estáticos y los escáneres de texto de envoltorio que no podían razonar sobre el vínculo criptográfico.
Visibilidad de la Carga Útil: Antes de las defensas, el éxito de la carga útil (visibilidad del comportamiento manipulado) osciló entre 0.91 y 1.00. Las defensas existentes redujeron esta visibilidad pero no la eliminaron:
- Inspector Estático/Escáner de Envoltorio: Redujo el éxito de la carga útil a ~0.71–0.77, pero no logró bloquear la ejecución de la puerta.
- PromptShield: Redujo aún más la visibilidad (~0.68–0.76) al filtrar el contenido generado, pero no inspeccionó la lógica de ejecución del envoltorio.
- SigStore (Parcial): Ineficaz, ya que los archivos de envoltorio y metadatos a menudo quedan fuera del límite de confianza firmado.
Utilidad de la Tarea: La inyección de cargas útiles (ej. banners, avisos legales) tuvo un impacto mínimo en el rendimiento de la tarea subyacente (precisión, puntuaciones F1) para tareas de clasificación y razonamiento, ya que los parsers a menudo podían ignorar el texto inyectado. Sin embargo, las tareas que dependen de la similitud de la forma superficial (ej. COCO Captions) mostraron caídas mayores en el F1 de tokens antes de la eliminación de la carga útil.
Latencia: La evaluación de la puerta introdujo una sobrecarga insignificante, con aumentos de latencia media inferiores al 0.5% y una latencia p95 inferior a 6 ms en todas las clases de modelos.

5. Significado y Reivindicaciones

El artículo sostiene que la capa de plantilla es un componente crítico pero insuficientemente protegido en los despliegues modernos de IA. La importancia de este trabajo radica en desplazar el enfoque de seguridad de los pesos del modelo y los datos de entrenamiento hacia los artefactos textuales mutables que gobiernan el comportamiento en tiempo de ejecución.

Limitaciones de las Defensas Actuales: Los autores enfatizan que las protecciones centradas únicamente en prompts, outputs o artefactos parcialmente firmados son insuficientes. Argumentan que tratar los envoltorios y metad datos como "archivos de configuración auxiliares" en lugar de "artefactos de lanzamiento críticos para la integridad" es un fallo fundamental en las prácticas actuales de seguridad de la cadena de suministro de ML.
Solución Propuesta: El artículo aboga por TIF-BAH como un complemento necesario en tiempo de ejecución para la firma de artefactos. Afirma que, si bien la firma de todo el bundle (incluyendo envoltorios y metadatos) bloquearía teóricamente el ataque, esto rara vez se implementa en los hubs abiertos. Por lo tanto, la verificación en tiempo de ejecución de la integridad del envoltorio contra una referencia confiable es esencial para cerrar esta brecha.
Alcance Ético: Los autores declaran explícitamente que sus cargas útiles son proxies benignos (ej. banners, avisos legales) diseñados para demostrar el control del comportamiento sin permitir acciones dañinas. No pretenden haber descubierto técnicas criptográficas novedosas, sino la aplicación novedosa del vínculo entre artefactos a la capa de despliegue de la IA.

En conclusión, el artículo postula que, sin tratar la integridad de los envoltorios y metadatos como un límite de seguridad primario, los sistemas de IA siguen siendo vulnerables a la manipulación del comportamiento en el tiempo de despliegue, la cual es invisible para las defensas tradicionales centradas en el modelo.