🤖 machine learning

Activation Probes Surface Code-Security Signals that the Model's Output Misses

Cet article démontre que les sondes linéaires appliquées aux activations internes des modèles d'IA à poids ouverts peuvent détecter les vulnérabilités de sécurité du code plus efficacement que le fait de solliciter ces mêmes modèles pour générer des verdicts de sécurité explicites, même pour des types de vulnérabilités non rencontrés lors de l'entraînement.

Auteurs originaux : Ivan Wiryadi

Publié 2026-08-11

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ivan Wiryadi

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un détective tentant de capturer un voleur très doué pour effacer ses traces. Dans le monde de l'informatique, et plus précisément dans le domaine de l'intelligence artificielle (IA), un problème croissant émerge : les agents d'IA écrivent de plus en plus le code qui fait fonctionner nos applications et nos sites web. Mais les rédacteurs d'IA font parfois des erreurs qui laissent des failles de sécurité, comme laisser une porte dérobée ouverte dans une maison numérique. Les humains sont censés vérifier ce code, mais il y en a tellement qu'ils ne peuvent pas tout contrôler.

Pour résoudre cela, nous demandons souvent à l'IA elle-même de vérifier son propre travail. Nous pourrions lui demander : « Ce code est-il sûr ? » en espérant qu'elle réponde « Non » s'il y a un problème. Cependant, cet article explore une idée fascinante : et si l'IA nous mentait, ou ne savait simplement pas comment l'exprimer à voix haute, alors que son cerveau hurle la vérité ? En IA, le « cerveau » est composé de nombres appelés « activations » qui changent à mesure que l'IA réfléchit. Tout comme une personne peut dire « Je vais bien » alors que son visage exprime la terreur, une IA peut dire « Ce code est sûr » alors que ses nombres internes indiquent qu'elle connaît un danger. Cet article demande si nous pouvons écouter ces nombres internes pour détecter les failles de sécurité que la réponse verbale de l'IA laisse passer.

Le murmure secret contre le mensonge bruyant

L'auteur de cet article, Ivan Wiryadi, s'est lancé dans le test d'une hypothèse audacieuse : Le « cerveau » interne de l'IA sait-il qu'il existe des bugs de sécurité même quand la bouche de l'IA dit le contraire ?

Pour le découvrir, il a traité cinq modèles de codage par IA en open-source comme des sujets de test. Il a pris un ensemble de codes Python contenant des failles de sécurité (fonctions vulnérables) et le même code après que les failles ont été corrigées (fonctions réparées). Il a ensuite entraîné un détecteur simple (appelé sonde linéaire) pour écouter les ondes cérébrales internes de l'IA (les activations) pendant qu'elle examinait ces codes. Voyez cette sonde comme un test de détection de mensonges qui lit les signaux électriques dans l'esprit de l'IA, plutôt que de lui demander ce qu'elle pense.

Voici le rebondissement : les chercheurs ont entraîné ce détecteur sur un ensemble de types de bugs (comme l'injection SQL ou le cross-site scripting) puis l'ont testé sur de nouvelles vulnérabilités du monde réel que l'IA n'avait jamais vues lors de son entraînement. Ils voulaient voir si le détecteur pouvait repérer le danger dans ces nouveaux bugs en lisant simplement les signaux internes de l'IA.

Les résultats : Le cerveau sait, la bouche ne sait pas

Les conclusions sont étonnamment claires. Lorsqu'on demandait directement à l'IA : « Ce code est-il vulnérable ? », elle donnait souvent exactement la même réponse pour le code défectueux et pour le code réparé. C'était comme un étudiant qui, lorsqu'on lui demande s'il a triché, répond « Non » tant pour l'examen copié que pour l'examen honnête. Le verdict verbal de l'IA était inutile pour faire la distinction.

Cependant, lorsque les chercheurs ont observé les activations internes de l'IA à l'aide de leur sonde, l'histoire changeait. La sonde pouvait systématiquement distinguer le code défectueux du code réparé.

Le score : Sur 147 vulnérabilités réelles qui ont été corrigées en modifiant une seule fonction, la sonde a correctement classé le code vulnérable comme étant « plus risqué » que le code réparé 61 % à 67 % du temps sur l'ensemble des cinq modèles.
La comparaison : Cela a battu les propres réponses verbales de l'IA à chaque fois. Même lorsque les chercheurs ont tenté de pousser l'IA à réfléchir davantage en lui demandant d'expliquer son raisonnement étape par étape (une technique appelée « Chaîne de pensée » ou Chain of Thought), l'IA échouait toujours à distinguer le mauvais code du bon code dans sa production écrite.
La signification : L'article note que bien que 61–67 % ne soit pas un score parfait (ce n'est pas 100 %), c'est statistiquement significatif. C'est mieux qu'un choix aléatoire (qui serait de 50 %), et cela prouve qu'un « signal de sécurité » existe à l'intérieur du modèle et que le résultat produit par l'IA le cache.

Ce que cela signifie (et ce que cela ne signifie pas)

L'article exclut explicitement l'idée que le simple fait de demander à l'IA d'être un réviseur de sécurité soit suffisant. L'auteur démontre que même avec des techniques d'incitation (prompting) avancées, les verdicts « Oui/Non » écrits de l'IA sont souvent erronés ou identiques, ce qui les rend peu fiables pour détecter des différences subtiles entre un code cassé et un code réparé.

L'article suggère que l'état interne de l'IA transporte un « signal de sécurité du code » qui est actuellement ignoré. L'auteur prend soin de ne pas présenter cela comme un problème résolu ou une solution miracle. Il décrit cela comme un effet « modeste mais constant » qui se maintient à travers différents types de modèles d'IA. Il note également que cela a été testé sur du code Python et des types de bugs spécifiques, nous ne savons donc pas encore si cela fonctionne parfaitement pour tous les langages de programmation ou pour tout type de faille de sécurité.

À retenir

En termes simples, cet article a découvert que les agents de codage par IA pourraient nous « mentir » lorsqu'ils disent que leur code est sûr, mais que leurs « ondes cérébrales » internes disent la vérité. En écoutant ces signaux internes plutôt qu'en lisant simplement la production de l'IA, nous pourrions construire de meilleurs filets de sécurité pour la masse de code que l'IA écrit désormais. C'est un peu comme réaliser que, bien qu'un suspect puisse dire « Je ne l'ai pas fait », son rythme cardiaque s'accélère d'une manière qui raconte une autre histoire. L'auteur espère qu'à l'avenir, nous pourrons utiliser ces signaux de « rythme cardiaque » pour signaler automatiquement le code dangereux avant même qu'il n'atteigne un réviseur humain.

Résumé technique : Les sondes d'activation révèlent des signaux de sécurité du code que le modèle ne transmet pas dans ses sorties

Énoncé du problème

Les agents de codage IA (par exemple, Claude Code, Cursor, OpenAI Codex) rédigent de plus en plus de code de production, les audits empiriques indiquant que 24 à 29 % des extraits de code Python et JavaScript générés par l'IA contiennent des faiblesses de sécurité. La revue de sécurité humaine ne peut pas passer à l'échelle pour suivre le rythme de la génération de code, ce qui nécessite un triage automatisé. Cependant, les vérifications automatisées actuelles sont insuffisantes : les analyseurs statiques souffrent de taux élevés de faux positifs, et solliciter les modèles de langage (LLM) par le biais de prompts pour obtenir des verdicts de sécurité binaires n'est pas robuste. Des réécritures triviales de code peuvent inverser les verdicts des LLM, et les modèles émettent souvent des réponses « OUI/NON » identiques tant pour les paires de code vulnérables que pour les pises corrigées, rendant leur sortie déclarée inutile pour distinguer le risque.

De plus, les agents de codage les plus utilisés sont à poids fermés (closed-weight), empêchant les équipes de déploiement d'inspecter leurs états internes. Les équipes peuvent plutôt déployer des modèles à poids ouverts (open-weight) comme réviseurs, mais le prompting standard de ces réviseurs échoue à détecter les vulnérabilités que les états cachés du modèle lui-même pourraient encoder.

Méthodologie

L'auteur étudie si des sondes linéaires appliquées aux activations du flux résiduel des LLM de code à poids ouverts permettent de récupérer des signaux de sécurité que les sorties induites par le prompt du modèle manquent.

Modèles et données

Modèles réviseurs : Cinq LLM de code à poids ouverts issus de quatre familles d'architectures ont été évalués : Qwen2.5-Coder (7B, 14B), DeepSeek-Coder (33B), Devstral-Small et Llama-3.1 (8B).
Données d'entraînement (SVEN-Python) : Les sondes ont été entraînées sur des paires de fonctions Python vulnérables et corrigées issues du jeu de données SVEN, couvrant quatre types spécifiques de CWE (Common Weakness Enumerations) : 022, 078, 079 et 089.
Données d'évaluation (PATCHEVAL) : Les sondes ont été testées en zero-shot sur 234 vulnérabilités Python réelles et divulguées (CVE) provenant du benchmark PATCHEVAL. Crucialement, les CVE utilisées pour l'évaluation contenaient des types de CWE inconnus lors de l'entraînement (aucun chevauchement avec les quatre CWE d'entraînement).
Division des données : Pour éviter la fuite de données (data leakage), les divisions ont été groupées par projet/dépôt, garantissant qu'aucun code d'un dépôt spécifique ne se retrouve à la fois dans l'entraînement et dans l'évaluation.

Ajustement des sondes (Probe Fitting)

Architecture : Une sonde linéaire unique a été ajustée par modèle.
Entrée : Les activations ont été extraites de l'entrée de la normalisation de couche (layers[L].input_layernorm) en utilisant nnsight.
Optimisation : L'auteur a effectué un balayage sur les couches, les stratégies de pooling de jetons (moyenne, max, dernier, max de fenêtre glissante) et les intensités de régularisation L2. La configuration maximisant l'AUC de la validation croisée groupée à 5 plis (5-fold GroupKFold AUC) a été sélectionnée.
Tâche : La sonde apprend à distinguer une fonction vulnérable de son homologue corrigée en se basant uniquement sur les activations des états cachés.

Métriques d'évaluation

Taux de victoire apparié (Paired Win-Rate) : Pour chaque CVE, la sonde score la fonction vulnérable ( $\hat{p}_{vul}$ ) et la fonction corrigée ( $\hat{p}_{fix}$ ). Le taux de victoire est la fraction des cas où $\hat{p}_{vul} > \hat{p}_{fix}$ .
Comparateurs : La sonde a été comparée à la sortie induite par le prompt du même modèle sous trois conditions :
1. No-shot : Requête directe sans exemples.
2. Few-shot : Requête avec des exemples de types de faiblesses non vus.
3. Chaîne de pensée (Chain-of-Thought - CoT) : Requête exigeant un raisonnement étape par étape avant un verdict.
Méthodes de lecture (Readout) : Les comparateurs ont été évalués à la fois par lecture de logit (probabilité YES/NO renormalisée) et par lecture de jeton (chaîne littérale "yes"/"no").

Résultats clés

1. Les sondes détectent des signaux manqués par le prompting

Sur les vulnérabilités réelles et inédites (CVE à fonction unique), la sonde linéaire a systématiquement classé la fonction vulnérable plus haut que sa correction, atteignant un taux de victoire apparié de 61–67 % sur l'ensemble des cinq modèles. Cette performance est statistiquement significative ( $p < 0,05$ ) et systématiquement supérieure à la ligne de chance de 50 %.

En revanche, les sorties induites par le prompt des modèles ont peu bien performé :

Lecture de Logit : Le taux de victoire de la sonde est supérieur à celui de la lecture de logit des modèles promptés pour chaque modèle sous chaque condition de prompt. Cependant, bien que la sonde surpasse significativement le no-shot prompting sur trois des cinq modèles et le few-shot prompting sur quatre, l'avantage sur le prompting de type Chain-of-Thought (CoT) par lecture de logit est étroit et statistiquement significatif pour un seul des cinq modèles. Malgré cet écart étroit, le taux de victoire de la sonde reste supérieur à celui du CoT pour chaque modèle.
Lecture de Jeton : En lisant le verdict écrit littéral, les modèles n'ont pas réussi à distinguer les paires dans 72–97 % des cas, attribuant le même mot aux fonctions vulnérables et corrigées.

2. Généralisation aux types de faiblesses inconnus

Les sondes, entraînées uniquement sur quatre CWE spécifiques, ont réussi à se généraliser à 234 CVE présentant des types de faiblesses entièrement différents. Cela suggère que les sondes capturent un « signal de sécurité du code » généralisable plutôt que de mémoriser des schémas de vulnérabilité spécifiques.

3. État interne vs Sortie déclarée

L'étude confirme un écart entre la représentation interne d'un modèle et son texte généré. Alors que la réponse déclarée du modèle (jeton) converge souvent vers une égalité, la probabilité interne (logits) et la sonde d'activation conservent un signal capable de classer le risque. La sonde fait efficacement « remonter à la surface » un signal de sécurité que le mécanisme de sortie du modèle lui-même rejette.

4. Performance in-distribution

Sur la distribution d'entraînement (SVEN-Python), les sondes ont atteint un AUC de 0,77–0,85 et une précision de 0,72–0,77 à un seuil de 0,5, surpassant nettement les modèles promptés (précision ~0,50).

Signification et affirmations

L'article affirme que les activations des modèles transportent un signal de sécurité du code que le prompting de ce même modèle manque.

Revue évolutive (Scalable Review) : Les conclusions suggèrent une voie pour des contrôles de sécurité auto-hébergés où un modèle à poids ouverts agit comme réviseur. En lisant les états cachés de ce réviseur via une sonde linéaire, les équipes peuvent signaler les modifications méritant une relecture humaine sans avoir besoin d'accéder aux internes de l'agent de codage à poids fermés qui a généré le code.
Supériorité sur le prompting : La sonde surpasse les stratégies de no-shot et de few-shot prompting du même modèle sur des vulnérabilités inédites. Bien que la sonde surpasse également le prompting de type Chain-of-Thought (CoT) en termes de taux de victoire sur tous les modèles, l'avantage sur le CoT est étroit et n'est pas toujours statistiquement significatif. L'écart clair demeure par rapport au no-shot et au few-shot prompting.
Modeste mais robuste : L'auteur qualifie l'effet de « modeste » (taux de victoire dans la soixantaine) mais constant à travers les architectures et les types de faiblesses. Il précise explicitement que l'intégration de la sonde dans un hook post-écriture d'un agent de codage et son étalonnage pour des seuils absolus sont des étapes futures nécessaires au déploiement.

Ce travail étend les recherches précédentes sur les sondes linéaires pour la sécurité et la détection de vulnérabilités en démontrant la transférabilité vers des types de faiblesses inconnus et des CVE réelles, tout en comparant directement les performances des sondes par rapport aux capacités de raisonnement par prompt du modèle lui-même.