Una investigación de Eclypsium muestra cómo el hardware comprometido puede alterar modelos de IA durante la ejecución

Eclypsium ha demostrado cómo una infraestructura informática comprometida puede cambiar el comportamiento de un modelo de IA durante la inferencia, aunque sus archivos originales permanezcan intactos. La investigación, publicada el 29 de octubre en La IA confiable requiere una infraestructura confiable, muestra por qué comprobar la firma o el hash de un archivo del modelo no garantiza la integridad del modelo que se ejecuta en la memoria.

En una demostración controlada con el apoyo de NVIDIA, los investigadores utilizaron una unidad de procesamiento de datos, o DPU, comprometida, junto con una configuración permisiva del aislamiento de memoria, para modificar los pesos del modelo durante la ejecución. Las respuestas del modelo cambiaron sin modificar el modelo almacenado ni el servicio de inferencia. Este hallazgo sitúa el hardware, el firmware y la configuración de los dispositivos dentro del perímetro de seguridad de la IA.

Otra forma de modificar un modelo de IA

Los debates sobre seguridad de la IA suelen centrarse en las instrucciones maliciosas, los datos de entrenamiento envenenados y el uso inseguro de herramientas. Esta investigación examina una capa más profunda: la infraestructura que almacena y transfiere los parámetros de un modelo mientras se ejecuta.

Los pesos son los parámetros numéricos que determinan las respuestas de un modelo. Un archivo válido en el disco puede cargarse en la memoria y, posteriormente, ser modificado por un componente con suficientes privilegios. Una comprobación posterior del archivo original sigue encontrando los bytes esperados, aunque la respuesta se haya generado a partir de un estado alterado durante la ejecución.

La demostración de Eclypsium cambió de forma visible el resultado de un análisis sobre una cuestión geopolítica. La preocupación más amplia es que la manipulación durante la ejecución podría afectar a otros usos sensibles, como la generación de código y la toma de decisiones automatizada. Estas posibilidades deben distinguirse del comportamiento específico observado en el laboratorio.

La afirmación de que el cambio pasó inadvertido también tiene un alcance definido: las comprobaciones de integridad del modelo almacenado utilizadas en la demostración no detectaron las modificaciones en la memoria. Eso no demuestra que estas sean invisibles para todas las formas de supervisión o análisis forense.

Las condiciones del ataque son importantes

La prueba se realizó en un entorno NVIDIA Grace Hopper. La vía de acceso directo a la memoria dependía de un componente privilegiado comprometido y de una configuración que permitía acceder a memoria sensible. Los investigadores señalan el paso directo de IOMMU y el aislamiento permisivo de PCIe como condiciones importantes, y destacan explícitamente que no eran los ajustes predeterminados de Linux.

Una IOMMU ayuda a controlar a qué memoria puede acceder un periférico. En la configuración de aislamiento más estricto que probaron los investigadores, no era posible utilizar la misma vía directa. Por tanto, el resultado subraya la importancia de verificar la configuración real del entorno, en lugar de dar por sentado que una capacidad de seguridad instalada está aplicando activamente un límite.

Una DPU es un procesador de infraestructura programable que se utiliza para servicios de redes, almacenamiento y seguridad. Su capacidad para transferir datos de forma eficiente resulta valiosa, pero los privilegios necesarios para las funciones legítimas de infraestructura pueden volverse peligrosos si un atacante toma el control del componente.

La respuesta de NVIDIA: verificar los límites de confianza

En su relato de la colaboración, NVIDIA describe el arranque autenticado de BlueField, la confianza basada en hardware, el aislamiento, las protecciones de las actualizaciones de firmware y la atestación. También destaca que los operadores de la nube eligen distintas configuraciones de seguridad en función de diferentes modelos de confianza.

El mensaje de las empresas es que los operadores necesitan pruebas que respalden esas decisiones. Los controles de acceso a la memoria, el aislamiento de los dispositivos y las interfaces de gestión deben evaluarse en el contexto del modelo de amenazas de cada entorno. La mera disponibilidad de una función no demuestra que esté configurada correctamente.

NVIDIA y Eclypsium también señalan que el problema va más allá de un único proveedor. Los sistemas de IA dependen de software privilegiado en el host, firmware de aceleradores, controladores de gestión y mecanismos de transferencia de datos. Las vías concretas varían según la arquitectura, pero la necesidad de tener en cuenta esos componentes no.

Por qué la seguridad de los agentes también depende de la seguridad de la infraestructura

Lo que está en juego aumenta cuando un modelo puede utilizar herramientas, acceder a datos empresariales o iniciar acciones. La manipulación de la infraestructura puede socavar las suposiciones de las protecciones a nivel de aplicación sobre qué modelo se está ejecutando realmente.

La plataforma abierta de seguridad para agentes de NVIDIA ilustra la respuesta por capas. OpenShell proporciona gobernanza durante la ejecución, mientras que NVIDIA Sentry en BlueField funciona desde un dominio de seguridad aislado por hardware, fuera del host y del agente. La arquitectura busca supervisar el comportamiento y aplicar políticas desde un punto de control independiente.

Esa posición independiente genera otra responsabilidad de seguridad: el hardware de aplicación de políticas y su pila de software también deben seguir siendo confiables. Trasladar un control fuera de la aplicación reduce una dependencia, pero aumenta la importancia de verificar el componente al que se confía dicho control.

Del inventario de hardware a la verificación continua

Eclypsium denomina «brecha de aseguramiento de la infraestructura de IA» a la desconexión entre la garantía centrada en los modelos y la integridad de la infraestructura. Su plataforma de aseguramiento de la infraestructura inventaría los componentes, evalúa el firmware y la configuración, compara el estado de los dispositivos con las líneas base aprobadas y supervisa los cambios. La empresa presenta estas capacidades como complementarias a las salvaguardas existentes para las aplicaciones y los modelos.

Para los operadores, el trabajo práctico comienza por tratar las DPU, las GPU, los controladores de gestión y su firmware como activos que se gestionan individualmente. Cada uno requiere asignación de responsables, seguimiento de versiones, evaluación de vulnerabilidades y un proceso de actualización bien definido. La revisión también debe abarcar el acceso al plano de gestión y el software de terceros instalado en los procesadores de infraestructura.

Las comprobaciones también deben acompañar al hardware durante su implementación, las actualizaciones, la recuperación tras incidentes y la reasignación. Una imagen limpia del sistema operativo no demuestra, por sí sola, que todos los componentes de nivel inferior se encuentren en un estado aprobado. La infraestructura compartida hace que este ciclo de vida sea especialmente importante, porque el hardware puede prestar servicio a distintos clientes sucesivamente.

Comprobar el sistema en ejecución, no solo el artefacto

Las firmas de los modelos siguen siendo útiles: responden a una pregunta importante sobre el artefacto que se está cargando. El arranque seguro, la atestación, el aislamiento en tiempo de ejecución y la supervisión continua responden a otras preguntas sobre el sistema que lo ejecuta. Ninguno debe considerarse un sustituto de todos los demás.

La importancia de la investigación de Eclypsium radica en que un modelo puede superar una comprobación de integridad mientras otra parte de su cadena de ejecución ha cambiado. Para las organizaciones que implementan IA en flujos de trabajo de gran impacto, la verificación de la infraestructura debe acompañar a la evaluación del modelo durante toda su operación.