Les recherches d’Eclypsium montrent comment un matériel compromis peut modifier des modèles d’IA pendant leur exécution

Eclypsium a montré comment une infrastructure informatique compromise peut modifier le comportement d’un modèle d’IA pendant l’inférence, alors même que ses fichiers d’origine restent intacts. Publiée le 29 octobre dans Une IA fiable nécessite une infrastructure fiable, cette recherche montre pourquoi vérifier la signature ou l’empreinte d’un modèle ne suffit pas à établir l’intégrité du modèle qui s’exécute en mémoire.

Lors d’une démonstration contrôlée menée avec le soutien de NVIDIA, les chercheurs ont utilisé une unité de traitement de données, ou DPU, compromise, ainsi qu’une isolation mémoire permissive, pour modifier les poids du modèle pendant son exécution. Les réponses du modèle ont changé sans que le modèle stocké ni le service d’inférence soient modifiés. Cette découverte montre que le matériel, les micrologiciels et la configuration des appareils font partie du périmètre de sécurité de l’IA.

Une autre façon de modifier un modèle d’IA

Les discussions sur la sécurité de l’IA portent souvent sur les instructions malveillantes, l’empoisonnement des données d’entraînement et l’utilisation non sécurisée d’outils. Cette recherche s’intéresse à une couche plus basse : l’infrastructure qui héberge et transfère les paramètres d’un modèle pendant son exécution.

Les poids sont les paramètres numériques qui déterminent les réponses d’un modèle. Un fichier valide stocké sur disque peut être chargé en mémoire, puis modifié par un composant doté de privilèges suffisants. Une vérification ultérieure du fichier d’origine retrouve toujours les octets attendus, même si une réponse a été générée à partir d’un état modifié en cours d’exécution.

La démonstration d’Eclypsium a visiblement modifié le résultat d’une analyse portant sur une question géopolitique. La préoccupation plus générale est que la manipulation en cours d’exécution pourrait aussi avoir des conséquences sur d’autres usages sensibles, notamment la génération de code et la prise de décisions automatisée. Il convient de distinguer ces éventualités du comportement précis observé en laboratoire.

L’affirmation selon laquelle la modification serait passée inaperçue a également une portée bien définie : les vérifications d’intégrité du modèle stocké utilisées lors de la démonstration n’ont pas révélé les modifications en mémoire. Cela ne permet pas d’établir que celles-ci échapperaient à toute forme de surveillance ou d’examen forensique.

Les conditions de l’attaque sont importantes

Le test a été réalisé dans un environnement NVIDIA Grace Hopper. La voie d’accès direct à la mémoire reposait sur un composant privilégié compromis et sur des paramètres de configuration autorisant l’accès à des données sensibles en mémoire. Les chercheurs désignent le passthrough de l’IOMMU et une isolation PCIe permissive comme des conditions importantes, en précisant explicitement qu’il ne s’agissait pas des paramètres Linux par défaut.

Une IOMMU aide à contrôler les zones mémoire auxquelles un périphérique peut accéder. Avec la configuration d’isolation renforcée testée par les chercheurs, cette même voie d’accès direct n’était pas disponible. Le résultat souligne donc l’importance de vérifier les paramètres réellement appliqués lors du déploiement, plutôt que de supposer qu’une fonctionnalité de sécurité installée fait effectivement respecter une frontière de sécurité.

Une DPU est un processeur d’infrastructure programmable utilisé pour les services réseau, de stockage et de sécurité. Sa capacité à transférer efficacement des données est précieuse, mais les privilèges nécessaires aux fonctions légitimes de l’infrastructure peuvent devenir dangereux si un attaquant prend le contrôle du composant.

La réponse de NVIDIA : vérifier les frontières de confiance

Dans son récit de la collaboration, NVIDIA décrit le démarrage authentifié de BlueField, la racine de confiance matérielle, l’isolation, les protections des mises à jour du micrologiciel et l’attestation. L’entreprise souligne également que les opérateurs de services cloud choisissent différentes configurations de sécurité en fonction de leurs modèles de confiance.

Les entreprises indiquent que les opérateurs doivent disposer d’éléments probants concernant ces choix. Les contrôles d’accès à la mémoire, l’isolation des appareils et les interfaces de gestion doivent être évalués dans le contexte du modèle de menace propre à chaque déploiement. La seule disponibilité d’une fonctionnalité ne prouve pas qu’elle est correctement configurée.

NVIDIA et Eclypsium soulignent également que le problème ne se limite pas à un seul fournisseur. Les systèmes d’IA dépendent des logiciels privilégiés de l’hôte, des micrologiciels des accélérateurs, des contrôleurs de gestion et des mécanismes de transfert de données. Les voies d’accès précises varient selon l’architecture, mais il faut tenir compte de ces composants dans tous les cas.

Pourquoi la sécurité des agents dépend aussi de celle de l’infrastructure

Les enjeux sont plus importants lorsqu’un modèle peut appeler des outils, accéder aux données de l’entreprise ou déclencher des actions. Une compromission de l’infrastructure peut remettre en cause les hypothèses des mécanismes de protection au niveau applicatif quant au modèle réellement exécuté.

L’Open Agent Safety Platform de NVIDIA illustre cette approche à plusieurs niveaux. OpenShell assure la gouvernance en cours d’exécution, tandis que NVIDIA Sentry sur BlueField opère depuis un domaine de sécurité isolé matériellement, à l’extérieur de l’hôte et de l’agent. Cette architecture vise à surveiller les comportements et à appliquer les politiques depuis un point de contrôle distinct.

Cette indépendance crée une autre responsabilité en matière de sécurité : le matériel chargé de l’application des règles et sa pile logicielle doivent eux-mêmes rester fiables. Déplacer un mécanisme de contrôle à l’extérieur de l’application réduit une dépendance, tout en renforçant l’importance de vérifier le composant auquel ce contrôle est confié.

De l’inventaire du matériel à l’assurance continue

Eclypsium désigne par « déficit d’assurance de l’infrastructure d’IA » le décalage entre l’assurance centrée sur les modèles et l’intégrité de l’infrastructure. Sa plateforme d’assurance de l’infrastructure inventorie les composants, évalue les micrologiciels et les configurations, compare l’état des appareils à des références approuvées et surveille les changements. L’entreprise présente ces capacités comme complémentaires des mesures de protection existantes des applications et des modèles.

Pour les opérateurs, la première mesure concrète consiste à gérer les DPU, les GPU, les contrôleurs de gestion et leurs micrologiciels comme des actifs distincts. Chacun doit avoir un responsable, un suivi des versions, une évaluation des vulnérabilités et un processus de mise à jour clairement défini. L’accès au plan de gestion et les logiciels tiers installés sur les processeurs d’infrastructure doivent également être pris en compte dans cette évaluation.

Les contrôles doivent aussi accompagner le matériel tout au long de son déploiement, de ses mises à jour, de la reprise après incident et de sa réaffectation. La présence d’une image propre du système d’exploitation ne suffit pas à établir que chaque composant de niveau inférieur est dans un état approuvé. Les infrastructures partagées rendent ce cycle de vie particulièrement important, car le matériel peut être utilisé successivement par plusieurs clients.

Vérifier le système en fonctionnement, et pas seulement l’artefact

Les signatures des modèles restent utiles : elles répondent à une question importante sur l’artefact chargé. Le démarrage sécurisé, l’attestation, l’isolation à l’exécution et la surveillance continue répondent à d’autres questions sur le système qui l’exécute. Aucun de ces mécanismes ne doit être considéré comme un substitut à tous les autres.

L’importance des travaux de recherche d’Eclypsium tient au fait qu’un modèle peut réussir un contrôle d’intégrité alors qu’une autre partie de sa chaîne d’exécution a changé. Pour les organisations qui déploient l’IA dans des processus aux conséquences importantes, la vérification de l’infrastructure doit accompagner l’évaluation des modèles tout au long de leur utilisation.