La modalità paranoica di Vitalik Buterin mette alla prova la promessa di privacy AI di Ethereum
Vitalik Buterin ha collocato il suo agente AI dietro quattro livelli di privacy, pur riconoscendo che la configurazione sperimentale resta più lenta e vulnerabile all'analisi del traffico. La modalità paranoica di Vitalik Buterin combina instradamento tramite Tor, traffico di copertura, pagamenti anonimi e riscrittura locale dei prompt. Mira a impedire che un fornitore di AI possa collegare facilmente una conversazione alla persona che l'ha avviata.
Il prototipo arriva due settimane dopo il lancio di zkAPI su Ethereum mainnet da parte della Ethereum Foundation e dell'Open Anonymity Project. Quel sistema separa i pagamenti API a consumo dall'identità di fatturazione dell'utente tramite prove a conoscenza zero. Il wrapper di Buterin cerca di affrontare le informazioni che la sola privacy dei pagamenti non può nascondere, inclusi indirizzi di rete, schemi temporali e abitudini di scrittura riconoscibili.
Questa distinzione conta per le istituzioni che valutano agenti autonomi per la finanza, la ricerca o le operazioni interne. Ethereum può fornire un meccanismo di pagamento privato, ma non può far dimenticare a un modello esterno il prompt che deve elaborare. L'esperimento mette quindi alla prova una proposta più difficile: se varie protezioni incomplete possano formare un ambiente operativo sufficientemente privato per agenti AI utili.
La modalità paranoica di Vitalik Buterin aggiunge quattro livelli di privacy
L'esperimento di Buterin tratta la privacy dell'AI come una catena di fughe di dati distinte, anziché come un singolo problema di crittografia.
Il 16 ottobre 2026, Buterin ha descritto un demone compatibile con OpenAI costruito attorno alla sua infrastruttura personale per agenti AI. Un demone è un programma in background che gestisce le richieste tra l'agente e i fornitori di modelli esterni.
La configurazione assegna un circuito Tor separato a ogni conversazione. Tor instrada il traffico attraverso più relay, impedendo alla destinazione di vedere direttamente l'indirizzo internet originario dell'utente.
Ogni conversazione conserva il circuito assegnato finché la sessione rimane attiva. Una nuova sessione riceve un circuito differente e una nuova autorizzazione di pagamento. Questo design limita i collegamenti diretti tra conversazioni separate senza sostenere il costo prestazionale a ogni messaggio.
Buterin mescola inoltre richieste autentiche con traffico di copertura casuale. Il traffico di copertura consiste in comunicazioni esca inviate per rendere più difficile a un osservatore identificare l'attività reale. L'approccio nasconde evidenti picchi di richieste dal monitoraggio passivo, sebbene non sconfigga ogni forma di analisi temporale.
Un modello linguistico locale riscrive i prompt prima che lascino il computer dell'utente. Questo passaggio cerca di rimuovere impronte stilistiche, espressioni ricorrenti e altri schemi linguistici che potrebbero identificare chi scrive.
Il modello locale non rende invisibile il contenuto del prompt. Ne modifica la presentazione preservando abbastanza significato da consentire al modello remoto di rispondere. Nomi, documenti, dettagli delle transazioni o fatti insoliti possono comunque rivelare l'utente.
Buterin esegue poi l'agente all'interno di una sandbox bubblewrap. Una sandbox limita i file, i dispositivi e le risorse di rete a cui un programma può accedere. Le chiamate di rete passano attraverso torsocks, che instrada le connessioni supportate nella rete Tor.
Il livello di pagamento è fornito da zkAPI. Anziché presentare una chiave API convenzionale collegata a un account, il software ottiene credenziali di breve durata tramite prove crittografiche di pagamento.
Buterin ha testato il sistema combinato con una richiesta di ristoranti vegani a Tallinn. Il compito era intenzionalmente ordinario, ma ha esercitato l'intero percorso dalla riscrittura locale all'inferenza remota.
Ha descritto lo stack come “piuttosto utilizzabile”, pur rilevando una latenza significativa all'avvio di nuove conversazioni. Questa ammissione definisce l'esperimento più accuratamente del nome stesso. La modalità paranoica è un prototipo funzionante con compromessi espliciti, non un prodotto di privacy completo.
Il codice pubblico contiene anche avvertenze importanti. Il repository zkAPI descrive il suo ramo con privacy abilitata come una release non destinata alla produzione. Alcuni manifest di rete restano non distribuiti e il materiale di prova per la produzione è incompleto.
Queste precisazioni rendono l'evento qualcosa di più di un annuncio di funzionalità. Buterin ha assemblato un modello di minaccia concreto e ha esposto i punti in cui i componenti falliscono. Il risultato invita a un esame approfondito da parte delle organizzazioni che necessitano di garanzie, audit e responsabilità operative.
Perché la spinta di Ethereum sulla sicurezza AI conta ora
Gli agenti AI trasformano le normali debolezze della privacy in rischi operativi perché combinano contesto sensibile, strumenti esterni e autorità di agire.
Un chatbot standard riceve testo e restituisce testo. Un agente può mantenere memoria, ispezionare documenti, chiamare API, eseguire codice e interagire con conti finanziari. Queste capacità aggiuntive creano sistemi più utili, ma ampliano anche le conseguenze della fuga di identità.
Un agente di investimento potrebbe ricevere dettagli di portafoglio, operazioni pianificate, indirizzi di wallet, quesiti fiscali e ricerca privata. Un agente aziendale potrebbe elaborare record dei clienti, codice sorgente, piani di prodotto o documenti legali.
Anche quando un fornitore non richiede un nome reale, vari segnali possono ricostruire l'identità. Un indirizzo internet rivela l'origine della rete. Un metodo di pagamento collega l'uso a un account. Lo stile di scrittura e fatti ripetuti possono collegare sessioni separate.
Il lancio di zkAPI della Ethereum Foundation affronta la componente di fatturazione di questo problema. Gli utenti depositano crediti in un vault Ethereum e ricevono una nota privata che rappresenta il loro saldo.
Quando il software necessita di accesso API, genera una prova a conoscenza zero. Questa prova conferma che esiste credito sufficiente senza identificare il deposito originario o il suo proprietario.
Il servizio emette quindi una chiave di breve durata con un limite di spesa ristretto. I prompt viaggiano verso il fornitore del modello, mentre l'autorizzazione di pagamento percorre un percorso separato. Il fornitore vede contenuto e utilizzo, ma non dovrebbe ricevere l'identità di fatturazione del pagatore.
Il design attuale utilizza prove Groth16 sulla curva BN254. Impegni e nullificatori impediscono agli osservatori di collegare semplicemente ogni richiesta allo stesso saldo depositato. Un nullificatore è un identificatore unidirezionale che blocca il riutilizzo senza rivelare il segreto sottostante.
Questo approccio differisce dal pagamento di ogni richiesta tramite una transazione blockchain visibile. I pagamenti diretti on-chain possono esporre tempistiche, cronologia del wallet e relazioni tra servizi. Possono inoltre aggiungere un ritardo inaccettabile a un agente interattivo.
zkAPI autorizza invece una sessione. Ciò riduce il lavoro ripetuto di prova e regolamento, preservando al contempo una separazione tra finanziamento e singole richieste.
Il sistema si estende oltre l'inferenza AI. La sua architettura può supportare altri servizi a consumo, tra cui chiamate di dati blockchain, generazione di contenuti multimediali, larghezza di banda o attività da macchina a macchina. L'AI resta il test più chiaro perché i prompt contengono spesso informazioni intime o commercialmente sensibili.
Le istituzioni giudicheranno il sistema diversamente rispetto agli sviluppatori individuali. Un prototipo può tollerare configurazioni manuali e interfacce in evoluzione. Una banca, un laboratorio di ricerca o un team di sicurezza aziendale necessita di controlli stabili, modalità di guasto documentate e revisione indipendente.
Questi acquirenti devono anche sapere quale parte può osservare ogni fase. Il server di pagamento vede un'autorizzazione valida e l'utilizzo totale. Il fornitore del modello vede il prompt e la risposta. Ethereum registra depositi e prelievi, ma non la conversazione stessa.
Questa separazione può ridurre la raccolta concentrata di dati. Non elimina l'esposizione dei dati. Per gli utenti istituzionali, questa differenza determina se il sistema supporta carichi di lavoro regolamentati o soltanto esperimenti a minor rischio.
La tempistica riflette anche un cambiamento più ampio nella sicurezza dell'AI. Le organizzazioni stanno passando da promesse generiche sulla privacy a controlli tecnici che dividono la fiducia tra dispositivi, sistemi di pagamento, reti e fornitori di inferenza.
Il prototipo di Buterin mette sotto pressione questa tendenza chiedendo se la privacy debba essere costruita attorno all'agente stesso. Se l'agente controlla instradamento, riscrittura, pagamento e autorizzazioni, gli utenti dipendono meno dalle politiche degli account di un fornitore.
I pagamenti anonimi non creano un'AI anonima
Il compromesso centrale è semplice: Ethereum può nascondere chi paga, mentre il modello necessita comunque di informazioni sufficienti per svolgere il lavoro richiesto.
Il design per l'utilizzo privato espone direttamente questa limitazione. zkAPI non fornisce anonimato di rete e non impedisce fughe di privacy attraverso il contenuto dei prompt.
Questo confine è cruciale. Le prove a conoscenza zero possono confermare un pagamento senza esporre una relazione di finanziamento. Non possono impedire a un fornitore di inferenza di leggere il testo inviato per l'elaborazione.
La riscrittura locale dei prompt cerca di ridurre questa esposizione. Un piccolo modello può rimuovere formulazioni abituali, sostituire frasi identificative o generalizzare determinati dettagli prima della trasmissione.
Tuttavia, la riscrittura diventa meno utile man mano che un agente riceve lavoro più specifico. Una richiesta di riassumere un documento pubblico è facile da sanitizzare. Una richiesta che coinvolge un contratto privato, una cartella clinica o un repository proprietario è molto più difficile.
Rimuovere troppo contesto riduce la qualità della risposta. Preservare il contesto necessario può divulgare proprio le informazioni che l'utente voleva proteggere. Nessuna tecnica di instradamento risolve questo conflitto tra contenuto e utilità.
La cronologia delle conversazioni crea un'altra debolezza. Un prompt isolato potrebbe rivelare poco, ma una sequenza può formare un profilo distinto. Luoghi, progetti, preferenze e vocabolario ripetuti forniscono punti di correlazione tra sessioni.
Circuiti Tor separati non impediscono la correlazione basata sul contenuto. Nemmeno credenziali di pagamento separate. Limitano particolari identificatori lasciando al contempo disponibili gli identificatori semantici per il fornitore del modello.
Anche gli strumenti dell'agente generano informazioni. Query di ricerca, documenti recuperati, chiamate di transazione e messaggi di errore possono esporre l'intento. Un prompt utente riscritto offre poca protezione se uno strumento invia in seguito un file non modificato.
La sandbox affronta una minaccia diversa. Limita ciò che un agente compromesso o mal indirizzato può raggiungere sulla macchina locale. Questa protezione conta perché un agente può seguire istruzioni ostili incorporate in siti web o documenti.
Tuttavia, una sandbox applica solo le autorizzazioni che riceve. Se l'agente necessita legittimamente dell'accesso a una cartella sensibile, il contenuto di quella cartella può comunque entrare nel suo contesto operativo.
L'implementazione istituzionale richiede quindi confini espliciti per i dati. I team di sicurezza devono definire quali file l'agente può ispezionare, quali strumenti può chiamare e quali destinazioni possono ricevere output.
Hanno inoltre bisogno di log per le indagini sugli incidenti. Questo requisito può entrare in conflitto con la non collegabilità. Un sistema progettato per cancellare le connessioni tra identità e utilizzo può rendere più difficile la responsabilità interna, a meno che l'auditing non venga gestito localmente.
La promessa non è l'anonimato completo. È la compartimentazione, in cui parti diverse apprendono parti diverse della transazione.
Questo può comunque essere prezioso. Un fornitore di modelli può elaborare un prompt senza ricevere un profilo di fatturazione persistente. Un sistema di pagamento può regolare l'utilizzo senza vedere la conversazione. Un relay di rete può inoltrare il traffico senza conoscere entrambi gli endpoint.
Le istituzioni utilizzano già principi di separazione simili nella custodia finanziaria e nella gestione degli accessi. Nessun singolo operatore dovrebbe possedere ogni credenziale, approvazione e record necessari per abusare di un sistema.
Ma l’inferenza AI aggiunge un destinatario inevitabile. Il modello remoto deve ricevere contenuti utili, a meno che il calcolo non avvenga localmente o all’interno di hardware riservato. La modalità paranoica riduce i metadati circostanti, ma non elimina questa dipendenza fondamentale.
Tor e il traffico di copertura lasciano una lacuna temporale
La modalità paranoica aumenta il costo della sorveglianza, ma il modello di minaccia dello stesso Buterin mostra perché il traffico esca casuale non può garantire l'impossibilità di correlazione.
Tor funziona bene contro molti osservatori passivi. Nasconde la connessione diretta tra un utente e una destinazione inoltrando il traffico attraverso più nodi.
Il traffico AI presenta tuttavia uno schema riconoscibile. Un utente invia un prompt, il provider riceve una richiesta e viene restituita una risposta. Tempistiche e volume dei pacchetti possono creare firme corrispondenti anche quando i contenuti restano crittografati.
Il traffico di copertura casuale rende questa correlazione più difficile. Richieste false circondano l'attività autentica, offrendo a un osservatore più eventi possibili da confrontare.
Un attaccante attivo ha più opzioni. Un provider di modelli potrebbe ritardare o variare intenzionalmente il traffico delle risposte. Se quel provider collaborasse con un relay di ingresso, entrambe le parti potrebbero cercare lo stesso schema manipolato.
Buterin ha individuato questa possibilità discutendo della sua implementazione. La sua soluzione preferita a lungo termine è una mixnet specializzata con traffico di copertura costante.
Una mixnet invia messaggi attraverso più intermediari che ritardano, riordinano e combinano il traffico. Il traffico di copertura costante mantiene un flusso regolare anche quando l'utente non ha richieste autentiche.
I messaggi reali sostituiscono quindi i pacchetti esca senza modificare la velocità di trasmissione visibile. Un osservatore vede lo stesso schema prima, durante e dopo l'attività dell'agente.
Questo design più solido comporta costi diretti. Il traffico costante consuma larghezza di banda mentre l'utente è inattivo. Il mixing aggiunge latenza, e relay distribuiti globalmente aumentano la complessità operativa.
Il sistema necessita inoltre di un numero sufficiente di operatori di relay indipendenti. Se un'unica organizzazione controlla ogni relay in un percorso selezionato, può ricostruire una parte maggiore del tragitto.
Gli incentivi economici non risolvono automaticamente questo problema. Lo staking può penalizzare fallimenti misurabili, ma non può dimostrare che operatori nominalmente separati non abbiano un proprietario comune.
Un progetto lanciato di recente che utilizza il nome Paranoid Mode propone percorsi a tre hop e relay con staking. Il suo sito afferma di essere indipendente da Buterin e dalla Ethereum Foundation. Questa distinzione è importante perché l'esistenza di un'implementazione non costituisce un'approvazione.
La rete indipendente illustra anche un'altra sfida: gli incentivi basati su token possono distrarre dalla valutazione della sicurezza. Ricompense per i relay, regole di governance e parametri di slashing non sostituiscono una revisione crittografica.
L'analisi delle limitazioni di Tor osserva inoltre che i provider ricevono comunque prompt riscritti. La protezione del traffico e quella dei contenuti devono quindi essere valutate separatamente.
La latenza resta il costo più visibile per l'utente. Buterin ha segnalato un avvio più lento per le nuove conversazioni, poiché ogni sessione stabilisce nuovi stati di rete e pagamento.
Le organizzazioni potrebbero accettare tale ritardo per ricerche sensibili o transazioni di alto valore. È meno probabile che lo accettino per attività interattive di routine che richiedono chiamate rapide agli strumenti.
Il traffico di copertura crea un'ulteriore questione finanziaria. Le chiamate al modello usate come esche sarebbero costose se raggiungessero un provider a pagamento. I pacchetti a livello di rete sono più economici, ma richiedono infrastrutture specializzate che riconoscano e scartino in sicurezza i messaggi di copertura.
Un design praticabile deve decidere dove terminano le esche e chi paga il loro trasporto. Deve inoltre impedire ai relay di fingere di inviare il traffico richiesto risparmiando banda.
Questi problemi non invalidano il prototipo. Chiariscono il divario tra ridurre i metadati evidenti e offrire una garanzia di anonimato difendibile.
Questa distinzione determinerà se la modalità paranoica resterà una configurazione personale o diventerà un'architettura di riferimento per l'AI istituzionale.
L'adozione istituzionale richiede audit, controlli e responsabilità chiare
Le istituzioni valuteranno lo stack come un insieme di dipendenze di sicurezza, non come un'unica funzionalità di privacy a marchio Ethereum.
La prima dipendenza è zkAPI stesso. Il suo repository pubblico definisce il protocollo sperimentale e avverte che le interfacce possono cambiare prima di una release stabile.
I sistemi crittografici richiedono più di codice funzionante. Le istituzioni cercheranno audit indipendenti, build riproducibili, generazione sicura dei parametri e risposte chiare alle vulnerabilità individuate.
Resta anche il rischio degli smart contract. I fondi depositati in un vault dipendono dalla logica del contratto, dalla verifica delle prove e dai meccanismi di prelievo. Un vantaggio di privacy non compensa un difetto che può bloccare o indirizzare erroneamente gli asset.
La seconda dipendenza è il client locale. Gestisce il materiale del wallet, le credenziali di sessione, la riscrittura dei prompt e le decisioni di instradamento. Una compromissione in quel punto può aggirare ogni livello di privacy a valle.
La distribuzione del software diventa quindi parte del modello di minaccia. Gli utenti devono verificare binari, aggiornamenti, dipendenze e file di configurazione. I team enterprise richiederanno inoltre distribuzione gestita e applicazione delle policy.
La terza dipendenza è il modello locale utilizzato per la riscrittura. Il suo output deve preservare il significato dell'attività rimuovendo al contempo gli identificatori. Non esiste un punteggio semplice che dimostri il raggiungimento di entrambi gli obiettivi.
Una riscrittura potrebbe modificare una formulazione contrattuale o un vincolo tecnico cruciale. Potrebbe anche conservare un dettaglio distintivo perché rimuoverlo renderebbe il prompt inutilizzabile.
Le organizzazioni necessitano di test che coprano sia la privacy sia l'accuratezza semantica. Tali valutazioni dovrebbero utilizzare carichi di lavoro rappresentativi anziché esempi generici di chat.
La quarta dipendenza è il provider del modello. La modalità paranoica riduce l'accesso del provider ai metadati relativi a identità e pagamento, ma il provider continua a controllare l'inferenza.
Può conservare i contenuti secondo le proprie impostazioni tecniche e obbligazioni contrattuali. Può anche modificare modelli, sistemi di logging o controlli contro gli abusi in modi che il client locale non può verificare.
Il confidential computing offre una possibile strada di supporto. Un ambiente di esecuzione attendibile isola codice e dati all'interno di hardware protetto, fornendo al contempo evidenze sul software in esecuzione.
Tuttavia, l'inferenza supportata da hardware introduce propri fornitori, sistemi di attestazione e una propria cronologia di vulnerabilità. Sposta la fiducia anziché eliminarla.
Le istituzioni devono inoltre decidere come gestire richieste legali e indagini interne. I sistemi di privacy progettati per impedire la correlazione possono complicare conformità, revisione delle frodi e responsabilità dei dipendenti.
Una versione enterprise pratica potrebbe richiedere un'identità controllata dall'organizzazione al di fuori del provider. Il datore di lavoro potrebbe sapere quale dipendente ha avviato una sessione, mentre il provider del modello riceverebbe solo un'autorizzazione non correlabile.
Questa soluzione preserverebbe la governance interna senza fornire alla società di inferenza un profilo utente completo. Richiederebbe inoltre un'attenta separazione tra registri di audit e contenuti dei prompt.
L'impostazione originale di AMBCrypto collegava l'esperimento all'interesse istituzionale per Ethereum. Questa conclusione resta speculativa. Buterin non ha annunciato un prodotto istituzionale, una distribuzione presso clienti o una modifica formale del protocollo Ethereum.
Il rapporto sui pagamenti mainnet conferma che zkAPI è operativo, ma la distribuzione non dimostra l'adozione. Dati di utilizzo, integrazioni con provider e revisioni di sicurezza indipendenti offriranno evidenze più solide.
Le istituzioni tengono conto anche della continuità. Hanno bisogno di operatori credibili, processi di supporto, aspettative sui livelli di servizio e piani di migrazione. Un prototipo open source può fornire componenti senza offrire tali garanzie.
Il caso più solido nel breve termine potrebbe riguardare sviluppatori che già gestiscono infrastrutture Ethereum e ne comprendono i rischi. Possono testare pagamenti API privati senza considerare l'intero stack pronto per la produzione.
Le organizzazioni più grandi possono studiare l'architettura come modello. Separare identità di pagamento, origine di rete, preparazione dei prompt e autorizzazioni locali. Quindi valutare ogni controllo rispetto al modello di minaccia effettivo dell'organizzazione.
Cosa succederà per la privacy AI su Ethereum
Tre segnali mostreranno se la modalità paranoica di Vitalik Buterin sta diventando infrastruttura o resta un esperimento influente.
Il primo segnale è una release zkAPI sottoposta a revisione indipendente, con artefatti di produzione stabili. Gli audit dovrebbero esaminare i contratti del vault, il sistema di prove, il wallet client e i percorsi di prelievo.
Una release stabile rafforzerebbe la tesi secondo cui il pagamento API anonimo può supportare applicazioni reali. Avvisi persistenti su componenti non distribuiti manterrebbero il sistema nell'ambito dell'uso sperimentale.
Il secondo segnale è l'adozione da parte di provider di modelli o gateway API. Il livello di pagamento diventa più utile quando gli sviluppatori possono accedere a diversi servizi di inferenza senza ricostruire le integrazioni per ciascuno di essi.
Il supporto dei provider metterebbe anche alla prova la possibilità che il pagamento anonimo coesista con la prevenzione degli abusi. I servizi necessitano di limiti di frequenza, controlli contro le frodi e conformità legale anche quando non possono identificare ogni pagatore.
Un equilibrio funzionante sosterrebbe l'affermazione più ampia di Buterin secondo cui le API non richiedono account permanentemente collegati all'identità. Il rifiuto da parte dei principali provider indebolirebbe la portata pratica dell'architettura.
Il terzo segnale è un livello di privacy di rete credibile progettato specificamente per il traffico degli agenti. Deve fornire traffico di copertura costante senza rendere latenza e larghezza di banda inaccettabili.
Quel livello necessita anche di una diversità indipendente dei relay e di un modello di sicurezza misurabile. Un semplice elenco di relay tokenizzati non risponderebbe alle domande sulla concentrazione degli operatori o sugli attacchi attivi.
Uno sviluppo riuscito colmerebbe la più importante debolezza di rete individuata da Buterin. Un fallimento lascerebbe Tor e il traffico di copertura casuale come difese utili ma incomplete.
I lettori non dovrebbero considerare il movimento di mercato di ETH una metrica di validazione. Il prototipo non ha alcuna relazione dimostrata con i ricavi della rete, la domanda istituzionale o il prezzo dell'asset.
Gli indicatori significativi sono tecnici e operativi. Osservate i risultati degli audit, le release stabili, le integrazioni reali con i provider e l'uso continuativo da parte di sviluppatori che gestiscono lavoro sensibile.
Per chi sviluppa AI, la lezione immediata è architetturale. L'identità può trapelare attraverso diversi canali, quindi una sola funzionalità di privacy non può proteggere da sola un agente.
I team dovrebbero mappare ciò che il sistema di pagamento, la rete, il provider, il client locale e gli strumenti dell'agente possono osservare ciascuno. Dovrebbero inoltre mantenere un registro ricercabile dei modelli di minaccia e delle decisioni all'interno della loro base di conoscenza tecnica.
La modalità paranoica di Vitalik Buterin rende visibile questo rischio frammentato. Non stabilisce un'AI privata di livello istituzionale, ma offre ai team di sicurezza uno stack concreto da mettere alla prova.
La domanda successiva è se revisori indipendenti e fornitori di servizi possano trasformare le sue protezioni stratificate in infrastruttura affidabile. Fino ad allora, la modalità paranoica dovrebbe essere trattata come un esperimento serio con limitazioni insolitamente esplicite.
