💻 computer science

The Security Budget of Code LLMs: An Information-Theoretic Capacity-Security Bound

Cet article établit et valide empiriquement une borne informationnelle démontrant que les LLM de code opèrent sous un « budget de sécurité » fixe où la somme de la capacité fonctionnelle et de la rétention de perturbation est limitée par l'entropie de la tâche et la fuite d'incitation, les résultats expérimentaux montrant que ce plafond théorique se maintient à travers divers modèles, ensembles de données et niveaux de précision.

Auteurs originaux : Jianwei Tai

Publié 2026-06-03

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jianwei Tai

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 embauchez un programmeur de robots très talentueux, mais légèrement nerveux. Vous lui donnez un ensemble d'instructions (un « prompt ») pour écrire un morceau de code. Parfois, vous pourriez accidentellement changer un mot dans vos instructions, ou un pirate pourrait tenter d'en modifier légèrement les termes pour inciter le robot à écrire quelque chose de dangereux.

Ce document pose une question fondamentale : Quelle part du « cerveau » du robot peut être consacrée à l'exécution correcte du travail par rapport à ce qui reste pour qu'il suive accidentellement (ou malicieusement) une ruse ?

Les auteurs appellent cela le « Budget de Sécurité ». Ils traitent la capacité du robot à réfléchir comme une quantité fixe d'énergie ou de bande passante qui doit être partagée entre deux tâches concurrentes.

Les deux besoins concurrents

Considérez l'attention du robot comme une tarte. Le papier explique que cette tarte est divisée en deux parts :

La part du « Travail » (Capacité) : C'est la mesure de la capacité du robot à comprendre votre intention originale. A-t-il écrit le code que vous avez réellement demandé ?
La part de l'« Écho » (Sécurité/Rétention) : C'est la mesure de la capacité de la sortie du robot à encore « se souvenir » des mots spécifiques que vous avez utilisés, même si vous les avez légèrement modifiés.
- Le piège : Si la sortie du robot est trop sensible aux changements infimes de votre prompt (un « Écho » élevé), cela signifie qu'un pirate pourrait facilement remplacer un mot comme « vérifier » par « ignorer » et le robot suivrait la nouvelle instruction dangereuse.
- L'objectif : Vous voulez que le robot soit bon pour le travail, mais vous ne voulez pas qu'il soit trop sensible à la formulation spécifique du prompt.

La règle d'or (Le Théorème)

Les auteurs ont prouvé une règle mathématique qui agit comme une limite de vitesse pour cette tarte. Ils disent :

Part du Travail + Part de l'Écho ≤ Espace Cérébral Total + Fuite de Prompt

En langage clair : Le robot ne peut pas être parfaitement bon pour le travail et parfaitement sensible à chaque minuscule changement de votre prompt en même temps. Il existe une limite stricte.

Espace Cérébral Total : C'est la complexité de la tâche. Si vous demandez un simple « Hello World », le robot dispose de beaucoup de place. Si vous demandez un système bancaire complexe, l'« Espace Cérébral » est énorme, laissant moins de place pour les marges de sécurité.
Fuite de Prompt (Prompt Leakage) : C'est la quantité d'informations partagées entre votre prompt original et le prompt « piégé ». Si la ruse consiste simplement à changer « chat » en « chien » (des synonymes), la fuite est élevée. Si la réeuse consiste à supprimer la moitié de la phrase, la fuite est faible.

Le papier prouve que si vous essayez de rendre le robot trop sensible au prompt (pour le rendre très robuste), vous réduisez inévitablement l'espace disponible pour qu'il accomplisse réellement le travail correctement.

Comment ils l'ont testé

Les chercheurs n'ont pas seulement deviné ; ils ont mené des expériences avec de vrais modèles d'IA (comme CodeLlama et Qwen) sur de vrais problèmes de programmation.

Le test de la « Boîte Noire » : Ils ont observé la sortie finale du robot (le code) sans regarder ses pensées internes pendant le processus. Ils ont traité le code comme une empreinte digitale.
Les résultats : Dans chaque test, les mathématiques ont tenu bon. La somme de la performance du « Travail » et de la sensibilité de l'« Écho » n'a jamais dépassé la limite de vitesse.
- Parfois, le robot était très bon pour le travail mais peu sensible aux ruses (laissant beaucoup de « marge » ou de budget inutilisé).
- Parfois, il était très sensible aux ruses, mais cela signifiait qu'il avait moins de place pour être parfait dans son travail.
- Crucialement : Ils ont découvert que certains types de ruses (comme renommer des variables ou échanger des synonymes) laissent un « écho » plus important que d'autres. Cela nous indique quels types de changements de prompt sont les plus dangereux s'ils ne sont pas surveillés.

Le « Test de Stress »

Pour s'assurer que leur règle était solide, ils ont essayé de la briser :

Le pool d'attaques « 23-Attack » : Ils ont essayé 23 façons différentes de manipuler le prompt. La règle a toujours tenu.
Le « Suffixe Universel » : Ils ont ajouté la même phrase dangereuse à chaque prompt. La règle a toujours tenu.
L'attaque par « Gradient » : Ils ont utilisé une attaque mathématique ultra-intelligente pour trouver la façon parfaite de piéger le robot. Même dans ce cas, la règle a tenu, bien que la qualité du code du robot ait chuté de manière significative (il s'est « effondré » plutôt que d'être simplement trompé).

La leçon pour les humains

Le papier conclut par une leçon pratique pour la construction d'assistants IA :

Vous ne pouvez pas vous contenter de mesurer si une IA réussit un test. Vous devez également mesurer quelle « voie d'information » vous laissez ouverte à un attaquant.

Si vous durcissez vos prompts (en les rendant rigides et standardisés), vous réduisez la tranche de l'« Écho », ce qui rend plus difficile pour les pirates de piéger l'IA.
Cependant, vous ne pouvez pas simplement rendre l'IA « stupide » pour qu'elle soit en sécurité. Vous devez trouver l'équilibre où l'IA est assez intelligente pour faire le travail, mais pas trop sensible aux jeux de mots pour qu'elle devienne un risque de sécurité.

En bref : Il existe une limite mathématique stricte à la capacité d'une IA à être à la fois un travailleur parfait et un auditeur parfait de chaque subtilité de votre voix. Le papier nous donne la règle pour mesurer cette limite.

Résumé technique : Le budget de sécurité des LLM de code

Énoncé du problème
Les assistants de programmation par IA reposent de plus en plus sur les prompts en langage naturel comme interface principale du développement logiciel. Ce changement introduit une vulnérabilité critique : de petites perturbations d'un prompt (par exemple, la substitution de synonymes, le renommage d'identifiants ou l'injection de commentaires) peuvent modifier le code généré tout en laissant l'intention de l'utilisateur partiellement reconnaissable. Les évaluations existantes s'appuient souvent sur les taux de réussite d'exécution (pass@1) avant et après perturbation. Cependant, les auteurs soutiennent que cela est insuffisant pour les assistants interactifs car cela ne permet pas de distinguer un modèle qui a perdu toute information sur la tâche (rendant la « robustesse » dénuée de sens) d'un modèle qui conserve suffisamment d'informations pour être reconnaissable mais dont l'implémentation change. Il existe un besoin pour une vision de type « niveau de budget » qui sépare l'information de la tâche, la fuite du prompt et la stabilité de la génération afin de comprendre les compromis entre la capacité fonctionnelle et la sécurité sous perturbation.

Méthodologie
Le papier formalise ce compromis en utilisant la théorie de l'information, en définissant deux quantités clés pour un LLM de code $\pi$ :

Capacité ($Cap$) : L'information mutuelle entre la solution canonique $c^*$ et la génération du modèle $c_\pi$ , notée $I(c^*; c_\pi)$ . Cela mesure la part de la tâche que le modèle capture.
Sécurité ($Sec$) : L'information mutuelle entre la génération sous le prompt original $p$ ( $c_\pi$ ) et la génération sous un prompt perturbé de manière adverse $\tilde{p}$ ( $\tilde{c}_\pi$ ), notée $I(c_\pi; \tilde{c}_\pi)$ . Elle agit comme un « canal de rétention de perturbation », mesurant l'information partagée entre les sorties saines et perturbées.

Cadre théorique
La contribution théorique centrale est le Théorème 1, qui établit une borne supérieure sur la somme de ces deux quantités :
$Cap + Sec \leq H(c^*) + I(p; \tilde{p})$
Ici, $H(c^*)$ est l'entropie de la solution canonique (entropie de la tâche) et $I(p; \tilde{p})$ est l'information mutuelle entre le prompt original et le prompt perturbé (fuite du prompt). La preuve repose sur des inégalités classiques de la théorie de l'information :

$Cap \leq H(c^*)$ découle de la définition de l'information mutuelle.
$Sec \leq I(p; \tilde{p})$ découle de l'inégalité de traitement des données (DPI), en supposant que les générations $c_\pi$ et $\tilde{c}_\pi$ sont conditionnellement indépendantes étant donné la paire de prompts $(p, \tilde{p})$ .

Pour rendre cette borne exploitable sans accès aux données d'entraînement internes du modèle, les auteurs dérivent le Théorème 2, une borne compagne à forme fermée et indépendante du modèle pour $H(c^*)$ . Cette borne utilise la compressibilité du code source :
$H(c^*) \leq \min(L_{max} \log V, |c^*|_{gz})$
où $L_{max}$ est la longueur maximale en tokens, $V$ est la taille du vocabulaire, et $|c^*|_{gz}$ est la longueur attendue de la solution canonique compressée via gzip.

Validation empirique
Les auteurs valident le Corollaire 1 (Borne de variable embarquée) en utilisant un protocole d'embedding uniquement sur la sortie. Pour préserver la chaîne de Markov requise par la preuve ( $z_\pi \to p \to \tilde{p} \to \tilde{z}_\pi$ ), l'embedding $E$ est appliqué uniquement au code généré, excluant le contexte du prompt.

Modèles et jeux de données : Les expériences ont été menées sur CodeLlama-7B et Qwen2.5-Coder-7B sur les jeux de données HumanEval et MBPP-sanitizées.
Estimateurs : L'information mutuelle a été estimée à l'aide des estimateurs MINE (Mutual Information Neural Estimation) et KSG (Kraskov-Stögbauer-Grassberger) sur les états cachés du dernier token (réduits par PCA).
Perturbations : Un ensemble de 23 perturbations a été utilisé, incluant des échanges de synonymes, des négations, l'injection de commentaires (y compris des commentaires anti-sécurité) et le renommage d'identifiants.

Résultats clés

Satisfaction de la borne : À travers six configurations de validation individuelles (variant les modèles, les jeux de données, la précision et les ablations d'embedding), la vérification par embedding a satisfait l'inégalité. Le ratio de saturation $(Cap + \max_T Sec) / (H(z^*) + \max_T I(p; \tilde{p}))$ se situait entre 0,27 et 0,92, avec un surplus théorique (slack) positif de 2,36 à 26,94 nats.
Stabilité : Un diagnostic de stabilité sur trois graines (seeds) a montré une saturation moyenne de 0,87.
Tests de stress : Des tests de stress adaptatifs, incluant un pool de 23 perturbations, un suffixe anti-sécurité universel fixe et une attaque PGD basée sur le gradient, ont tous abouti à un surplus positif, confirmant que la borne tient même sous des stratégies de perturbation agressives.
Signal par problème : Bien que la borne théorique utilise des embeddings uniquement sur la sortie, un cosine d'embedding mixte-contexte (conditionné par le prompt et le code) a été trouvé corrélé avec le pass@1 au niveau de l'exécution (ex: $\rho=0,36$ pour CodeLlama-HumanEval), servant de signal d'alignement pratique distinct de la borne de sécurité.
Analyse de la fuite : L'étude a identifié que le renommage d'identifiants et la substitution de synonymes laissent les plafonds d'information partagée les plus élevés (haut $I(p; \tilde{p})$ ), tandis que les commentaires anti-sécurité fuient moins d'informations de prompt mais sont plus dangereux pour la sécurité.

Signification et revendications
Le papier affirme fournir un budget quantitatif et informationnel de la stabilité de la génération de code. Sa signification réside dans :

Décomposition : Séparer le « budget » entre l'entropie de la tâche et la fuite du prompt, permettant aux développeurs de comprendre que la réduction de la fuite du prompt ( $I(p; \tilde{p})$ ) resserre le canal maximal disponible pour un adversaire sans nécessairement augmenter la capacité fonctionnelle.
Plafond indépendant du modèle : La borne à forme fermée sur $H(c^*)$ permet de calculer un plafond de sécurité pour tout nouveau modèle sur un ensemble de tâches connu sans nécessiter l'accès au modèle ou aux données d'entraînement, en se basant uniquement sur le tokenizer et la distribution des solutions canoniques.
Garde-fous pratiques : Les auteurs soutiennent que les garde-fous des assistants de programmation devraient être évalués non seulement par le pass@1, mais par l'information de perturbation de prompt qu'ils laissent disponible à un adversaire. La borne offre un test pour le durcissement des prompts : réduire $I(p; \tilde{p})$ devrait resserrer le budget de sécurité.

Les auteurs restent modestes, notant que la contribution est l'instanciation de ces concepts pour la génération de code (définir le budget et le plafond à forme fermée) plutôt qu'un nouveau théorème de traitement de données. Ils reconnaissent des limites, notamment la sensibilité des estimateurs de MI (où MINE peut surestimer près des frontières) et le fait que la borne caractérise le budget de stabilité disponible plutôt que de prouver qu'un adversaire réaliste saturera toujours ce budget.