
Noisegate: un gateway di privacy differenziale che consente a un agente LLM non attendibile di interrogare dati sensibili tramite MCP (Model Context Protocol), con una garanzia formale che nessun record individuale può trapelare anche se l'agente è malevolo - l'applicazione risiede in codice attendibile al di sotto del modello, validata da una galleria di attacchi eseguibile.
Un agente AI che può studiare dati sensibili senza essere in grado di individuare nessuno singolarmente. Il limite è matematico, è applicato in codice che l'agente non può raggiungere, e il repo include gli attacchi che tentano di infrangerlo.
Una sessione registrata di Claude Desktop (risposte abbreviate; le card dei grafici sono della sessione stessa). Un agente AI suddivide 20 pazienti per diagnosi, e il rumore di ±12 sovrasta ogni bin. Ricordato che non può disattivare il rumore, esaurisce un budget di tre risposte finché il gate restituisce un rifiuto invece di una risposta più silenziosa. Sul censimento di 32.561 righe, una fetta troppo ristretta viene respinta al confine di fiducia, mentre una ripartizione completa per istruzione ritorna pulita su larga scala. Il rifiuto e la reiezione sono l'applicazione reale del gateway dal vivo, riprodotta da python scripts/render_demo_gif.py.
Fai domande su un dataset sensibile in linguaggio naturale. Un LLM compila ogni domanda in una query piccola e vincolata. Un motore di privacy differenziale la esegue sotto un budget di privacy tracciato e restituisce una risposta deliberatamente rumorosa con un intervallo di confidenza dichiarato. Come il suo omonimo audio, il gateway mantiene ogni segnale sotto una soglia impostata al di sotto del livello di rumore: il contributo di qualsiasi singolo individuo viene annegato, mentre il segnale alla scala dell'intero dataset passa quasi intatto.
La parte interessante non è che un LLM possa scrivere query. È che la garanzia di privacy non dipende dalla fiducia nell'LLM. Il modello è una comodità che propone una query. Non applica nulla. Ogni proprietà di privacy è applicata a valle, da componenti che si comporterebbero allo stesso modo se una persona digitasse la query a mano. Questa è la disciplina del confine di fiducia che applicheresti a qualsiasi input non attendibile in un sistema di produzione, applicata qui a un agente AI.
La galleria degli attacchi viene eseguita in-process contro il vero motore DP:```bash pip install -e . python -m attacks.patients_alice # re-identify Alice with privacy off, then watch # the guard, the noise, and the budget defeat it
### 2. Collegare un agente AI
Il gateway viene eseguito come server MCP stdio per Claude Desktop. L'agente diventa l'autore della query non attendibile e riceve solo strumenti strutturati (`count`, `sum`, `average`, `histogram`, `get_budget`) i cui schemi degli argomenti sono generati dalla policy del dataset. Non è necessaria alcuna API key da nessuna parte, perché l'agente che si connette è l'intelligenza.
**[Configurazione e procedura completa →](https://github.com/yashmahajan10/llm-differential-privacy-gateway/blob/main/docs/CLAUDE_DESKTOP.md)**
### 3. L'interfaccia completa in linguaggio naturale
Una demo locale single-tenant. Una API key è necessaria solo per il compilatore NL→query non attendibile:```bash
export ANTHROPIC_API_KEY=... # used only by the untrusted NL→query compiler
docker compose up # brings up the engine, API, and UI
# open http://localhost:8501
Quella superficie HTTP + Streamlit è una demo locale, single-tenant. L'identità proviene da un header X-Identity falsificabile, quindi è pensata per un singolo operatore fidato sulla propria macchina, non per un deployment pubblico (vedi cosa sono e cosa non sono queste superfici). Per la configurazione locale senza Docker, l'esecuzione dei test e i parametri di configurazione, vedi SETUP.md.
Chiunque può dichiarare la privacy. Questo repository distribuisce gli exploit che demolirebbero tale dichiarazione, li esegue contro il proprio motore e fissa i risultati in CI. Il modo più rapido per capire cosa garantisce il gateway è vederlo sconfiggere tre attacchi classici che mettono in crisi i sistemi ingenui che "interrogano un database".
Un attacco per differenza isola una singola persona ponendo due domande aggregate che differiscono esattamente per quella persona.``` Query A: "Total income of all 100 people in department X." → $7,240,000 Query B: "Total income of all people in department X except Alice." → $7,135,000 Attacker computes: A − B = $105,000 ← Alice's exact salary, leaked.
Entrambe le query sono "solo aggregati". Nessuna delle due nomina una singola riga. Eppure insieme espongono un individuo. La galleria (`attacks/differencing.py`) mostra questo attacco **riuscire con la privacy disabilitata**: il valore privato del target viene recuperato esattamente. (Lo sketch sullo stipendio sopra è illustrativo; sui dati reali UCI Adult, "Alice" è l'unica detentrice del massimo capital gain del suo gruppo.) Poi mostra lo stesso attacco **sconfitto una volta attivata la DP**: il rumore calibrato su ciascuna risposta rende inutile la sottrazione, e il budget accountant addebita l'informazione rilasciata attraverso *entrambe* le query invece di trattarle come indipendenti.
### Attacco 2: Inferenza di appartenenza
Un attacco di inferenza di appartenenza determina se uno *specifico individuo* è presente nel dataset. Per molti dataset (uno studio medico, una lista di morosi), questo fatto è di per sé sensibile. Un attaccante con solo accesso alle query cerca di decidere: "questa esatta persona è nei dati?"