IA ⚠️: capacités cachées, limites des audits de sécurité
Découvrez comment l’IA révèle des capacités cachées via un déclencheur secret. Apprenez les limites de l’audit de sécurité et repérez les backdoors.
Quand un modèle d'IA peut cacher des capacités dans ses poids
Les évaluations de sécurité des modèles d'intelligence artificielle reposent souvent sur une idée simple : si un modèle contient une capacité dangereuse, des tests bien conçus devraient finir par la faire sortir. Sauf que cette hypothèse a un angle mort. Et si la capacité est là... mais volontairement enfouie, pour ne se manifester qu'avec un déclencheur précis ?
Une étude publiée sur arXiv le 9 octobre 2026 explore exactement ce scénario. Les auteurs y décrivent une méthode qui intègre un réseau de neurones chiffré dans les poids d'un modèle hôte. Ce réseau ne serait déchiffré et exécuté qu'après réception d'un déclencheur particulier. Selon eux, dans certaines hypothèses cryptographiques, l'ensemble peut rester difficile à extraire ou à interpréter, même pour un auditeur qui dispose des poids.
Cette étude ne veut pas dire que « tous les modèles » cachent des capacités, ni que n'importe quel système déployé peut faire n'importe quelle tâche secrète. Elle pointe plutôt une limite assez concrète des audits basés uniquement sur l'élicitation : tester un modèle ne garantit pas qu'on a fait apparaître tout ce qu'il pourrait faire.
Le problème : un audit ne teste que ce qu'il parvient à faire apparaître
Les évaluations de capacités sont devenues une étape courante avant de mettre des modèles d'IA à disposition. Les équipes vérifient, par exemple, si un modèle peut suivre des instructions dangereuses, produire des contenus interdits ou contribuer à des usages à risque. Elles évaluent aussi ses réponses à des scénarios « durs », mettent parfois des outils sous le modèle, ou changent les consignes pour tenter de faire remonter des comportements qui ne surgissent pas dans un échange ordinaire.
Tout ça est utile. Ça permet de repérer des risques concrets et de comparer des versions dans des conditions contrôlées. Mais il y a une prémisse, souvent implicite : la capacité qu'on cherche doit pouvoir être déclenchée par ce qu'on fait dans l'audit. Si l'évaluateur ignore le bon déclencheur, ou si le comportement ne se manifeste que dans une configuration très spécifique, le test peut conclure à tort que la capacité n'existe pas.
La différence entre absence de preuve et preuve d'absence
Dans la pratique, un audit ne donne pas un verdict absolu sur le système. Il observe ce que le modèle produit dans un ensemble de situations, avec un budget de temps et de calcul limité. Un résultat négatif veut donc généralement dire : « on n'a pas vu ce comportement dans les conditions testées ». Pas forcément : « le modèle ne sait pas le faire dans toutes les conditions possibles ».
En cybersécurité, c'est une logique familière. Le fait de ne voir aucun problème pendant un test d'intrusion ne prouve pas que le logiciel est invincible. Ça donne plutôt une assurance bornée par le périmètre, les outils et les compétences mobilisées. L'étude applique la même idée aux capacités des modèles : ne pas réussir une tentative d'élicitation ne suffit pas à conclure que la capacité n'existe pas.
Pourquoi l'élicitation peut échouer
Les approches classiques tentent de faire émerger un comportement en modifiant les entrées ou en jouant sur l'entraînement. L'étude mentionne notamment des essais de réglage fin, l'ajout de bruit dans les poids, la recherche de déclencheurs via le gradient, et l'entraînement adversarial dans l'espace latent. Ces pistes ne sont pas identiques, mais elles partagent une condition : elles doivent trouver un chemin jusqu'au mécanisme caché.
Un modèle peut au contraire être conçu pour que le mécanisme reste inaccessible sans une condition précise. Si le déclencheur est inconnu et que la partie cachée est chiffrée, multiplier les requêtes ne garantit pas qu'on y arrivera. L'enjeu ne se limite donc pas à « écrire de meilleurs prompts ». Il faut aussi se demander ce qu'on peut réellement conclure lorsque l'intérieur du modèle a été construit pour résister à l'inspection.
Ce que les expériences démontrent - et leurs limites
Les auteurs ont construit des preuves de concept avec PyTorch, puis les ont évaluées sur une tâche de prédiction de petites réactions chimiques. Ils utilisent cette tâche comme « proxy » de capacités potentiellement pertinentes pour les risques CBRN (chimiques, biologiques, radiologiques ou nucléaires). Le mot « proxy » compte : on n'est pas face à une démonstration que le modèle pourrait concevoir ou fabriquer une arme.
Les méthodes d'élicitation mises à l'épreuve
L'étude rapporte une résistance à quatre familles de méthodes :
- Réglage fin : reprendre l'entraînement pour faire émerger (ou modifier) le comportement visé.
- Ajout de bruit aux poids : perturber les paramètres pour voir si la structure cachée se révèle, se dégrade ou devient plus détectable.
- Recherche de déclencheur par gradient : utiliser des signaux de gradient pour tenter de retrouver l'entrée qui active le comportement.
- Entraînement adversarial latent : travailler sur des représentations internes pour pousser le modèle vers des comportements difficiles à faire apparaître avec des entrées « normales ».
Ça ne veut pas dire que ces méthodes sont inutiles partout. Elles peuvent rester pertinentes contre de nombreuses portes dérobées et pour évaluer des systèmes réels. Mais l'étude suggère qu'une construction pensée pour résister à une classe d'attaques peut réduire l'efficacité d'autres approches. En sécurité, une méthode qui marche contre un type de menace n'offre pas une garantie automatique contre un autre type.
Ce que le résultat ne permet pas de conclure
Ce serait excessif de résumer l'article par « n'importe quelle capacité peut être cachée dans n'importe quel modèle ». Le titre et le résumé parlent d'une capacité de construction sous des hypothèses cryptographiques, avec une preuve de concept expérimentale sur une tâche limitée. Ils ne montrent pas, en particulier, que cette approche est déjà intégrée dans des modèles commerciaux, qu'elle se généralise à grande échelle sans coût, ou qu'elle serait indétectable quelle que soit la méthode d'analyse.
Les détails pratiques comptent aussi. Selon la manière d'implémenter, il peut y avoir des artefacts, des coûts de calcul, une dépendance forte au déclencheur, ou un comportement différent dans un modèle beaucoup plus grand. Même si le signal de recherche est intéressant, l'article, tel que présenté, ne suffit pas à quantifier la faisabilité dans un contexte de production.
Autre limite : la cryptographie donne des garanties conditionnelles. Une preuve peut établir qu'un adversaire ne parvient pas à récupérer une information dans un cadre donné, si des hypothèses tiennent et si les conditions du système sont respectées. Ce n'est pas la même chose qu'une assurance générale contre toute fuite, toute erreur d'implémentation ou toute attaque latérale.
Pourquoi la publication des modèles compte
Les auteurs indiquent publier leurs modèles pour aider à améliorer les défenses. Concrètement, des preuves de concept peuvent permettre aux équipes sécurité de tester leurs outils et de concevoir des contre-mesures. Mais il y a un revers : publier une technique peut aussi aider des acteurs malveillants à l'étudier et, potentiellement, à l'adapter.
C'est un arbitrage classique. Retenir des détails peut ralentir l'amélioration des défenses ; publier sans précaution peut faciliter la réutilisation. La meilleure décision dépend du niveau de maturité de la méthode, de la sensibilité des artefacts, et de la capacité de la communauté à analyser rapidement les risques. Pour les organisations, la réponse n'est pas de considérer toute publication comme dangereuse, ni de supposer que l'ouverture suffit à sécuriser un système.
Conséquences pour les audits et la gouvernance de l'IA
Le message opérationnel est simple : il ne faut pas réduire l'audit sécurité à une série de tests de comportement. Ces tests répondent à une question utile (« que fait le modèle dans ces conditions ? »), mais ils n'adressent pas tout le reste : « comment a-t-il été construit ? », « qu'est-ce qui a été modifié ? », « quels mécanismes existent dans les poids ? », et surtout « qu'est-ce qu'on ne sait pas encore ? ».
Une approche d'audit en plusieurs couches
Pour une entreprise française ou européenne qui intègre un modèle dans un produit, mieux vaut combiner plusieurs niveaux de contrôle. Aucun ne remplace les autres.
- Évaluer les sorties : tester des scénarios réalistes, y compris des variantes et des tentatives de contournement. Documenter le périmètre, les versions du modèle et la couverture des tests.
- Vérifier la provenance : conserver des informations sur la source du modèle, les étapes de réglage fin, les jeux de données et les dépendances logicielles. La traçabilité ne révèle pas forcément toutes les capacités, mais elle aide à expliquer des changements.
- Contrôler les artefacts : comparer les versions, rechercher des anomalies et appliquer des analyses adaptées aux poids et au code. Une analyse statique ne garantit pas la détection d'un mécanisme chiffré, mais elle peut signaler d'autres problèmes.
- Tester les interactions : regarder ce qui se passe avec les outils connectés, les permissions, les appels de fonctions et les chemins d'exécution. Une capacité risquée ne devient vraiment dangereuse que si elle peut être exploitée dans le système déployé.
- Définir des mesures de confinement : limiter les privilèges, isoler les environnements sensibles, journaliser les actions et prévoir un arrêt rapide. La défense ne peut pas dépendre uniquement du fait que l'on comprendra tous les poids.
Au fond, cette approche ressemble plus à une logique d'assurance système qu'à un examen « ponctuel » du modèle. Elle relie le comportement attendu au contexte de déploiement, aux données reçues et aux actions que le modèle est autorisé à déclencher.
Adapter les conclusions au contexte réglementaire
En Europe, le RGPD impose de gérer sérieusement la gouvernance des données personnelles et les responsabilités liées aux systèmes qui les utilisent. Mais il ne propose pas, en soi, une méthode technique pour détecter des circuits cachés. De la même façon, les obligations autour de l'IA dépendent de l'usage, du niveau de risque et du cadre réglementaire applicable.
Dans ce contexte, une bonne pratique consiste à garder des preuves d'évaluation vérifiables : version du modèle, scénarios testés, outils utilisés, résultats, mesures de réduction du risque et risques résiduels. Dire « le modèle a été testé » ne veut rien dire si on ne peut pas répondre à des questions précises : testé par qui, sur quelle version, dans quelles conditions, avec quel accès, et contre quels types de tentatives d'exploitation.
Un cadre de décision pour les équipes produit
L'article ne dit pas qu'il faut arrêter les évaluations de capacités. Il rappelle simplement qu'il ne faut pas leur donner une portée qu'elles n'ont pas. En pratique, avant une mise en production, une équipe peut s'appuyer sur ce type de grille :
- Quel préjudice est possible ? Un assistant interne n'a pas le même profil de risque qu'un système connecté à des outils sensibles.
- Quelles capacités ont été testées ? Séparer ce qui a été observé de ce qui est supposé absent.
- Quel accès l'auditeur a-t-il ? Une API, des poids ouverts, ou un environnement de développement complet ne donnent pas les mêmes possibilités.
- Qu'est-ce qui reste hors périmètre ? Déclencheurs secrets, dépendances externes, modifications postérieures : il faut les traiter explicitement.
- Que fait-on si un test échoue ? Réduction des permissions, supervision, isolation et procédures de réponse limitent l'impact même si l'analyse interne reste incomplète.
La sécurité, en général, vient de l'addition. Chercher une interprétabilité parfaite est séduisant, mais souvent irréaliste. Un système défendable, c'est plutôt un système dont les risques sont documentés, les accès cadrés, et le confinement éprouvé.
Conclusion : élargir l'audit au-delà des tests de comportement
Cette recherche met en évidence une limite assez structurelle : un audit basé sur l'élicitation ne peut observer que les comportements qu'il arrive à déclencher. Les auteurs vont plus loin en décrivant comment intégrer des calculs neuronaux chiffrés dans les poids, puis les activer avec un déclencheur secret. Les expériences restent une preuve de concept, mais le problème de fond mérite attention.
Pour les équipes produit et sécurité, la réponse n'est pas d'abandonner les tests. C'est de les replacer dans une stratégie plus large : provenance documentée, contrôle des artefacts, évaluation des interactions, limitation des permissions et mécanismes de confinement. Une évaluation négative doit être lue comme une information sur les conditions testées, pas comme une garantie universelle.
Vous déployez un modèle d'IA dans un produit ? Commencez par une fiche d'audit qui précise la version, le périmètre testé, les accès accordés et les risques résiduels. C'est plus utile - et plus défendable - qu'une simple phrase du type « le modèle a été testé ».
Comment une capacité peut être dissimulée dans les poids
La construction décrite dans l'article s'appuie sur deux ingrédients : un calcul caché sous la forme d'un réseau neuronal chiffré, et une activation conditionnée par un déclencheur secret. Les auteurs expliquent comment intégrer ce réseau dans les poids d'un modèle hôte. Une fois le bon déclencheur fourni, le système déchiffre puis exécute le circuit intégré.
Quand les auteurs parlent de « poids », ils désignent les paramètres numériques appris (ou ajustés) pendant la construction du modèle. Dans les modèles à poids ouverts, ces paramètres sont souvent accessibles. Mais « accessibles » ne veut pas dire « faciles à comprendre ». Même avec un fichier de poids sous la main, interpréter des milliards de paramètres et leurs interactions reste difficile.
Le rôle du coffre numérique
Pour protéger l'information ou le calcul, les auteurs utilisent l'idée de « coffres numériques », c'est-à-dire des constructions cryptographiques pensées pour rendre le contenu difficile à récupérer ou à comprendre sans la condition appropriée.
Dans le scénario décrit, ce qui est caché n'est pas seulement une phrase secrète « planquée » dans les poids. C'est un circuit neuronal, capable d'effectuer un calcul. C'est plus large que ce que les auteurs évoquent comme travaux antérieurs, qui portaient sur la dissimulation de chaînes de caractères fixes. Dissimuler une chaîne n'est pas la même chose que dissimuler une computation arbitraire : dans ce second cas, le mécanisme peut produire des sorties calculées à partir d'entrées.
Dit simplement : la promesse théorique dépend d'hypothèses de cryptographie. Elle ne signifie pas que l'inspection est inutile, ni que tout serait inviolable face à toutes les attaques. Les garanties dépendent du modèle de menace, des hypothèses choisies et de l'implémentation.
Pourquoi l'accès aux poids ne règle pas tout
On pourrait croire qu'un audit avec accès complet au modèle suffit à lever tous les doutes. L'étude s'attaque à cette idée : selon les auteurs, leur construction cherche à rendre les circuits cachés difficiles à éliciter et à interpréter, même quand les poids sont disponibles.
C'est important quand on parle de politiques d'accès. Les poids ouverts rendent l'inspection possible, et c'est un vrai avantage pour l'audit. Mais l'ouverture ne remplace pas la discussion sur ce que la cryptographie garantit (ou ne garantit pas) ni la question de l'interprétabilité. Et il ne faut pas confondre « avoir les poids » et « avoir toute la chaîne de fabrication ». Les données utilisées, le code d'entraînement, les étapes intermédiaires, les outils, et d'éventuels secrets peuvent changer ce qu'un auditeur peut réellement vérifier.
Un audit solide doit donc préciser ce qui est accessible, ce qui ne l'est pas, et quelles conclusions restent raisonnables.