Le mode paranoïaque de Vitalik Buterin met à l’épreuve la promesse de confidentialité de l’IA sur Ethereum

Vitalik Buterin a placé son agent d’IA derrière quatre couches de confidentialité, tout en reconnaissant que cette configuration expérimentale reste plus lente et vulnérable à l’analyse du trafic. Le mode paranoïaque de Vitalik Buterin combine le routage Tor, le trafic de couverture, les paiements anonymes et la réécriture locale des prompts. Il vise à empêcher un fournisseur d’IA d’associer facilement une conversation à la personne qui l’a initiée.

Le prototype arrive deux semaines après le lancement de zkAPI sur le réseau principal Ethereum par l’Ethereum Foundation et l’Open Anonymity Project. Ce système dissocie les paiements d’API facturés à l’usage de l’identité de facturation d’un utilisateur grâce à des preuves à divulgation nulle de connaissance. Le wrapper de Buterin tente de traiter les informations que la confidentialité des paiements ne peut à elle seule masquer, notamment les adresses réseau, les schémas temporels et les habitudes d’écriture reconnaissables.

Cette distinction compte pour les institutions qui envisagent des agents autonomes pour la finance, la recherche ou les opérations internes. Ethereum peut fournir un mécanisme de paiement privé, mais ne peut pas faire oublier à un modèle externe le prompt qu’il doit traiter. L’expérience teste donc une proposition plus exigeante : plusieurs protections incomplètes peuvent-elles former un environnement d’exploitation suffisamment privé pour des agents d’IA utiles ?

Le mode paranoïaque de Vitalik Buterin ajoute quatre couches de confidentialité

L’expérience de Buterin considère la confidentialité de l’IA comme une chaîne de fuites distinctes, plutôt que comme un unique problème de chiffrement.

Le 16 octobre 2026, Buterin a décrit un daemon compatible avec OpenAI, construit autour de son harnais personnel d’agent d’IA. Un daemon est un programme d’arrière-plan qui gère les requêtes entre l’agent et les fournisseurs de modèles externes.

La configuration attribue un circuit Tor distinct à chaque conversation. Tor fait transiter le trafic par plusieurs relais, empêchant la destination de voir directement l’adresse internet d’origine de l’utilisateur.

Chaque conversation conserve son circuit attribué tant que la session reste active. Une nouvelle session reçoit un circuit différent et une nouvelle autorisation de paiement. Cette conception limite les liens évidents entre des conversations distinctes sans imposer le coût de performance à chaque message.

Buterin mélange aussi les requêtes authentiques avec du trafic de couverture aléatoire. Le trafic de couverture consiste en des communications leurres envoyées pour rendre l’activité réelle plus difficile à identifier par un observateur. Cette approche masque les pics évidents de requêtes lors d’une surveillance passive, même si elle ne neutralise pas toutes les formes d’analyse temporelle.

Un modèle de langage local réécrit les prompts avant qu’ils ne quittent l’ordinateur de l’utilisateur. Cette étape vise à éliminer les empreintes stylistiques, les expressions récurrentes et d’autres schémas linguistiques susceptibles d’identifier l’auteur.

Le modèle local ne rend pas le contenu du prompt invisible. Il en modifie la présentation tout en préservant suffisamment de sens pour que le modèle distant puisse répondre. Des noms, documents, détails de transaction ou faits inhabituels peuvent toujours révéler l’utilisateur.

Buterin exécute ensuite l’agent dans une sandbox bubblewrap. Une sandbox limite les fichiers, appareils et ressources réseau auxquels un programme peut accéder. Les appels réseau passent par torsocks, qui dirige les connexions prises en charge vers le réseau Tor.

La couche de paiement repose sur zkAPI. Au lieu de présenter une clé API conventionnelle liée à un compte, le logiciel obtient des identifiants de courte durée grâce à des preuves cryptographiques de paiement.

Buterin a testé le système combiné avec une requête portant sur des restaurants végétaliens à Tallinn. La tâche était volontairement ordinaire, mais elle a exercé l’ensemble du parcours, de la réécriture locale à l’inférence distante.

Il a décrit la pile comme « devenant assez utilisable », tout en signalant une latence importante lors du démarrage de nouvelles conversations. Cet aveu définit l’expérience plus précisément que son nom. Le mode paranoïaque est un prototype fonctionnel aux compromis explicites, et non un produit de confidentialité finalisé.

Le code public comporte aussi des avertissements importants. Le dépôt zkAPI décrit sa branche dotée de fonctions de confidentialité comme une version non destinée à la production. Certains manifestes réseau restent non déployés et les éléments de preuve destinés à la production sont incomplets.

Ces réserves font de l’événement davantage qu’une annonce de fonctionnalité. Buterin a élaboré un modèle de menace concret et mis en évidence les défaillances des composants. Le résultat invite à l’examen des organisations qui ont besoin de garanties, d’audits et de responsabilité opérationnelle.

Pourquoi la poussée d’Ethereum en matière de sécurité de l’IA compte aujourd’hui

Les agents d’IA transforment les faiblesses ordinaires de confidentialité en risques opérationnels, car ils combinent contexte sensible, outils externes et pouvoir d’action.

Un chatbot standard reçoit du texte et renvoie du texte. Un agent peut conserver une mémoire, examiner des documents, appeler des API, exécuter du code et interagir avec des comptes financiers. Ces capacités supplémentaires créent des systèmes plus utiles, mais elles élargissent aussi les conséquences d’une fuite d’identité.

Un agent d’investissement peut recevoir des détails de portefeuille, des transactions prévues, des adresses de portefeuille, des questions fiscales et des recherches privées. Un agent d’entreprise pourrait traiter des dossiers clients, du code source, des plans de produits ou des documents juridiques.

Même lorsqu’un fournisseur n’exige pas de vrai nom, plusieurs signaux peuvent reconstruire une identité. Une adresse internet révèle l’origine du réseau. Un moyen de paiement relie l’utilisation à un compte. Le style d’écriture et les faits répétés peuvent relier des sessions distinctes.

Le lancement de zkAPI par l’Ethereum Foundation traite la partie facturation de ce problème. Les utilisateurs déposent des crédits dans un coffre Ethereum et reçoivent une note privée représentant leur solde.

Lorsque le logiciel a besoin d’un accès API, il génère une preuve à divulgation nulle de connaissance. Cette preuve confirme qu’un crédit suffisant existe sans identifier le dépôt initial ni son propriétaire.

Le service émet ensuite une clé de courte durée assortie d’une limite de dépenses. Les prompts transitent vers le fournisseur de modèles, tandis que l’autorisation de paiement emprunte un chemin distinct. Le fournisseur voit le contenu et l’utilisation, mais ne devrait pas recevoir l’identité de facturation du payeur.

La conception actuelle utilise des preuves Groth16 sur la courbe BN254. Les engagements et les nullifiers empêchent les observateurs de relier simplement chaque requête au même solde déposé. Un nullifier est un identifiant à sens unique qui bloque la réutilisation sans révéler le secret sous-jacent.

Cette approche diffère du paiement de chaque requête par une transaction blockchain visible. Les paiements directs on-chain peuvent exposer le calendrier, l’historique du portefeuille et les relations entre services. Ils peuvent aussi ajouter un délai inacceptable à un agent interactif.

zkAPI autorise plutôt une session. Cela réduit le travail répété de preuve et de règlement tout en maintenant une séparation entre le financement et les requêtes individuelles.

Le système s’étend au-delà de l’inférence IA. Son architecture peut prendre en charge d’autres services facturés à l’usage, notamment les appels de données blockchain, la génération de médias, la bande passante ou les tâches machine à machine. L’IA reste le test le plus clair, car les prompts contiennent souvent des informations intimes ou commercialement sensibles.

Les institutions jugeront le système différemment des développeurs individuels. Un prototype peut tolérer une configuration manuelle et des interfaces changeantes. Une banque, un laboratoire de recherche ou une équipe de sécurité d’entreprise a besoin de contrôles stables, de modes de défaillance documentés et d’un examen indépendant.

Ces acheteurs doivent également savoir quelle partie peut observer chaque étape. Le serveur de paiement voit une autorisation valide et l’utilisation totale. Le fournisseur de modèles voit le prompt et la réponse. Ethereum enregistre les dépôts et les retraits, mais pas la conversation elle-même.

Cette séparation peut réduire la collecte concentrée de données. Elle n’élimine pas l’exposition des données. Pour les utilisateurs institutionnels, cette différence détermine si le système prend en charge des charges de travail réglementées ou seulement des expérimentations à moindre risque.

Le calendrier reflète aussi une évolution plus large de la sécurité de l’IA. Les organisations passent de promesses générales de confidentialité à des contrôles techniques qui répartissent la confiance entre les appareils, les systèmes de paiement, les réseaux et les fournisseurs d’inférence.

Le prototype de Buterin accentue cette tendance en demandant si la confidentialité devrait être construite autour de l’agent lui-même. Si l’agent contrôle le routage, la réécriture, le paiement et les autorisations, les utilisateurs dépendent moins des politiques de compte d’un fournisseur.

Les paiements anonymes ne créent pas une IA anonyme

Le compromis central est simple : Ethereum peut masquer qui paie, tandis que le modèle a toujours besoin de suffisamment d’informations pour effectuer le travail demandé.

La conception d’utilisation privée énonce directement cette limite. zkAPI ne fournit pas l’anonymat réseau et n’empêche pas les fuites de confidentialité via le contenu des prompts.

Cette frontière est essentielle. Les preuves à divulgation nulle de connaissance peuvent confirmer un paiement sans exposer une relation de financement. Elles ne peuvent pas empêcher un fournisseur d’inférence de lire le texte soumis au traitement.

La réécriture locale des prompts tente de réduire cette exposition. Un petit modèle peut supprimer les formulations habituelles, remplacer les expressions identifiantes ou généraliser certains détails avant transmission.

Pourtant, la réécriture devient moins utile à mesure qu’un agent reçoit des tâches plus spécifiques. Une demande de résumé d’un document public est facile à assainir. Une demande impliquant un contrat privé, un dossier médical ou un dépôt propriétaire est bien plus difficile.

Supprimer trop de contexte réduit la qualité de la réponse. Préserver le contexte nécessaire peut divulguer précisément les informations que l’utilisateur voulait protéger. Aucune technique de routage ne résout ce conflit entre contenu et utilité.

L’historique des conversations crée une autre faiblesse. Un prompt isolé peut révéler peu de choses, mais une séquence peut former un profil distinct. Des lieux, projets, préférences et vocabulaires récurrents fournissent des points de corrélation entre les sessions.

Des circuits Tor séparés n’empêchent pas la corrélation fondée sur le contenu. Des identifiants de paiement distincts non plus. Ils limitent certains identifiants tout en laissant des identifiants sémantiques à la disposition du fournisseur de modèles.

Les outils de l’agent génèrent eux aussi des informations. Les requêtes de recherche, les documents récupérés, les appels de transaction et les messages d’erreur peuvent révéler l’intention. Un prompt utilisateur réécrit offre peu de protection si un outil envoie ensuite un fichier non modifié.

La sandbox traite une menace différente. Elle limite ce qu’un agent compromis ou mal orienté peut atteindre sur la machine locale. Cette protection importe, car un agent peut suivre des instructions hostiles intégrées à des sites web ou à des documents.

Toutefois, une sandbox n’applique que les autorisations qu’elle reçoit. Si l’agent a légitimement besoin d’accéder à un dossier sensible, le contenu de ce dossier peut toujours entrer dans son contexte de travail.

Un déploiement institutionnel exige donc des limites explicites concernant les données. Les équipes de sécurité doivent définir quels fichiers l’agent peut examiner, quels outils il peut appeler et quelles destinations peuvent recevoir les résultats.

Elles ont également besoin de journaux pour enquêter sur les incidents. Cette exigence peut entrer en conflit avec l’absence de lien entre identité et utilisation. Un système conçu pour effacer les connexions entre l’identité et l’usage peut compliquer la responsabilité interne, à moins que l’audit ne soit géré localement.

La promesse n’est pas l’anonymat complet. C’est la compartimentation, où différentes parties apprennent différentes composantes de la transaction.

Cela peut néanmoins rester précieux. Un fournisseur de modèles peut traiter un prompt sans recevoir un profil de facturation persistant. Un système de paiement peut régler l’utilisation sans consulter la conversation. Un relais réseau peut transmettre le trafic sans connaître les deux extrémités.

Les institutions utilisent déjà des principes de séparation similaires dans la conservation financière et la gestion des accès. Aucun opérateur unique ne devrait posséder chaque identifiant, approbation et enregistrement nécessaires pour abuser d’un système.

Mais l’inférence par IA ajoute un destinataire inévitable. Le modèle distant doit recevoir un contenu utile, à moins que le calcul ne s’effectue localement ou dans du matériel confidentiel. Le mode paranoïaque réduit les métadonnées environnantes, mais il ne supprime pas cette dépendance fondamentale.

Tor et le trafic de couverture laissent une faille temporelle

Le mode paranoïaque augmente le coût de la surveillance, mais le propre modèle de menace de Buterin montre pourquoi un trafic leurre aléatoire ne peut garantir l’impossibilité de lier les activités.

Tor fonctionne efficacement contre de nombreux observateurs passifs. Il dissimule la connexion directe entre un utilisateur et une destination en relayant le trafic à travers plusieurs nœuds.

Le trafic d’IA présente toutefois un schéma reconnaissable. Un utilisateur envoie un prompt, le fournisseur reçoit une requête, puis une réponse revient. Le moment et le volume des paquets peuvent produire des signatures correspondantes, même lorsque le contenu reste chiffré.

Un trafic de couverture aléatoire complique cette corrélation. De fausses requêtes entourent l’activité réelle, donnant à un observateur davantage d’événements possibles à comparer.

Un attaquant actif dispose de plus d’options. Un fournisseur de modèles pourrait intentionnellement retarder ou faire varier le trafic de réponse. Si ce fournisseur coopérait avec un relais d’entrée, les deux parties pourraient rechercher le même schéma manipulé.

Buterin a identifié cette possibilité en évoquant son implémentation. Sa réponse privilégiée à long terme est un mixnet spécialisé avec un trafic de couverture constant.

Un mixnet envoie des messages à travers plusieurs intermédiaires qui retardent, réordonnent et combinent le trafic. Un trafic de couverture constant maintient un flux régulier même lorsque l’utilisateur n’a aucune requête réelle.

Les messages réels remplacent alors les paquets leurres sans modifier le débit de transmission visible. Un observateur voit le même schéma avant, pendant et après l’activité de l’agent.

Cette conception plus robuste comporte des coûts directs. Le trafic constant consomme de la bande passante lorsque l’utilisateur est inactif. Le mélange ajoute de la latence, et des relais répartis mondialement accroissent la complexité opérationnelle.

Le système doit également compter suffisamment d’opérateurs de relais indépendants. Si une organisation contrôle tous les relais d’un chemin sélectionné, elle peut reconstituer une plus grande partie de l’itinéraire.

Les incitations économiques ne résolvent pas automatiquement ce problème. Le staking peut pénaliser des défaillances mesurables, mais il ne peut pas prouver que des opérateurs nominalement distincts n’ont pas un propriétaire commun.

Un projet récemment lancé utilisant le nom Paranoid Mode propose des routes à trois sauts et des relais stakés. Son site web indique qu’il est indépendant de Buterin et de l’Ethereum Foundation. Cette distinction est importante, car l’existence d’une implémentation ne constitue pas une approbation.

Le réseau indépendant illustre également un autre défi : les incitations par token peuvent détourner l’attention de l’évaluation de la sécurité. Les récompenses des relais, les règles de gouvernance et les paramètres de slashing ne remplacent pas une revue cryptographique.

L’analyse des limites de Tor souligne également que les fournisseurs reçoivent toujours des prompts réécrits. La protection du trafic et la protection du contenu doivent donc être évaluées séparément.

La latence demeure le coût le plus visible pour l’utilisateur. Buterin a signalé un démarrage plus lent pour les nouvelles conversations, car chaque session établit un nouvel état réseau et de paiement.

Les organisations pourraient accepter ce délai pour des recherches sensibles ou des transactions à forte valeur. Elles seront moins susceptibles de l’accepter pour des tâches interactives courantes nécessitant des appels d’outils rapides.

Le trafic de couverture soulève une question financière supplémentaire. Les appels de modèle utilisés comme leurres seraient coûteux s’ils atteignaient un fournisseur payant. Les paquets au niveau du réseau sont moins chers, mais ils exigent une infrastructure spécialisée capable de reconnaître et d’écarter les messages de couverture en toute sécurité.

Une conception viable doit déterminer où les leurres se terminent et qui paie leur transport. Elle doit aussi empêcher les relais de prétendre envoyer le trafic requis tout en économisant de la bande passante.

Ces problèmes n’invalident pas le prototype. Ils précisent l’écart entre la réduction des métadonnées évidentes et l’offre d’une garantie d’anonymat défendable.

Cette distinction déterminera si le mode paranoïaque reste une configuration personnelle ou devient une architecture de référence pour l’IA institutionnelle.

L’adoption institutionnelle exige des audits, des contrôles et une responsabilité claire

Les institutions évalueront la pile comme un ensemble de dépendances de sécurité, et non comme une fonctionnalité de confidentialité unique estampillée Ethereum.

La première dépendance est zkAPI lui-même. Son dépôt public qualifie le protocole d’expérimental et avertit que les interfaces peuvent changer avant une version stable.

Les systèmes cryptographiques exigent davantage que du code fonctionnel. Les institutions rechercheront des audits indépendants, des builds reproductibles, une génération de paramètres sécurisée et des réponses claires aux vulnérabilités découvertes.

Le risque lié aux smart contracts demeure également. Les fonds déposés dans un coffre dépendent de la logique du contrat, de la vérification des preuves et des mécanismes de retrait. Un avantage de confidentialité ne compense pas une faille capable de bloquer ou de détourner des actifs.

La deuxième dépendance est le client local. Il gère les éléments du portefeuille, les identifiants de session, la réécriture des prompts et les décisions de routage. Une compromission à ce stade peut contourner toutes les couches de confidentialité en aval.

La distribution logicielle devient donc une partie du modèle de menace. Les utilisateurs doivent vérifier les binaires, les mises à jour, les dépendances et les fichiers de configuration. Les équipes en entreprise exigeront également un déploiement géré et l’application des politiques.

La troisième dépendance est le modèle local utilisé pour la réécriture. Sa sortie doit préserver le sens de la tâche tout en supprimant les identifiants. Il n’existe pas de score simple prouvant qu’il a atteint ces deux objectifs.

Une réécriture peut modifier une formulation contractuelle cruciale ou une contrainte technique. Elle peut également préserver un détail distinctif, car le supprimer rendrait le prompt inutilisable.

Les organisations ont besoin de tests couvrant à la fois la confidentialité et l’exactitude sémantique. Ces évaluations doivent utiliser des charges de travail représentatives plutôt que des exemples génériques de chat.

La quatrième dépendance est le fournisseur du modèle. Le mode paranoïaque réduit l’accès du fournisseur aux métadonnées d’identité et de paiement, mais le fournisseur contrôle toujours l’inférence.

Il peut conserver le contenu conformément à ses paramètres techniques et à ses obligations contractuelles. Il peut aussi modifier les modèles, les systèmes de journalisation ou les contrôles contre les abus d’une manière que le client local ne peut pas vérifier.

L’informatique confidentielle offre une piste de soutien possible. Un environnement d’exécution de confiance isole le code et les données dans du matériel protégé tout en fournissant des preuves sur le logiciel en cours d’exécution.

Toutefois, l’inférence adossée au matériel introduit ses propres fournisseurs, systèmes d’attestation et antécédents de vulnérabilités. Elle déplace la confiance au lieu de l’éliminer.

Les institutions doivent aussi décider comment gérer les demandes légales et les enquêtes internes. Les systèmes de confidentialité conçus pour empêcher la corrélation peuvent compliquer la conformité, l’examen des fraudes et la responsabilité des employés.

Une version pratique pour l’entreprise peut nécessiter une identité contrôlée par l’organisation en dehors du fournisseur. L’employeur pourrait savoir quel employé a initié une session, tandis que le fournisseur du modèle ne recevrait qu’une autorisation non corrélable.

Cette disposition préserverait la gouvernance interne sans donner à l’entreprise d’inférence un profil utilisateur complet. Elle exigerait également une séparation soigneuse entre les journaux d’audit et le contenu des prompts.

Le cadrage initial d’AMBCrypto reliait l’expérience à l’intérêt institutionnel pour Ethereum. Cette conclusion reste spéculative. Buterin n’a annoncé ni produit institutionnel, ni déploiement client, ni changement formel du protocole Ethereum.

Le rapport sur les paiements mainnet confirme que zkAPI est opérationnel, mais le déploiement ne prouve pas l’adoption. Les données d’utilisation, les intégrations de fournisseurs et les revues de sécurité indépendantes fourniront des éléments plus solides.

Les institutions se préoccupent aussi de la continuité. Elles ont besoin d’opérateurs crédibles, de processus de support, d’attentes de niveau de service et de plans de migration. Un prototype open source peut fournir des composants sans offrir ces garanties.

Le cas le plus solide à court terme pourrait concerner les développeurs qui exploitent déjà une infrastructure Ethereum et en comprennent les risques. Ils peuvent tester des paiements API privés sans considérer l’ensemble de la pile comme prêt pour la production.

Les grandes organisations peuvent étudier l’architecture comme un modèle. Séparer l’identité de paiement, l’origine réseau, la préparation des prompts et les autorisations locales. Puis évaluer chaque contrôle face au modèle de menace réel de l’organisation.

Quelle suite pour la confidentialité de l’IA sur Ethereum

Trois signaux montreront si le mode paranoïaque de Vitalik Buterin devient une infrastructure ou demeure une expérience influente.

Le premier signal sera une version de zkAPI examinée de manière indépendante, avec des artefacts de production stables. Les audits devront examiner les contrats de coffre, le système de preuves, le portefeuille client et les parcours de retrait.

Une version stable renforcerait l’idée que le paiement anonyme d’API peut soutenir de vraies applications. Des avertissements persistants concernant des composants non déployés maintiendraient le système dans un usage expérimental.

Le deuxième signal sera l’adoption par des fournisseurs de modèles ou des passerelles API. La couche de paiement devient plus utile lorsque les développeurs peuvent accéder à plusieurs services d’inférence sans reconstruire les intégrations pour chacun.

Le soutien des fournisseurs testerait également si le paiement anonyme peut coexister avec la prévention des abus. Les services ont besoin de limites de débit, de contrôles antifraude et de conformité légale, même lorsqu’ils ne peuvent pas identifier chaque payeur.

Un équilibre fonctionnel soutiendrait l’affirmation plus large de Buterin selon laquelle les API n’exigent pas de comptes liés de façon permanente à une identité. Un rejet par les principaux fournisseurs affaiblirait la portée pratique de l’architecture.

Le troisième signal sera une couche crédible de confidentialité réseau conçue spécifiquement pour le trafic des agents. Elle doit fournir un trafic de couverture constant sans rendre la latence et la bande passante inacceptables.

Cette couche doit aussi disposer d’une diversité indépendante de relais et d’un modèle de sécurité mesurable. Une simple liste de relais tokenisée ne répondrait pas aux questions concernant la concentration des opérateurs ou les attaques actives.

Un développement réussi comblerait la faiblesse réseau la plus importante identifiée par Buterin. Un échec laisserait Tor et le trafic de couverture aléatoire comme des défenses utiles mais incomplètes.

Les lecteurs ne devraient pas considérer l’évolution du marché de l’ETH comme un indicateur de validation. Le prototype n’a aucune relation démontrée avec les revenus du réseau, la demande institutionnelle ou le prix de l’actif.

Les indicateurs significatifs sont techniques et opérationnels. Surveillez les résultats d’audit, les versions stables, les intégrations réelles de fournisseurs et une utilisation soutenue par des développeurs traitant des travaux sensibles.

Pour les créateurs d’IA, la leçon immédiate est architecturale. L’identité fuit par plusieurs canaux ; une seule fonctionnalité de confidentialité ne peut donc pas protéger un agent à elle seule.

Les équipes doivent cartographier ce que le système de paiement, le réseau, le fournisseur, le client local et les outils de l’agent peuvent chacun observer. Elles doivent également conserver une trace consultable des modèles de menace et des décisions dans leur base de connaissances technique.

Le mode paranoïaque de Vitalik Buterin rend ce risque fragmenté visible. Il n’établit pas une IA privée de niveau institutionnel, mais il donne aux équipes de sécurité une pile concrète à mettre à l’épreuve.

La question suivante est de savoir si des examinateurs indépendants et des fournisseurs de services peuvent transformer ses protections par couches en infrastructure fiable. D’ici là, le mode paranoïaque doit être considéré comme une expérience sérieuse aux limites exceptionnellement franches.