La maggior parte degli agenti autonomi in produzione oggi trasmette PII in chiaro direttamente a server di strumenti MCP di terze parti — nomi, e-mail, codici fiscali, dati di pagamento — senza alcuna tokenizzazione e senza alcuna traccia di audit. La soluzione non è un promemoria di policy. È un livello di intercettazione che si colloca tra l'agente e ogni strumento esterno, che tokenizza i dati prima che escano dal tuo perimetro e registra ogni contatto in un registro immutabile. Ecco come lo gestisce VeriSwarm Guard.
La protezione dei PII per gli agenti IA è la pratica di impedire che le informazioni personali identificabili trapelino lungo il percorso dei dati che un agente attraversa — input del prompt, contesto dell'LLM, chiamate a strumenti MCP, servizi di terze parti e risposte in uscita — pur continuando a consentire agli strumenti di svolgere un lavoro utile sui dati. È un sovrainsieme della redazione dell'input dell'LLM: il punto di fuga che danneggia di più in produzione non è l'LLM, è la chiamata allo strumento dopo che l'LLM decide di effettuarla.
Un tipico flusso di lavoro di un agente: un utente fornisce nome, e-mail, telefono e una carta di credito. L'LLM li elabora. L'agente chiama quindi uno strumento — un'API di calendario, un CRM, un processore di pagamenti — e inoltra quei dati in chiaro tramite MCP. La specifica MCP non porta intrinsecamente il contesto utente; il server dello strumento non può distinguere gli utenti né applicare controlli per utente. Ogni categoria di dati — PII, credenziali, dati finanziari — può essere inoltrata all'esterno in un unico flusso di lavoro a velocità macchina, per impostazione predefinita.
Per la meccanica passo-passo per colmare questa lacuna, vedi come prevenire una fuga di dati di un agente IA.
I numeri del 2026 non sono lusinghieri:
La Data Loss Prevention è stata costruita per un mondo in cui gli esseri umani copiavano file e inviavano e-mail. Le chiamate agli strumenti degli agenti infrangono ogni presupposto su cui si basa il DLP:
Un agente può effettuare centinaia di chiamate agli strumenti al minuto. L'ispezione DLP tradizionale non riesce a starci dietro senza diventare un collo di bottiglia che vanifica lo scopo dell'automazione.
Le policy DLP classificano i dati a riposo o in transito attraverso canali noti. Le chiamate agli strumenti MCP sono dinamiche, programmatiche e passano per endpoint che il team di sicurezza potrebbe non sapere che esistono.
Il pattern-matching individua formati noti (numeri di carta, codici fiscali) ma si lascia sfuggire i PII dipendenti dal contesto, come condizioni mediche o identificatori suddivisi tra più token. È lì che serve il NER su dati strutturati.
L'architettura che funziona è un livello di intercettazione a runtime tra l'agente e i suoi strumenti. Guard Proxy si colloca in quella posizione. Presidio (il motore NER open source di Microsoft) rileva e tokenizza le categorie di PII — nomi, e-mail, numeri di telefono, codici fiscali, carte di credito, indirizzi IP e numeri di identificazione finanziaria o governativa (conti bancari, patenti di guida, passaporti) — prima che la chiamata allo strumento lasci il perimetro. Il server dello strumento vede [PERSON_1] invece di «Jane Smith». L'LLM ragiona sul token. Il valore originale viene ripristinato solo nella risposta finale all'utente autorizzato. Non è una scansione a posteriori; è una trasformazione inline.
La pipeline di trasformatori esegue quattro trasformatori integrati in un ordine fisso — prima la tokenizzazione dei PII, poi l'iniezione di contesto, il mascheramento dei campi e la convalida dello schema. La ripartizione completa di ciò che fa ciascuno, cosa lo attiva e come aggiungere trasformatori personalizzati si trova in I quattro trasformatori di Guard Proxy: cosa intercetta ciascuno, in ordine.
Tre modalità di distribuzione (in cloud, Docker on-prem, stdio locale) coprono l'intera gamma, da «punta il tuo agente verso un URL» a «i dati non lasciano mai la tua VPC».
La tokenizzazione è pseudonimizzazione, non anonimizzazione. Ai sensi dell'articolo 4(5) del GDPR, i dati pseudonimizzati restano dati personali — il token più la tabella di corrispondenza possono comunque reidentificare l'individuo, e più campi tokenizzati possono essere combinati per rivelare l'identità anche senza la tabella di corrispondenza. Ciò significa che un payload tokenizzato da Guard resta comunque nell'ambito del GDPR; sposta solo i controlli richiesti.
In pratica, la tokenizzazione riduce il raggio d'impatto di un'esposizione e dimostra i controlli «allo stato dell'arte» richiesti dall'articolo 32 — ma non elimina i diritti dell'interessato, gli obblighi di notifica delle violazioni o i requisiti del registro dei trattamenti. Un fornitore che afferma che la tokenizzazione rende i PII «non più dati personali» si sbaglia oppure ti sta vendendo qualcosa. Noi no.
Ogni intercettazione di PII viene registrata nel registro concatenato tramite hash di Vault — cosa è stato inviato, cosa è stato tokenizzato, cosa è stato restituito, quando, con quale identità dell'agente, contro quale strumento. Quando un revisore chiede «dove sono finiti i dati di questo cliente?», la risposta è una cronologia verificabile crittograficamente, non uno screenshot di uno strumento di monitoraggio. La verifica della catena rileva le manomissioni; le esportazioni si mappano direttamente sui requisiti del registro dei trattamenti dell'articolo 30 del GDPR.
Il runbook per il giorno in cui la verifica della catena fallisce — l'endpoint, la forma della risposta, i passaggi di indagine — si trova in Verificare una catena Vault: un runbook per il giorno in cui l'integrità si rompe.
Il settore sanitario è il caso d'uso più esigente per la protezione dei PII al confine tra agente e strumento. Il quadro delle sanzioni dell'OCR del 2025 mostra che i rilievi di Risk Analysis dominano gli accordi con un rapporto di 3:1, con multe medie di circa 291.000 $, più obblighi di monitoraggio di 2 anni. La tokenizzazione di Guard, il registro di Vault e il ciclo di scoring a livello di agente si combinano in una postura che regge quell'audit — integrata nella superficie verticale sanitaria con impostazioni predefinite allineate alla HIPAA attivate di default.
Token. Guard Proxy tokenizza i PII al confine di intercettazione — nomi, e-mail, numeri di telefono, codici fiscali, carte di credito, indirizzi IP, numeri di identificazione finanziaria e governativa (conti bancari, patenti di guida, passaporti) — e l'LLM ragiona sul token. I server degli strumenti ricevono il token. Il valore originale viene ripristinato solo nella risposta finale all'utente autorizzato; nulla a valle vede il testo in chiaro.
La mappa risiede all'interno della distribuzione Guard Proxy del tenant e non viene mai inviata sulla rete insieme al payload tokenizzato. In modalità cloud è protetta da crittografia specifica del tenant; in modalità Docker on-prem non lascia mai la tua rete. Il formato del token è reversibile solo con quella chiave, quindi una chiamata allo strumento intercettata rivela il token, non il valore che rappresenta.
È uno dei controlli. La tokenizzazione al confine della chiamata allo strumento tiene la PHI fuori dal contesto dell'LLM, fuori dai server di strumenti MCP che non controlli, e la porta nel registro concatenato tramite hash di Vault in modo che il registro del flusso di dati resista a un audit. La postura HIPAA completa richiede anche BAA con i server di strumenti a valle, manifesti firmati sugli agenti stessi (Passport) e processi operativi attorno alla risposta alle violazioni. La tokenizzazione a runtime chiude la lacuna tecnica più grande; il resto è burocrazia e operatività.
La redazione distrugge il valore (irreversibile) — va bene per telemetria e log, inutile quando lo strumento ha bisogno del dato per funzionare. Il mascheramento oscura parzialmente (ultime 4 cifre di una carta) — buono per superfici leggibili dall'uomo. Il blocco impedisce del tutto la chiamata — giusto per violazioni gravi della policy. La tokenizzazione preserva l'utilità rimuovendo il segreto — l'unica delle quattro in cui il server dello strumento può ancora svolgere un lavoro utile senza vedere il valore originale. Guard supporta tutte e quattro; la scelta è per categoria di dato e per policy.
Sì — è la sua superficie principale. Guard Proxy è un livello di intercettazione MCP trasparente con tre modalità di distribuzione (in cloud, Docker on-prem, stdio locale). Il client MCP del tuo agente punta a Guard Proxy invece che direttamente al server dello strumento; Guard Proxy inoltra la chiamata senza i PII e restituisce la risposta. Nessuna modifica al codice dell'agente.
Sì — lo stesso meccanismo di tokenizzazione copre entrambi. Oltre ai dati personali, il rilevatore riconosce i formati delle credenziali — token GitHub, chiavi OpenAI, chiavi AWS, token Slack, chiavi GCP, chiavi Stripe, JWT e blocchi di chiavi private — e li tokenizza allo stesso modo in cui tokenizza un nome o un codice fiscale. Una chiave API trapelata diretta a una chiamata di strumento viene intercettata prima che lasci il tuo perimetro, non solo un codice fiscale trapelato.
I token scadono dopo un TTL configurabile — un'ora per impostazione predefinita — e sono limitati a un tenant e una sessione specifici, quindi un token generato per una conversazione non può essere riprodotto in un'altra. I valori originali sono crittografati a riposo (crittografia simmetrica Fernet), e ogni reidratazione al testo in chiaro viene registrata per l'audit. Un token che trapela da solo è inutile senza sia la chiave di crittografia sia una sessione attiva e delimitata.
Attraversa l'intera struttura. Il tokenizzatore di Guard percorre in modo ricorsivo ogni dict e lista negli argomenti di una chiamata a uno strumento — e nel corpo della risposta — quindi i PII sepolti in `data.customer.email` o all'interno di un elenco di record vengono tokenizzati come un campo di primo livello. Una versione precedente ispezionava solo il livello superiore, il che lasciava passare senza redazione i PII annidati nelle tipiche forme di payload MCP; quella lacuna è stata chiusa come correzione critica.
Guard Proxy non richiede alcuna modifica al codice del tuo agente. Punta il tuo client MCP verso Guard Proxy invece che verso il server dello strumento; Guard Proxy inoltra la chiamata senza i PII e restituisce la risposta. Il piano gratuito di Gate ti dà prima visibilità sull'inventario e sul flusso di eventi — così puoi vedere il problema prima di attivare la soluzione.