Need to Know : réécriture de requêtes par intégrité contextuelle

De quoi s’agit-il ?

Le 2 juin 2026, Xinyue Huang, Xiaochun Cao et Wenyuan Yang ont publié Need to Know: Contextual-Integrity-Grounded Query Rewriting for Privacy-Conscious LLM Delegation (arXiv:2606.04067, cs.CR / cs.AI). Le papier traite une exposition de données facile à négliger parce que rien ne « casse » : chaque fois qu’un utilisateur délègue une tâche à un LLM hébergé dans le cloud, son prompt embarque régulièrement des informations sensibles non essentielles à la tâche, aux côtés du contenu réellement nécessaire. Le fournisseur — et quiconque a accès à ses journaux — reçoit les deux.

L’argument central des auteurs est que la parade habituelle, la caviardage des PII par type, est le mauvais outil. Un redacteur qui masque tout ce qui ressemble à un nom, une adresse ou un numéro de carte est indépendant du contexte : il sur-divulgue à la fois le contexte sensible non typé (un détail médical, une relation, un lieu suggéré dans la prose) et sur-supprime les segments porteurs de réponse dont le modèle avait besoin. La contribution est une reformulation, accompagnée d’un benchmark et d’un réécriveur entraîné — pas d’une attaque.

Comment ça marche

Le papier reformule la réécriture de requêtes respectueuse de la vie privée sous l’angle de l’intégrité contextuelle (Contextual Integrity, CI) : un flux d’information n’est approprié que s’il respecte les normes du contexte dans lequel l’information a été partagée. Traduit en règle pour la délégation, cela devient un test unique — un segment ne doit être transmis au modèle cloud que s’il est nécessaire à la tâche. Le critère de décision est la nécessité, pas le type de donnée.

Pour rendre cela mesurable, les auteurs construisent DelegateCI-Bench, présenté comme le premier benchmark d’intégrité contextuelle orienté tâche pour la délégation respectueuse de la vie privée. Il comprend 3 167 échantillons combinant des données synthétiques couvrant 11 tâches et 20 types de tâches, des requêtes utilisateur réelles tirées de WildChat, et un jeu d’épreuves médical dense en informations sensibles.

# Décision conceptuelle, segment par segment — descriptif, pas du code exécutable.
# Source : arXiv:2606.04067 (Huang, Cao & Yang, 2026).

caviardage par type :   mask(span) si regex/NER dit "PII"     # aveugle au contexte
intégrité contextuelle: forward(span) seulement si task_essential(span)
                        sinon suppress(span)                  # fondé sur la nécessité

Au-dessus du benchmark, ils entraînent un réécriveur de requêtes avec un cadre d’apprentissage par renforcement guidé par la CI, qui transforme les segments « essentiels » et « sensibles non essentiels » en signaux d’optimisation vérifiables — le réécriveur est récompensé lorsqu’il conserve l’information critique pour la tâche tout en retirant les divulgations superflues. Résultat rapporté : le réécriveur appris atteint le meilleur compromis vie privée / utilité, jusqu’à +10,1 d’utilité moyenne par rapport aux références embarquées (on-device).

Pourquoi c’est important

C’est le versant quotidien de l’exposition de données par les LLM. Aucun payload malveillant, aucun modèle compromis — juste le volume de contexte sensible qui part vers des fournisseurs tiers parce qu’un prompt est l’endroit le plus commode pour déverser tout ce que l’on sait. Pour les workflows régulés (santé, juridique, RH), ce flux est autant une surface de conformité qu’un sujet de vie privée, et « nous caviardons les PII avant l’envoi » est un contrôle plus faible qu’il n’y paraît : les redacteurs par type ratent le contexte qui n’est pas un type de PII reconnu, et cassent l’utilité quand ils effacent le segment qui portait la réponse.

Le cadrage CI est transposable bien au-delà de ce seul réécriveur. Toute équipe construisant une passerelle devant un modèle cloud — un proxy, un filtre DLP, un pré-traitement embarqué — prend implicitement des décisions de transmission ou de suppression. Les prendre par nécessité plutôt que par type de donnée est un modèle mental plus propre, et un benchmark comme DelegateCI-Bench permet de vérifier qu’un filtre préserve réellement les réponses tout en réduisant les fuites, au lieu d’échanger un échec contre un autre.

Défenses

Le papier est la défense, mais les enseignements pour la pratique sont concrets. Traitez la minimisation des données vers les LLM cloud comme un test de nécessité, pas comme un passage de regex : demandez-vous si chaque segment sensible change la réponse, et supprimez-le si ce n’est pas le cas. Mesurez les deux moitiés du compromis — vie privée et utilité — car un redacteur qui retire discrètement du texte porteur de réponse échoue en silence et les utilisateurs le contournent. Quand c’est possible, exécutez l’étape de réécriture / minimisation sur l’appareil ou à l’intérieur de votre périmètre de confiance, pour que la suppression intervienne avant toute sortie, et conservez un jeu d’évaluation à part (médical ou autre, à forte sensibilité) pour détecter les régressions de sur-divulgation.

Deux mises en garde honnêtes. Un réécriveur appris est lui-même un modèle : il peut classer un segment comme non essentiel et écarter quelque chose qui comptait, ou conserver ce qu’il aurait fallu retirer — c’est donc une couche de réduction du risque, pas une garantie, et les flux à fort enjeu méritent toujours une revue humaine et un cantonnement au moindre privilège de ce que voit le modèle cloud. Et le chiffre de +10,1 est une moyenne de benchmark des auteurs ; les gains réels dépendent de votre mix de tâches et de la sensibilité effective de vos requêtes.

Statut

Élément	Référence	Date	Notes
Papier principal	arXiv:2606.04067 (Huang, Cao, Yang)	2026-06-02	cs.CR / cs.AI ; v1
Benchmark	DelegateCI-Bench	2026-06	3 167 échantillons, 11 tâches, 20 types de tâches, WildChat + jeu médical
Méthode	Réécriveur par apprentissage par renforcement guidé CI	2026-06	Meilleur compromis vie privée / utilité, jusqu’à +10,1 d’utilité moyenne vs références embarquées
Cadrage	Intégrité contextuelle : ne transmettre un segment que s’il est essentiel à la tâche	2026-06	Remplace le caviardage des PII par type, aveugle au contexte

Il s’agit d’un résultat de recherche, pas d’une vulnérabilité produit divulguée — il n’y a rien à corriger. L’enseignement actionnable est architectural : décidez de ce qui atteint un LLM cloud par nécessité, pas par type de donnée, et mesurez l’utilité en même temps que la vie privée, afin que votre couche de minimisation n’efface pas silencieusement la réponse.