La sécurité des agents est souvent réduite à l’injection d’instructions, aux autorisations des outils, au cloisonnement ou aux confirmations de l’utilisateur. Une nouvelle prépublication de chercheurs de l’Université de l’Illinois à Urbana-Champaign met en évidence une autre couche : le mécanisme qui assemble le contexte et décide quels fichiers, mémoires, descriptions d’outils, règles de dépôt et valeurs d’exécution entrent dans l’invite de l’agent, avec quel niveau d’autorité.
Les auteurs nomment cette classe de défaillance « élévation de privilège du contexte ». Sur 12 environnements d’agents, dont Codex, Claude Code, Gemini CLI, Qwen Code, Kimi CLI, Aider, OpenCode, Cline, Goose, Pi-mono, OpenClaw et Hermes Agent, ils déclarent avoir validé à l’exécution 282 sources de contexte susceptibles de participer à des chemins d’élévation. Leurs démonstrations couvrent la manipulation du raisonnement et des appels d’outils, la persistance entre sessions, le déni de service et, dans certaines chaînes, l’exécution de code à distance. Il s’agit de résultats rapportés par les auteurs dans une prépublication arXiv du 1er septembre, et non d’une preuve que toutes les versions actuelles restent vulnérables.
L’assemblage du contexte possède son propre modèle de privilèges
Un environnement d’agent fusionne des informations provenant de nombreux endroits. Un dépôt peut fournir un fichier AGENTS.md ou des règles propres à un produit. Les compétences et serveurs MCP ajoutent des descriptions et des résultats. Les fichiers de configuration, variables d’environnement, mémoires, sous-agents et métadonnées de projet découvertes automatiquement peuvent tous devenir visibles pour le modèle.
L’observation centrale est que ces entrées ne conservent pas toujours l’autorité de leur origine. Les chercheurs distinguent deux dimensions. La première apparaît lorsqu’un contenu contrôlé par un attaquant atteint un rôle de message plus privilégié. La seconde survient lorsqu’une information passe d’une portée courte, comme une session ou un projet, vers une portée persistante plus large, par exemple une mémoire ou une configuration au niveau de l’utilisateur.
Avec leur chaîne d’analyse CoRA, les auteurs recensent 463 sources de contexte et en valident 282 à l’exécution. Parmi elles, 183 sont insérées au rôle système, 60 au rôle utilisateur, 9 au rôle assistant et 30 au rôle outil. Les sources propres au projet forment le groupe le plus important. L’étude énumère ensuite 1 761 chemins candidats et vérifie, avec plusieurs modèles, si une instruction injectée est chargée et provoque l’effet comportemental attendu.
Ces chiffres ne signifient pas qu’il existe 282 vulnérabilités indépendantes et directement exploitables. Une même source peut participer à plusieurs chemins, et l’exploitation dépend de la manière dont l’attaquant peut la contrôler et dont l’environnement la compose. Le résultat structurel est plus important : les agents modernes combinent de nombreuses sources ayant des niveaux de confiance, de durée et de portée différents sans toujours imposer une règle explicite empêchant l’augmentation d’autorité.
Les attaques franchissent des frontières que les confirmations ne couvrent pas
La page du projet présente plusieurs démonstrations de bout en bout. Dans un scénario de revue de demande de fusion avec Codex, des instructions contrôlées par le dépôt modifient la politique de revue effectivement appliquée et excluent une partie vulnérable du code. Dans un scénario Cline, un texte fourni par un attaquant est cité par le modèle mais ensuite interprété comme une structure d’appel d’outil, ce qui permet des écritures persistantes et une modification de paramètres d’approbation. Un autre cas montre le déplacement d’un contenu malveillant par des métadonnées de gestion de versions et la mémoire de l’agent.
Ce mécanisme est différent d’une simple demande visant à faire ignorer les instructions précédentes. L’attaquant cherche à exploiter le système qui assemble et réinterprète le contexte. Une confirmation d’autorisation peut fonctionner correctement à un niveau alors qu’une source moins fiable est promue ailleurs vers une représentation dotée de davantage d’autorité.
Les auteurs indiquent avoir signalé leurs résultats aux responsables des 12 environnements. Selon eux, Codex, Gemini CLI et Cline ont publié des versions destinées à atténuer certains problèmes signalés, tandis qu’OpenAI et Anthropic ont accusé réception des découvertes. La divulgation coordonnée étant toujours en cours et certains détails restant volontairement limités, il serait imprudent d’en tirer une liste actuelle de produits vulnérables.
Le contexte a besoin de provenance, pas seulement de filtres
Le contrôle pratique dépasse l’ajout d’un nouveau filtre contre l’injection. L’environnement d’exécution devrait connaître l’origine de chaque fragment de contexte, l’entité capable de le modifier, sa durée de vie prévue et l’autorité maximale qu’il peut obtenir.
Cela conduit à une règle de non-élévation : un contenu non fiable ou à portée étroite ne devrait pas pouvoir devenir silencieusement un état plus privilégié ou plus durable parce qu’un analyseur, une mémoire, un chargeur de compétence ou une passerelle de configuration l’a recopié. Toute transition qui augmente le privilège devrait passer par une frontière explicite avec validation et décision de politique.
Le principe ressemble au suivi de données contaminées et à la séparation des privilèges dans les systèmes classiques. Une instruction de dépôt peut rester utile tout en portant une provenance indiquant qu’elle est contrôlée par le projet. Le résultat d’un outil peut être consulté sans être autorisé à réécrire la mémoire globale. Le modèle peut proposer de conserver une information, mais l’environnement peut exiger une opération distinctement autorisée avant qu’un contenu de session devienne un état durable pour l’utilisateur.
C’est précisément la partie qui devrait sortir de la seule ingénierie d’instructions. Les filtres peuvent réduire certaines formes connues d’injection, mais ils ne prouvent pas que l’autorité n’a pas augmenté lors du passage d’une source de contexte à une autre. La provenance, la portée, le rôle, la persistance et les droits d’écriture sont des propriétés que l’environnement peut faire respecter de façon déterministe.
Le résultat dépasse les attaques fondées sur Git
Aipolix a récemment examiné GitSpawn, une divulgation distincte dans laquelle une configuration Git malveillante pouvait provoquer l’exécution de commandes sur la machine lors de la collecte automatique de contexte. Ce cas était limité par une condition de livraison : le dépôt devait parvenir à la victime avec ses métadonnées .git contrôlées par l’attaquant, et non par une opération normale de clonage ou de récupération.
L’étude sur l’élévation du contexte inclut des vecteurs liés à la gestion de versions, mais sa contribution est beaucoup plus large. Sa taxonomie couvre la mémoire, la configuration, les compétences, les composants tiers, l’analyse de balises et les rafraîchissements de contexte dans plusieurs environnements. L’enjeu éditorial est donc différent : les métadonnées Git ne sont qu’une source possible, tandis que la véritable frontière de sécurité est le graphe des transformations qui convertissent de nombreuses sources en contexte privilégié.
Pour une équipe d’ingénierie, la bonne question n’est pas de savoir si son produit apparaît dans l’article. Elle doit pouvoir répondre, pour chaque élément de contexte : qui l’a fourni, à quelle portée il appartient, dans quel rôle il peut entrer, s’il peut devenir persistant et quelles transitions peuvent accroître son autorité.
Des limites importantes subsistent
L’étude est une prépublication et n’a pas été répliquée indépendamment. CoRA utilise lui-même un modèle de langage, les auteurs évaluent des versions précises des environnements et les résultats ne démontrent pas que les dernières versions de chaque produit cité restent affectées. Certaines corrections ont déjà été publiées, selon les chercheurs.
Les auteurs annoncent également la publication du code source complet, mais la page du projet fournit actuellement surtout des démonstrations et des artefacts, sans dépôt public CoRA clairement indiqué. La reproduction indépendante reste donc limitée. Les 282 sources validées et les taux d’attaque doivent être compris comme des mesures de l’équipe de recherche, pas comme des statistiques universelles de production.
Malgré ces réserves, le travail révèle un angle mort architectural utile. Les autorisations d’outils déterminent ce qu’un agent peut exécuter. Un contrôle de privilège du contexte doit aussi déterminer comment une information acquiert de l’autorité avant même que le modèle choisisse une action. Sans cette seconde frontière, l’agent peut hériter d’un niveau de confiance que la source d’origine n’a jamais mérité.