Riepilogo Tecnico: PRIVSCOPE

Enunciato del Problema

Le architetture ibride di agenti locale–cloud offrono un equilibrio pratico tra autonomia e capacità. In questi sistemi, un Controller Locale (LC) affidabile, residente sul dispositivo, gestisce la pianificazione e il ragionamento di routine, delegando i sottocompiti ad alta intensità computazionale (ad esempio, recupero in tempo reale, ragionamento complesso) a un Modello Linguistico Cloud (CLM) non affidabile. Tuttavia, questa delega crea un confine critico per la privacy.

Il LC costruisce i payload per il CLM combinando la richiesta corrente dell'utente con uno stato di lavoro persistente che si accumula attraverso i flussi di lavoro. Ciò porta a una sovra-disclosure, dove il payload diretto al cloud contiene più informazioni di quanto richiesto dal sottocompito delegato. Il documento identifica tre forme specifiche di questo rischio:

1. Residuo di compiti precedenti: Contesto da flussi di lavoro precedenti (ad esempio, finestre di disponibilità, nomi di provider passati) incluso nel payload corrente nonostante sia irrilevante per il nuovo compito.
2. Inclusione irrilevante per il compito: Dettagli del profilo (ad esempio, ID membri, date di nascita) che non hanno alcun ruolo funzionale nel sottocompito delegato.
3. Specificità eccessiva: Rivelazione di informazioni con una granularità più fine del necessario (ad esempio, indirizzo esatto vs. quartiere, sintomo preciso vs. categoria ampia).

Le soluzioni esistenti isolano i flussi di lavoro per prevenire la fuoriuscita tra flussi o applicano sanificazioni generiche (come la rimozione di dati) che non riescono a ragionare sullo scopo specifico del payload assemblato dal LC, spesso compromettendo l'utilità del compito o fallendo nel prevenire la ri-identificazione tramite contesto.

Metodologia: PRIVSCOPE

Gli autori propongono PRIVSCOPE, un governatore di payload affidabile residente sul dispositivo che impone una disclosure limitata al compito al confine LC→CLM senza richiedere modifiche al provider cloud. Il sistema opera sul principio che le informazioni sensibili dovrebbero raggiungere il cloud solo quando necessarie per il sottocompito e solo nella forma meno rivelatrice sufficiente per l'utilità del compito.

PRIVSCOPE implementa una pipeline on-device in quattro fasi:

1. Estrazione e Legame Locale delle Unità di Disclosure:

   • Il payload assemblato dal LC viene scomposto in unità di disclosure ($U_t$) tipizzate.
   • Viene utilizzato un processo di estrazione a livelli: regole deterministiche per pattern strutturati (email, ID), corrispondenza del profilo per valori legati all'account e parsing leggero (ad esempio, spaCy) per contenuti semantici di classe aperta.
   • Legame Locale: I valori esatti legati all'account (ad esempio, ID membri assicurativi, dettagli di pagamento) vengono instradati a una tabella di legame locale ($B_t$) e rimossi dal payload. Questi rimangono sul dispositivo per una successiva attuazione locale ma non raggiungono mai il cloud.

2. Controllo della Necessità Cloud e del Trasferimento:

   • A ogni unità viene assegnato un ruolo: cloud (necessario per il sottocompito) o locale (trattenuto).
   • Questa decisione è presa tramite una chiamata batchata a un modello locale che valuta le unità nel contesto del compito delegato.
   • Vengono applicati guardiani consapevoli della provenienza:
     • Richiesta Corrente: Filtrata in base alla necessità del compito.
     • Stato di Lavoro (Trasferimento Precedente): Filtraggio più rigoroso; mantenuto solo se la richiesta corrente dipende esplicitamente da essi (ad esempio, "continua dal precedente").
     • Fonte Sconosciuta: Mai promossa al cloud per prevenire fuoriuscite inferite dal LC.

3. Astrazione Sufficiente al Compito:

   • Le unità assegnate al ruolo "cloud" non vengono necessariamente rilasciate nella loro forma esatta.
   • PRIVSCOPE applica gerarchie di astrazione tipizzate (ad esempio, $Regione \prec Città \prec Quartiere \prec Indirizzo Esatto$).
   • Una politica calibrata offline seleziona la rappresentazione più grezza sufficiente per il compito delegato (ad esempio, sostituire una data esatta con una "finestra a livello di settimana" o un sintomo specifico con una "categoria di servizio").
   • Questa fase garantisce che il CLM riceva una visione minimizzata sufficiente per la scoperta dei candidati.

4. Risoluzione Locale e Completamento del Flusso di Lavoro:

   • Il payload sanificato ($\hat{P}_t$) viene inviato al CLM.
   • Ricevuti i risultati dei candidati, il LC utilizza lo stato privato trattenuto (da $B_t$ e stato di lavoro) per ancorare la risposta, classificare i candidati e completare il flusso di lavoro localmente.

Contributi Chiave

Il documento delinea quattro contributi principali:

1. Caratterizzazione del Problema: Identificazione e caratterizzazione della sovra-disclosure dello stato persistente come un rischio di privacy distinto negli agenti ibridi, dove il payload assemblato dal LC (non solo il prompt grezzo) espone residui di compiti precedenti e stati irrilevanti per il compito.
2. Formulazione: Una formulazione del controllo della disclosure limitato al compito come un problema di mediazione del payload al confine LC→CLM, scomponendo il payload in unità tipizzate con provenienza della fonte.
3. Progettazione del Sistema: La progettazione di PRIVSCOPE, che combina il legame locale dei valori esatti, il filtraggio della necessità consapevole della provenienza e l'astrazione sufficiente al compito. Ciò permette allo stato privato esatto di rimanere sul dispositivo esponendo al CLM una visione del compito minimizzata.
4. Valutazione: Implementazione e valutazione su 100 flussi di lavoro di scoperta di provider per prenotazioni mediche su tre CLM commerciali e cinque back-end locali.

Risultati Sperimentali

La valutazione confronta PRIVSCOPE con una baseline non protetta (Vanilla), riscrittura basata su prompt (PEP) e rimozione deterministica (Presidio).

• Privacy:
  • Fuga di Profilo: PRIVSCOPE elimina completamente la fuga di profilo (0.0%), rispetto al 17.7% della baseline non protetta.
  • Rischio di Ri-identificazione (RIR): PRIVSCOPE riduce il recupero di valori privati basato sull'attaccante al 23.1%, più che dimezzando la baseline non protetta (64.3%) e superando PEP (39.6%) e Presidio (29.3%).
  • Fuga da Iniezione: Riduce l'iniezione di stato non sollecitato di un ordine di grandezza (0.3% vs 5.1% in Vanilla).
• Utilità:
  • Recall dei Candidati: PRIVSCOPE ottiene il recall dei candidati più alto su tutti i LLM cloud testati (ad esempio, 54.1% su GPT-4o-mini, 69.6% su Gemini 2.5 Flash), superando significativamente Presidio (25.5% su GPT-4o-mini) che spesso rimuove contesti critici per il compito.
  • Successo del Compito: Su GPT-4o-mini e Gemini 2.5 Flash, i tassi di successo del compito rimangono vicini alla baseline non protetta (82–86%), mentre Presidio causa cali significativi a causa della rimozione eccessiva.
• Efficienza:
  • Latenza: Il sistema aggiunge circa 3.13 secondi di latenza di mediazione on-device su hardware commerciale (MacBook M2 Pro) utilizzando un modello locale da 3 miliardi di parametri.
  • Costo Cloud: PRIVSCOPE riduce i costi delle API cloud del 13–23% rispetto alla riscrittura basata su prompt, poiché minimizza le dimensioni del payload invece di espanderle per chiarezza.

Significato e Affermazioni

Il documento afferma che PRIVSCOPE offre un compromesso privacy–utilità–costo più forte rispetto agli approcci esistenti. A differenza dei metodi di rimozione che compromettono l'utilità del compito o della riscrittura dei prompt che è fragile e dipendente dal modello, la mediazione strutturata e consapevole della provenienza di PRIVSCOPE garantisce che:

1. La privacy è preservata impedendo al cloud di vedere identificatori non necessari e residui di flussi di lavoro precedenti.
2. L'utilità è mantenuta astrando i dati sensibili solo al livello necessario per il sottocompito delegato specifico, permettendo al controller locale di risolvere il compito finale utilizzando lo stato privato.
3. La deployabilità è elevata poiché opera come un plug-in sul dispositivo, non richiede modifiche lato cloud e riutilizza il modello del controller locale esistente per la mediazione.

Gli autori notano che la loro valutazione è focalizzata sulle deleghe di ricerca di informazioni nel dominio delle prenotazioni mediche. Riconoscono che, sebbene il design si applichi ampiamente ai payload LC–CLM, sono necessari lavori futuri per gestire span impliciti, apprendere gerarchie di astrazione dinamicamente e affrontare CLM avversari. Il sistema è presentato come un passo pratico verso la sicurezza dei sistemi agentici ibridi contro le fuoriuscite di stato persistente.