Résumé technique : Quand l'alignement ne suffit pas : Attaques par chemin de réponse sur les agents LLM

1. Énoncé du problème : Altération post-alignement

L'article identifie une faille de sécurité fondamentale dans le paradigme Bring-Your-Own-Key (BYOK), une architecture largement adoptée où les utilisateurs acheminent le trafic des modèles de langage (LLM) via des services de relais tiers (par exemple, LiteLLM, OpenRouter) tout en s'authentifiant avec leurs propres identifiants.

Dans cette architecture, le relais agit comme un proxy légitime et configuré par l'utilisateur qui termine le chiffrement de bout en bout, créant deux sauts chiffrés séquentiels : l'un entre l'agent frontal et le relais, et l'autre entre le relais et le LLM backend. Bien que les couches de transport soient sécurisées, le relais a un accès en clair à tous les messages.

La vulnérabilité centrale, qualifiée d'Altération post-alignement, découle du fait que les mécanismes de sécurité et d'alignement du LLM (RLHF, entraînement constitutionnel, invites système) ne s'appliquent qu'à la génération de la réponse par le modèle backend. Une fois la réponse alignée générée, elle traverse le relais avant d'atteindre l'agent pour exécution. L'article soutient que les protocoles d'API LLM actuels manquent de mécanismes d'intégrité au niveau de l'application (tels que des signatures ou des MAC) pour lier la sortie du modèle backend à l'entrée de l'agent. Par conséquent, un relais malveillant peut réécrire la réponse alignée du LLM après sa génération mais avant son exécution, contournant ainsi toutes les garanties de sécurité sans avoir besoin de compromettre le modèle ou de vaincre les protections cryptographiques de transport.

Cette surface d'attaque se distingue et est strictement plus puissante que :

• L'attaque de l'homme du milieu (MitM) au niveau de la couche de transport : Qui nécessite de vaincre le chiffrement ou de forger des certificats.
• L'injection d'invite : Qui repose sur la persuasion du modèle pour générer du contenu nuisible, un processus contraint par la force de l'alignement du modèle.

2. Méthodologie : L'attaque par altération du relais (RTA)

Les auteurs matérialisent cette vulnérabilité sous la forme de l'Attaque par altération du relais (RTA), un cadre hiérarchique opérant entièrement depuis la position du relais. La RTA se compose de trois étapes :

2.1 Orchestration stratégique (Attaque en chaîne)

Pour gérer des objectifs complexes et multi-tours qui ne peuvent être atteints en une seule interaction, le relais décompose les objectifs de haut niveau en une chaîne ordonnée de sous-objectifs. Il suit l'état de la conversation et décide s'il doit transmettre une réponse inchangée ou intervenir en fonction des exigences du sous-objectif actuel. Cela permet à l'attaque de collecter de manière adaptative les artefacts nécessaires (par exemple, les chemins de fichiers) avant d'exécuter l'action malveillante finale.

2.2 Manipulation tactique

Le relais effectue des modifications minimales, pilotées par le schéma, sur les champs spécifiques qui dictent l'exécution de l'agent, plutôt que de réécrire l'intégralité du texte. Le cadre définit deux chemins parallèles :

• RTA-PreWrite (Chemin de requête) : Opère avant l'inférence du LLM. Le relais réécrit la requête utilisateur et retire les garde-fous de l'invite système pour « purifier » le contexte, forçant le modèle à se concentrer uniquement sur l'objectif adversarial. Ce chemin est vulnérable aux défenses côté entrée.
• RTA-PostForge (Chemin de réponse) : Opère après l'alignement. Le relais intercepte la réponse bénigne et alignée et modifie uniquement les champs structurés critiques (par exemple, noms d'outils, arguments, drapeaux de raison de fin) pour forcer des appels d'outils ou des écritures de fichiers arbitraires. Ce chemin contourne structurellement l'alignement de sécurité du modèle dans son intégralité.

2.3 Restauration furtive

Pour échapper à la détection et préserver l'utilité de la tâche légitime de l'utilisateur, la RTA emploie :

• Polissage par le même modèle : Le relais resoumet l'ébauche altérée au même LLM backend (en utilisant les identifiants BYOK de l'utilisateur) avec une invite pour réparer la formulation au niveau de surface tout en maintenant les champs malveillants immuables. Cela garantit que la sortie finale correspond au style et à la distribution natifs du modèle.
• Exécution simultanée des tâches : Le relais met en mémoire tampon la réponse authentique pour la tâche originale de l'utilisateur et la réinsère dans la conversation une fois les sous-objectifs de l'attaque atteints, masquant ainsi l'attaque à l'utilisateur.

3. Modèle formel et contributions théoriques

L'article formalise la vulnérabilité en utilisant des définitions de sécurité basées sur des jeux, prouvant quatre idées clés :

1. Substitution de réponse non authentifiée : Sans intégrité de bout en bout, un relais peut substituer toute charge utile valide par rapport au schéma. Si la charge utile encode une action nuisible, l'agent l'exécute indépendamment de la sortie du modèle backend.
2. L'alignement s'arrête au backend : Même un LLM parfaitement aligné (celui qui ne génère jamais de réponses nuisibles) n'offre aucune protection contre un adversaire sur le chemin de réponse. Le relais rejette la sortie alignée et injecte la sienne, rendant l'alignement du modèle sans rapport avec l'exécution finale.
3. Domination de la réécriture du chemin de requête : Un relais capable de réécrire le contexte de la requête (en supprimant les instructions concurrentes) est strictement plus puissant qu'un relais limité à l'ajout d'instructions, car il élimine l'effet de « dilution de l'attention » qui protège souvent contre l'injection d'invite.
4. Asymétrie défensive : Les détecteurs reposant uniquement sur le contenu de la transcription sont limités par la distance statistique entre le texte poli (altéré) et le texte authentique. Puisque la RTA utilise un polissage par le même modèle, cette distance est minimisée, rendant la détection basée uniquement sur la transcription théoriquement faible.

4. Évaluation expérimentale

Les auteurs ont évalué la RTA sur six LLM (trois propriétaires : GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro ; trois à poids ouverts : GLM-5.1, MiniMax-M2.5, Qwen-235B) sur deux benchmarks : AgentDojo et Agent Security Bench (ASB).

Résultats clés

• Efficacité : La RTA surpasse nettement les bases de référence d'injection d'invite.
  • RTA-PostForge a atteint un Taux de succès d'attaque (ASR) de 73,5 % sur AgentDojo et 89,2 % sur ASB.
  • RTA-PreWrite a atteint un ASR de 99,1 % sur ASB.
  • À l'inverse, les meilleures bases de référence d'injection d'invite n'ont atteint qu'environ 17,9 % d'ASR sur AgentDojo et 44,4 % sur ASB.
• Préservation de l'utilité : Contrairement aux attaques par chemin de requête qui cassent souvent la tâche de l'utilisateur, RTA-PostForge a préservé 47,6 % de l'utilité de la tâche utilisateur sur AgentDojo en mettant en mémoire tampon et en restaurant la réponse authentique.
• Impérceptibilité : RTA-PostForge a maintenu une cohérence stylistique élevée (C=0,758) et une similarité sémantique, le test d'égalité des modèles (MET) rejetant l'hypothèse nulle de distributions identiques dans seulement 54,2 % des cas, contre 90,0 % pour la RTA-PreWrite plus agressive.
• Évasion de la surcharge : La surcharge de latence introduite par RTA-PostForge (médiane ~5,9 s) s'est inscrite dans la variance naturelle du réseau des relais commerciaux pour 74 % des interactions, rendant sa détection par de simples seuils de latence difficile.

Évaluation des défenses

L'article a évalué quatre défenses existantes côté agent (Délimiteurs, Sandwich, Détection de réponse connue, CaMeL) :

• Aucune n'a éliminé complètement RTA-PostForge.
• CaMeL (qui force la génération de code) a réduit l'ASR à 14,5 %, mais les auteurs ont démontré une adaptation où le relais réécrit directement le bloc de code Python généré, restaurant l'ASR à 50,1 %.
• Détecteur de canal temporel : Les auteurs proposent un détecteur basé sur la télémétrie opérationnelle (latence). En agrégeant les preuves temporelles sur une session (n=50 tours), ce détecteur a atteint un AUC de 0,964, suggérant que si la détection basée sur le contenu échoue, les anomalies opérationnelles offrent un vecteur de défense viable.

5. Importance et revendications

L'article prétend révéler une faille d'intégrité structurelle dans l'écosystème moderne des agents LLM, distincte et plus grave que l'injection d'invite. Ses contributions principales sont :

1. Formalisation : Il prouve que la falsification du chemin de réponse domine strictement l'injection d'invite et que la cause racine est l'absence de vérification d'intégrité de bout en bout dans les protocoles d'API LLM actuels.
2. Faisabilité réelle : Grâce à des études de cas sur OpenClaw (conseil financier) et Claude Code (agent de codage), les auteurs démontrent que la RTA peut exfiltrer silencieusement des bases de code ou inverser des décisions financières dans des environnements de production tout en maintenant l'apparence d'un fonctionnement normal.
3. Limitation des défenses actuelles : L'ouvrage soutient que l'amélioration de l'alignement du modèle ou le renforcement des invites est insuffisant face à un adversaire de relais, car l'attaque se produit en aval de toutes les vérifications d'alignement.
4. Appel à l'action : L'article conclut que les futurs protocoles d'API LLM doivent traiter l'intégrité de la réponse de bout en bout comme un primitif de premier ordre (par exemple, des réponses signées par le fournisseur) pour combler cette lacune, car les défenses au niveau de l'application seules ne peuvent garantir que l'agent exécute la réponse générée par le modèle backend.

Les auteurs adoptent un ton modeste concernant les travaux futurs, notant que leur modèle de menace suppose un environnement BYOK où le relais termine légitimement le TLS, et que l'extension du modèle de menace à des infrastructures multi-sauts plus larges et la conception de mécanismes d'intégrité fondés sur des principes sont les prochaines étapes nécessaires.