Résumé Technique : PRIVSCOPE

Énoncé du Problème

Les architectures d'agents hybrides local–cloud offrent un équilibre pratique entre autonomie et capacité. Dans ces systèmes, un Contrôleur Local (LC) de confiance, exécuté sur l'appareil, gère la planification et le raisonnement de routine, en déléguant les sous-tâches intensives en capacités (par exemple, la recherche en temps réel, le raisonnement complexe) à un Modèle de Langage Cloud (CLM) non fiable. Cependant, cette délégation crée une frontière de confidentialité critique.

Le LC construit les charges utiles pour le CLM en combinant la demande utilisateur actuelle avec un état de travail persistant qui s'accumule à travers les flux de travail. Cela conduit à une sur-divulgation, où la charge utile destinée au cloud contient plus d'informations que ce que la sous-tâche déléguée nécessite. L'article identifie trois formes spécifiques de ce risque :

1. Résidu de tâche antérieure : Des contextes provenant de flux de travail précédents (par exemple, fenêtres de disponibilité, noms de fournisseurs passés) inclus dans la charge utile actuelle, bien qu'ils soient sans rapport avec la nouvelle tâche.
2. Inclusion sans rapport avec la tâche : Des détails de profil (par exemple, identifiants de membres, dates de naissance) qui n'ont aucun rôle fonctionnel dans la sous-tâche déléguée.
3. Spécificité excessive : La divulgation d'informations avec une granularité plus fine que nécessaire (par exemple, adresse exacte vs quartier, symptôme précis vs catégorie large).

Les solutions existantes isolent soit les flux de travail pour empêcher les fuites inter-flux, soit appliquent un assainissement à usage général (comme le masquage) qui échoue à raisonner sur la portée spécifique de la charge utile assemblée par le LC, brisant souvent l'utilité de la tâche ou échouant à empêcher la ré-identification via le contexte.

Méthodologie : PRIVSCOPE

Les auteurs proposent PRIVSCOPE, un gouverneur de charge utile de confiance exécuté sur l'appareil qui impose une divulgation limitée à la tâche à la frontière LC→CLM, sans nécessiter de modifications auprès du fournisseur cloud. Le système fonctionne sur le principe que les informations sensibles ne doivent atteindre le cloud que lorsqu'elles sont requises pour la sous-tâche, et uniquement sous la forme la moins révélatrice suffisante pour l'utilité de la tâche.

PRIVSCOPE met en œuvre un pipeline en quatre étapes exécuté sur l'appareil :

1. Extraction des unités de divulgation et liaison locale :

   • La charge utile assemblée par le LC est décomposée en unités de divulgation typées ($U_t$).
   • Un processus d'extraction en couches est utilisé : des règles déterministes pour les motifs structurés (courriels, identifiants), une correspondance de profil pour les valeurs liées au compte, et un parsing léger (par exemple, spaCy) pour le contenu sémantique de classe ouverte.
   • Liaison locale : Les valeurs exactes liées au compte (par exemple, identifiants de membres d'assurance, détails de paiement) sont acheminées vers une table de liaison locale ($B_t$) et retirées de la charge utile. Elles restent sur l'appareil pour une action locale ultérieure mais n'atteignent jamais le cloud.

2. Nécessité cloud et contrôle du report :

   • Chaque unité se voit attribuer un rôle : cloud (nécessaire pour la sous-tâche) ou local (retenu).
   • Cette décision est prise via un appel de modèle local par lots qui évalue les unités dans le contexte de la tâche déléguée.
   • Des gardes conscientes de la provenance sont appliquées :
     • Demande actuelle : Filtrée en fonction de la nécessité de la tâche.
     • État de travail (Report antérieur) : Filtrage plus strict ; conservé uniquement si la demande actuelle en dépend explicitement (par exemple, « continuer depuis la précédente »).
     • Source inconnue : Jamais promue vers le cloud pour empêcher les fuites déduites par le LC.

3. Abstraction suffisante pour la tâche :

   • Les unités assignées au rôle « cloud » ne sont pas nécessairement libérées sous leur forme exacte.
   • PRIVSCOPE applique des hiérarchies d'abstraction typées (par exemple, $Région \prec Ville \prec Quartier \prec Adresse Exacte$).
   • Une politique calibrée hors ligne sélectionne la représentation la plus grossière suffisante pour la tâche déléguée (par exemple, remplacer une date exacte par une « fenêtre hebdomadaire » ou un symptôme spécifique par une « catégorie de service »).
   • Cette étape garantit que le CLM reçoit une vue minimisée suffisante pour la découverte de candidats.

4. Résolution locale et achèvement du flux de travail :

   • La charge utile assainie ($\hat{P}_t$) est envoyée au CLM.
   • Après réception des résultats de candidats, le LC utilise l'état privé retenu (provenant de $B_t$ et de l'état de travail) pour ancrer la réponse, classer les candidats et compléter le flux de travail localement.

Contributions Clés

L'article expose quatre contributions principales :

1. Caractérisation du problème : Identification et caractérisation de la sur-divulgation d'état persistant comme un risque de confidentialité distinct dans les agents hybrides, où la charge utile assemblée par le LC (et pas seulement l'invite brute) expose des résidus de tâches antérieures et un état sans rapport avec la tâche.
2. Formulation : Une formulation du contrôle de la divulgation limité à la tâche comme un problème de médiation de charge utile à la frontière LC→CLM, décomposant la charge utile en unités typées avec une provenance de source.
3. Conception du système : La conception de PRIVSCOPE, qui combine la liaison locale des valeurs exactes, le filtrage de nécessité conscient de la provenance et l'abstraction suffisante pour la tâche. Cela permet à l'état privé exact de rester sur l'appareil tout en exposant une vue de tâche minimisée au CLM.
4. Évaluation : Mise en œuvre et évaluation sur 100 flux de travail de découverte de fournisseurs de réservation médicale à travers trois CLM commerciaux et cinq architectures locales.

Résultats Expérimentaux

L'évaluation compare PRIVSCOPE à une base de référence non protégée (Vanilla), à une réécriture basée sur l'invite (PEP) et au masquage déterministe (Presidio).

• Confidentialité :
  • Fuite de profil : PRIVSCOPE élimine totalement la fuite de profil (0,0 %), contre 17,7 % pour la base de référence non protégée.
  • Risque de ré-identification (RIR) : PRIVSCOPE réduit la récupération de valeurs privées par un attaquant à 23,1 %, soit plus de la moitié de la réduction par rapport à la base de référence non protégée (64,3 %) et surpassant PEP (39,6 %) et Presidio (29,3 %).
  • Fuite par injection : Il réduit l'injection d'état non sollicitée d'un ordre de grandeur (0,3 % contre 5,1 % dans Vanilla).
• Utilité :
  • Rappel des candidats : PRIVSCOPE atteint le rappel de candidats le plus élevé sur tous les LLM cloud testés (par exemple, 54,1 % sur GPT-4o-mini, 69,6 % sur Gemini 2.5 Flash), surpassant significativement Presidio (25,5 % sur GPT-4o-mini) qui supprime souvent le contexte critique pour la tâche.
  • Succès de la tâche : Sur GPT-4o-mini et Gemini 2.5 Flash, les taux de réussite des tâches restent proches de la base de référence non protégée (82–86 %), tandis que Presidio provoque des baisses significatives en raison d'un masquage excessif.
• Efficacité :
  • Latence : Le système ajoute environ 3,13 secondes de latence de médiation sur l'appareil sur du matériel grand public (MacBook M2 Pro) en utilisant un modèle local de 3 milliards de paramètres.
  • Coût cloud : PRIVSCOPE réduit les coûts d'API cloud de 13 à 23 % par rapport à la réécriture basée sur l'invite, car il minimise la taille de la charge utile plutôt que de l'élargir pour plus de clarté.

Importance et Revendications

L'article revendique que PRIVSCOPE offre un compromis confidentialité–utilité–coût plus fort que les approches existantes. Contrairement aux méthodes de masquage qui brisent l'utilité de la tâche ou à la réécriture d'invites qui est fragile et dépendante du modèle, la médiation structurée et consciente de la provenance de PRIVSCOPE garantit que :

1. La confidentialité est préservée en empêchant le cloud de voir les identifiants inutiles et les résidus de flux de travail antérieurs.
2. L'utilité est maintenue en n'abstrayant les données sensibles qu'au niveau nécessaire pour la sous-tâche déléguée spécifique, permettant au contrôleur local de résoudre la tâche finale en utilisant l'état privé.
3. La déployabilité est élevée car il fonctionne comme un plug-in sur l'appareil, ne nécessite aucune modification côté cloud et réutilise le modèle de contrôleur local existant pour la médiation.

Les auteurs notent que leur évaluation se concentre sur les délégations de recherche d'informations dans le domaine de la réservation médicale. Ils reconnaissent que, bien que la conception s'applique largement aux charges utiles LC–CLM, des travaux futurs sont nécessaires pour gérer les segments implicites, apprendre dynamiquement les hiérarchies d'abstraction et traiter les CLM adverses. Le système est présenté comme une étape pratique vers la sécurisation des systèmes d'agents hybrides contre les fuites d'état persistant.