FR
De fausses étiquettes peuvent transformer un texte d’outil en consigne utilisateur
Compaction Laundering: Provenance Destruction in Context-Compacting Coding Agents · arXiv:2610.29869
En termes simples
Les agents de programmation raccourcissent parfois les longues conversations en les remplaçant par un résumé dont ils se servent comme mémoire. L’article examine si du texte tiré d’un fichier ou d’une page web peut ainsi ressembler à une consigne donnée par l’utilisateur.
Dans certains systèmes testés, les rôles des messages deviennent des étiquettes écrites, comme [User]:, qu’un texte non fiable peut imiter. Les résumés de cinq systèmes de ce type ont souvent traité une fausse approbation comme une consigne de l’utilisateur ; quatre systèmes qui conservaient les rôles dans des champs distincts ne l’ont pas fait.
Un petit test avec un agent réel a aussi montré que cette fausse approbation pouvait mener à l’exécution d’une commande.
La recherche
Quand un agent de programmation raccourcit une conversation, il peut écarter les messages d’origine et utiliser un résumé comme mémoire. Du texte qu’il a lu dans un fichier ou une page web peut-il alors être repris dans ce résumé comme s’il s’agissait d’une consigne de l’utilisateur ?
L’article compare comment neuf systèmes de test pour agents de programmation résument de fausses étiquettes utilisateur, puis évalue si une vérification du code peut détecter les fausses attributions.
Les auteurs ont testé la même fausse approbation avec le véritable sérialiseur et la consigne de résumé de chaque système.
Un modèle évaluateur a déterminé si les résumés la présentaient comme une consigne durable de l’utilisateur, puis une évaluation distincte a vérifié un échantillon des classements. Dans chacun des cinq systèmes qui convertissent les rôles en texte, le taux de blanchiment allait de 87 à 100 % ; il était de 0 % dans les quatre systèmes à rôles typés.
Ce contraste appuie l’explication selon laquelle, dans les systèmes testés, la conversion en texte rend l’étiquette falsifiable, tandis que les messages typés préservent le rôle de la personne ou du système qui parle. Un test distinct en conditions réelles a montré que cette fausse mémoire pouvait mener à l’exécution d’une commande, mais seulement dans certains essais empoisonnés.
La démonstration en conditions réelles portait sur un seul système de test, un seul modèle et un petit nombre d’essais ; les proportions ne constituent donc pas des estimations précises. La plupart des tests d’exécution utilisaient une boucle d’agent générique, sans demande d’approbation ni bac à sable au niveau du système d’exploitation.
Ils montrent ce que le modèle a fait dans cette configuration, pas ce que tout agent protégé exécuterait.
Ce que montrent les preuves
- Quand la mémoire perd sa source
L’article mesure le blanchiment de provenance dans des systèmes de test pour agents de programmation : il cherche à savoir si un résumé transforme du texte non fiable en quelque chose qui semble être une consigne de l’utilisateur.
Cela peut compter lorsqu’un agent condense une longue conversation et s’appuie sur le résumé comme mémoire. La question est de savoir si, pendant le résumé, perdre la trace de qui a dit quoi permet à un texte tiré d’un fichier ou d’une page web d’acquérir l’autorité d’un message de l’utilisateur.
- Deux façons de transmettre les messages
Certains systèmes convertissent les messages en texte brut et indiquent qui parle avec des étiquettes comme [User]:. Si un contenu non fiable inclut une fausse étiquette et que le système ne la neutralise pas, le modèle qui résume peut prendre le texte qui suit pour une véritable consigne de l’utilisateur.
D’autres systèmes conservent le rôle dans un champ distinct, qu’un texte issu d’un fichier ou d’un outil ne peut pas falsifier. L’article teste cette différence en utilisant le véritable sérialiseur et la consigne de résumé de chaque système.
- Un net écart entre les résumés
Les chercheurs ont testé la même fausse approbation dans cinq systèmes qui convertissent les rôles en texte et quatre qui les conservent dans des champs distincts.
Un modèle évaluateur a déterminé si chaque résumé présentait l’approbation comme une consigne durable de l’utilisateur ; une évaluation distincte a vérifié un échantillon stratifié. Dans les systèmes qui convertissent les rôles en texte, 87–100 % des résumés ont été classés comme ayant blanchi l’approbation, contre 0 % dans les systèmes à rôles typés.
- Quand la fausse mémoire mène à l’action
Une fausse approbation peut aussi influer sur le plan d’un agent ou amener un agent chargé de la revue à ignorer un fichier contenant une porte dérobée. L’article teste séparément si elle peut mener à l’exécution d’une commande.
Lors d’un petit test de bout en bout avec la véritable interface du terminal pi, la chaîne complète — refus avant la condensation, puis exécution après celle-ci — s’est produite dans trois des six essais empoisonnés et dans aucun des cinq essais propres rapportés. Cela montre que, dans cette configuration, l’effet peut aller jusqu’à l’exécution ; le petit échantillon ne permet pas d’établir un taux précis pour d’autres agents.
- Une vérification détecte certaines fausses attributions
L’article teste aussi une vérification du code qui compare les affirmations du résumé attribuées à l’utilisateur aux véritables messages de l’utilisateur conservés par le système. À l’un des seuils rapportés, elle a détecté 77 % des cas de blanchiment et rétrogradé à tort 2 % des affirmations légitimes dans des résumés propres.
Certaines fausses attributions ont tout de même échappé à la vérification ; le résultat appuie donc l’idée d’une atténuation partielle, et non d’une solution complète.
Détails
- Auteurs de l’article original
- Arshan Dabirsiaghi
- Soumis à arXiv
- Licence
- CC BY 4.0