Sintesi Tecnica: Ghost Tool Calls: Privacy al Momento dell'Emissione per Strumenti di Agenti Speculativi

1. Definizione del Problema

Gli agenti linguistici aumentati da strumenti utilizzano sempre più la esecuzione speculativa per ridurre la latenza. In questo paradigma, un runtime di un agente predice probabili chiamate future agli strumenti e le distribuisce in parallelo mentre il pianificatore sta ancora decidendo quale ramo di esecuzione impegnare (commit). Sebbene ciò migliori le prestazioni, introduce un nuovo modello di fallimento della privacy che gli autori denominano Ghost Tool Calls (Chiamate agli Strumenti Fantasma).

Una ghost tool call è una chiamata speculativa abbandonata che è stata inviata a un osservatore esterno (ad esempio, un fornitore di ricerca, un endpoint API o un monitor di rete) ma che non è mai stata promossa al piano finale e definitivo dell'agente. Poiché queste chiamate vengono emesse prima che l'agente si impegni su un workflow specifico, esse rivelano l'intento inferito dell'utente (argomenti, entità e potenziali azioni di follow-up) ai servizi esterni.

Il problema centrale è temporale: una volta che un osservatore esterno riceve una chiamata speculativa, l'informazione viene conservata nei log del provider, nelle cache o nelle tracce di rete. I meccanismi di privacy standard falliscono nel risolvere questo problema perché:

• La pulizia al momento del commit è inefficace; l'osservatore possiede già i dati.
• Le restrizioni di sola lettura (ad esempio, consentire la speculazione solo per strumenti di sola lettura) non impediscono la fuga di intenti tramite argomenti o endpoint di destinazione.
• Le liste di controllo degli accessi (allow-lists) permettono la chiamata se lo strumento è autorizzato, indipendentamente dal fatto che il ramo venga successivamente abbandonato.

Gli autori sostengono che la privacy per gli agenti speculativi richieda una decisione di policy al momento dell'emissione (issue-time), presa prima che la chiamata lasci il confine del runtime fidato, piuttosto che una decisione al momento del commit.

2. Metodologia e Framework

Il Modice di Traccia (Trace Model)

Gli autori formalizzano il gap di privacy utilizzando un modello di traccia che confronta due sequenze:

• Traccia Emessa ($S$): Il log ordinato di tutti gli eventi di strumenti distribuiti, inclusi quelli speculativi.
• Traccia Impegnata ($C$): La sottosequenza ordinata di eventi che l'agente utilizza infine.
• Ghost Calls: Eventi in $S \setminus C$.
• Esposizione Marginale ($\Delta_i$): La differenza tra ciò che un osservatore $i$ vede nella traccia speculativa ($O_i(S)$) rispetto al controfattuale basato solo sul commit ($O_i(C)$). Rappresenta l'informazione aggiuntiva trapelata esclusivamente a causa della speculazione.

Il modello identifica tre canali di divulgazione:

1. Argomenti: Il payload letterale (ad esempio, query di ricerca).
2. Destinazione: L'endpoint o la collezione accessata (ad esempio, un'API per le ferie HR rispetto a una ricerca generica).
3. Metadati: Tempo, ordine, conteggi dei tentativi (retry) e stati della cache.

Contratti di Privacy per Strumenti Speculativi

Per far rispettare la privacy al confine dell'emissione, il documento propone i Contratti di Privacy per Strumenti Speculativi. Questo è un'astrazione di runtime che tratta l' "osservazione prima del commit" come un effetto di prima classe, distinto dalla mutazione dello stato.

Componenti Chiave:

• Etichette (Labels): Ogni evento speculativo è etichettato con modalità di esecuzione, classe di effetto, classe di osservatore, sensibilità degli argomenti, sensibilità della destinazione e confidenza del ramo.
• Il Monitor: Un componente fidato situato tra il pianificatore e i percorsi di I/O esterni. Esso valuta ogni evento speculativo prima della distribuzione.
• Funzione Decisionale: Il monitor mappa gli eventi in una delle cinque azioni:
  1. ALLOW (Consenti): Distribuisce invariato.
  2. REWRITE (Riscrivi): Trasforma gli argomenti sensibili in equivalenti generici prima della distribuzione.
  3. SHADOW (Ombra): Esegue un sostituto locale fidato invece della chiamata esterna; il risultato viene utilizzato se il ramo viene promosso, ma l'osservatore esterno non vede mai la richiesta originale.
  4. DEFER (Differire): Accoda l'evento per una ri-valutazione solo se il ramo viene promosso al piano impegnato.
  5. BLOCK (Blocca): Scarta l'evento interamente.

Invariante di Soundness (Correttezza): Sotto l'assunto di mediazione completa (nessun leak di dati grezzi prima del monitor) e corretta etichettatura, il monitor impedisce a qualsiasi campo proibito di entrare nell'esposizione marginale ($\Delta_i$) dell'osservatore, indipendentemente dal fatto che l'evento venga successivamente impegnato o abbandonato.

3. Contributi Principali

1. Concetto di Ghost Tool Call: La formalizzazione delle chiamate agli strumenti abbandonate come una minaccia alla privacy distinta, distinguendo tra divulgazione al momento dell'emissione (issue-time) e mutazione dello stato al momento del commit.
2. Contratti di Privacy per Strumenti Speculativi: Un'astrazione di runtime con etichette concrete, una pipeline decisionale a cinque azioni e un'invariante di correttezza che tratta l'osservazione pre-commit come un effetto distinto.
3. Valutazione Empirica: Una valutazione completa di 12 policy su tre corpora generati (30 task statici, 150 task accoppiati e 66 task AgentDojo) e uno studio su un provider reale (Brave Search/DuckDuckGo). La valutazione utilizza molteplici modelli avversari (LLM, keyword matching, TF-IDF) per misurare il recupero delle etichette sensibili nascoste.

4. Risultati

La valutazione confronta le policy basandosi sul recupero avversario (la probabilità che un avversario inferisca correttamente un'etichetta sensibile dalla proiezione dell'osservatore) e sul successo del task.

• Conferma della Leakage (Fuga di Dati): Le tracce speculative aumentano significativamente la fuga di dati. In un benchmark a piano statico, i tassi di recupero sono passati da 0,44 (No-Speculation) a 0,97 (Speculazione Naive).
• Inefficacia dei Controlli Post-Hoc: Le policy che agiscono dopo la distribuzione o che si affidano a restrizioni di sola lettura falliscono nel ridurre la fuga di dati:
  • Late-Scrub, ACL e SIA (Speculative Interaction Agents): Queste policy lasciano intatta l'esposizione marginale. SIA, che limita la speculazione agli strumenti di sola lettura, performa in modo altrettanto scarso rispetto al baseline Naive perché le chiamate di sola lettura rivelano comunque l'intento tramite argomenti e destinazioni.
  • Pre-Scrub: La redazione del testo libero degli argomenti prima della distribuzione è insufficiente se i campi strutturati o le destinazioni rimangono invariati.
• Efficacia delle Trasformazioni al Momento dell'Emissione: Solo le policy che trasformano la proiezione prima della distribuzione riducono la fuga di dati:
  • Rewrite (Riscrivi): Parafrasare gli argomenti sensibili in equivalenti generici ha ridotto il recupero a livelli quasi minimi (ad esempio, 0,04 in scenari real-planner).
  • Shadow (Ombra): Instradare le chiamate verso sostituti locali ha ridotto il recupero a 0,00 in diversi benchmark.
  • Gate (Cancello): Differire le chiamate a bassa confidenza fino alla promozione del ramo ha ridotto la fuga di dati, sebbene con un compromesso sull'utilità se la soglia è troppo stretta.
• Segnale Residuo: I principali vettori di fuga sono i campi di argomento strutturati e gli URL di destinazione. Mascherare i nomi degli strumenti o usare la redazione di testo libero non ferma la fuga se la destinazione o gli argomenti strutturati rivelano l'argomento.
• Utilità vs. Privacy: Il successo del task è rimasto elevato nella maggior parte delle policy (0,77–0,83). Shadow e Rewrite hanno ottenuto una fuga di dati quasi nulla con un impatto trascurabile sul successo del task, mentre i filtri post-hoc non hanno offerto alcun beneficio per la privacy.
• Latenza: Il meccanismo di enforcement del contratto non è diventato un collo di bottiglia per la latenza. Nei carichi di lavoro asincroni multi-tool, le policy che preservano la privacy (Rewrite, Gate) hanno mantenuto vantaggi di latenza simili al baseline Naive.

5. Significato e Rivendicazioni

Il documento sostiene che la speculazione crea un fallimento della privacy al momento dell'emissione che non può essere risolto dalle tradizionali autorizzazioni o dalla pulizia al momento del commit. La significatività del lavoro risiede in:

• Spostamento del Confine della Privacy: Spostare il punto decisionale della privacy dal "quando l'agente effettua il commit" al "quando l'agente emette". Gli autori sostengono che una volta che un osservatore possiede una chiamata speculativa, il danno è fatto; pertanto, il runtime deve decidere cosa inviare prima di inviarlo.
• Ridefinizione della Speculazione "Sicura": Il documento dimostra che limitare la speculazione agli strumenti "di sola lettura" (un comune schema di sicurezza) è insufficiente per la privacy, poiché le chiamate di sola lettura rivelano comunque l'intento. La vera privacy richiede la trasformazione o la soppressione della proiezione osservabile.
• Astrazione Pratica: I contratti proposti forniscono un framework concreto e implementabile (Rewrite, Shadow, Defer) che consente ai sistemi di runtime di bilanciare i benefici di latenza della speculazione con i requisiti di privacy senza sacrificare l'utilità del task.

Gli autori concludono che, sebbene la speculazione sia attraente per le prestazioni, essa richiede policy al momento dell'emissione che modifichino o sopprimano attivamente la proiezione dell'argomento o della destinazione della chiamata speculativa per prevenire la fuga dell'intento inferito dell'utente.