Vol de prompt par le temps : canaux auxiliaires du cache de préfixe en LLM mutualisé

De quoi s’agit-il ?

Les systèmes modernes de service de LLM mettent en cache le travail déjà effectué. L’Automatic Prefix Caching (APC) réutilise les tenseurs clé-valeur calculés pour le début d’une requête dès qu’une requête ultérieure commence par le même texte — un gain de vitesse important pour les longs documents et les conversations multi-tours. Le problème : un succès de cache (hit) est plus rapide qu’un échec (miss), et cette différence de temps est observable de l’extérieur. Dans un déploiement mutualisé où le cache de préfixe est partagé entre utilisateurs, un attaquant peut envoyer des prompts forgés, mesurer le temps du premier token et déduire si le préfixe qu’il a deviné correspond à quelque chose qu’un autre locataire avait déjà mis en cache. En répétant la sonde, token par token, on reconstitue le prompt d’un inconnu.

Ce n’est pas théorique. Une équipe de Stanford — Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang et Tatsunori Hashimoto — a audité de vraies API dans Auditing Prompt Caching in Language Model APIs (arXiv 2502.07776, février 2025, accepté à ICML 2025) et a détecté un partage de cache global entre utilisateurs chez sept fournisseurs d’API, dont OpenAI. Le même signal temporel a même révélé un fait d’architecture : que le modèle d’embedding d’OpenAI est un Transformer decoder-only. La publication la plus récente de cette lignée, CacheSolidarity (arXiv 2603.10726, mars 2026), est à l’origine de cet article.

Comment ça marche

Il n’y a pas de payload à caviarder ici — l’attaque est une pure mesure contre une API en boîte noire. Le mécanisme :

Étape                        Ce qui se passe
---------------------------  --------------------------------------------------
1. Choisir un préfixe cible  Deviner une chaîne par laquelle le prompt d'une
                             victime pourrait commencer (en-tête de system
                             prompt, adresse e-mail, identifiant de compte)
2. Sonder                    Envoyer une requête débutant par ce candidat et
                             relever le time-to-first-token (TTFT)
3. Classer hit / miss        TTFT bas => le préfixe était déjà en cache chez
                             un autre (hit) ; TTFT élevé => miss
4. Étendre & répéter         Ajouter le token suivant, re-sonder, et avancer
                             le préfixe morceau par morceau

L’attaquant ne lit jamais directement les données d’un autre utilisateur ; il les déduit de la latence. Des travaux ultérieurs en montrent la portée : PromptPeek (Wu et al., 2025), tel que rapporté par l’étude SafeKV, reconstitue des prompts avec jusqu’à 99 % de précision lorsque le gabarit du prompt est connu, et ~95 % sans cette connaissance, en ciblant l’ordonnancement par arbre radix utilisé par des frameworks comme SGLang. CacheSolidarity et SafeKV listent le même ensemble de systèmes qui embarquent le cache de préfixe : OpenAI, DeepSeek, Google Gemini, MoonShot Kimi, vLLM et SGLang.

Pourquoi c’est important

L’exposition croît avec la quantité de texte sensible qui se retrouve dans un préfixe partagé. Les auteurs de SafeKV notent que des corpus de pré-entraînement courants comme C4 et le Pile contiennent des noms d’utilisateur, des numéros de téléphone, des numéros de carte de paiement et des numéros de sécurité sociale — précisément le type de séquence qui devient inférable s’il est mis en cache et partagé entre locataires. Tout ce que vous placez en tête d’un prompt — un system prompt contenant des secrets, une fiche client préfixée pour le contexte, un document récupéré — est un candidat à la reconstruction par un co-locataire.

Pour rester honnête : il s’agit d’une fuite de confidentialité sous conditions précises, pas d’une exécution de code à distance. L’attaquant a besoin d’un service mutualisé qui partage le cache au-delà des frontières de sécurité, d’un écart de temps mesurable et d’un budget de sondage suffisant. L’analyse de CacheSolidarity souligne que l’exploitabilité dépend du matériel, de la taille du modèle, de la charge et de la longueur des requêtes — sur certaines configurations, l’écart hit/miss est trop bruité pour être exploité. C’est un vrai facteur atténuant, mais c’est une propriété du déploiement, pas une garantie.

Défenses

La recherche a convergé vers trois familles de défense, selon une progression nette dans la finesse de la coupe.

1. Isolation complète par utilisateur. Désactiver entièrement le partage de préfixe entre locataires ; chaque utilisateur (ou organisation) dispose d’un cache privé. Cela ferme le canal mais annule le bénéfice de l’APC. SafeKV a mesuré une isolation qui gonfle le time-to-first-token jusqu’à ~38 % sur les grands modèles ; CacheSolidarity rapporte des coûts similaires. Efficace, brutal, coûteux.
2. Obscurcissement temporel. Ajouter du padding ou de la gigue pour rendre hits et misses indistinguables. Le piège, explicité par les deux articles : l’attaquant n’a besoin que d’une séparation statistique, il faut donc rembourrer les hits vers la queue lente de la distribution des miss — ce qui efface l’essentiel du gain de latence et gonfle les P95/P99.
3. Isolation sélective. Partager par défaut, n’isoler que ce qui est risqué. SafeKV (arXiv 2508.08438) classe les préfixes sensibles de façon asynchrone et les garde privés, récupérant un débit jusqu’à 2,66× face à l’isolation complète. CacheSolidarity va plus loin : il suit la propriété des préfixes, signale ceux que plusieurs utilisateurs réutilisent de façon suspecte, et n’isole que ceux-là — avec en plus un « Activator » qui n’enclenche l’isolation que lorsque l’écart de temps est réellement distinguable pour le matériel et la charge du moment. Construit sur vLLM et évalué sur neuf modèles (0,5 à 13 milliards de paramètres), il rapporte jusqu’à 70 % de réutilisation de cache en plus et 30 % de latence en moins que l’isolation par utilisateur, avec un surcoût négligeable, et les auteurs annoncent une mise en open source.

Pour les équipes qui exploitent ou achètent de l’inférence LLM, la liste pratique :

• Ne placez pas de secrets en position de préfixe partagé. Gardez les clés d’API, les identifiants et les données personnelles propres à chaque utilisateur hors des system prompts et hors de la tête cacheable d’une requête.
• Cantonnez le cache à une frontière de confiance. Un cache cloisonné par organisation ou par locataire supprime le canal inter-locataires ; vérifiez que votre fournisseur procède ainsi plutôt qu’un partage global.
• Traitez la politique de cache comme une question d’achat. Demandez aux fournisseurs si le cache de préfixe ou sémantique est partagé entre clients et combien de temps les entrées persistent — les fournisseurs de l’audit avaient des durées de rétention allant de quelques minutes à plusieurs jours.
• En auto-hébergement, préférez l’isolation sélective. L’isolation complète fonctionne mais coûte cher ; les approches de type SafeKV et CacheSolidarity conservent le gain de vitesse tout en fermant le canal.

Statut

Élément	Référence	Date	Notes
Audit empirique d’API	arXiv 2502.07776 (Stanford, ICML 2025)	2025-02	Partage de cache inter-utilisateurs chez 7 fournisseurs, dont OpenAI
Attaque de vol de prompt	NDSS 2025 (Wu et al.)	2025	Reconstruction de prompt jusqu’à 99 % / 95 % via cache KV partagé
SafeKV (isolation sélective)	arXiv 2508.08438	2025-08	Classification de sensibilité asynchrone ; débit jusqu’à 2,66× vs isolation
CacheSolidarity (isolation sélective)	arXiv 2603.10726	2026-03	Signale la réutilisation suspecte ; jusqu’à +70 % de réutilisation, -30 % de latence vs isolation

Le fil rouge de deux ans de recherche : les optimisations de vitesse dont dépend le service de LLM — le partage de cache de préfixe et de KV — sont aussi un canal auxiliaire de confidentialité dès que le cache franchit une frontière de confiance. Les travaux de 2026 ne vous demandent pas de choisir entre vitesse et sécurité ; ils montrent que le canal peut être fermé en isolant les quelques préfixes qui comptent plutôt qu’en cloisonnant chaque utilisateur.