Ethereum co-founder Vitalik Buterin has published a detailed look at his personal AI workflow, arguing that the current wave of cloud-connected AI agents introduces serious security and privacy risks. In the post, he said he fully moved away from cloud AI services in April 2026 and now operates a self-hosted, local-first setup designed around the principles of being self-sovereign, private, and secure.
His broader warning is not aimed at artificial intelligence in general, but at the growing trend of AI agents that can browse the web, call tools, send messages, and potentially interact with financial systems with minimal user oversight. In Buterin’s view, these systems are often being deployed faster than their security assumptions are being tested.
Why Buterin Abandoned Cloud AI
Buterin said his local setup was built as a direct response to what he sees as major failures in the AI agent ecosystem. He pointed to research indicating that about 15% of agent skills or tool plugins contain malicious instructions. He also cited findings from security firm Hiddenlayer, which showed that parsing a single malicious web page could fully compromise an Openclaw instance, enabling it to download and execute shell scripts without the user’s knowledge.
That type of attack model is particularly concerning because AI agents are increasingly being used as intermediaries between users and sensitive systems, including communication tools, research environments, and potentially crypto wallets. For Buterin, this means the security boundary is no longer just the model itself, but the full stack of connected tools and permissions around it.
He framed the issue in broader terms, warning that after years of progress driven by end-to-end encryption and local-first software, the rise of poorly secured AI tooling could push privacy standards sharply backward.
Hardware and Performance of the Local Stack
At the center of Buterin’s current system is a laptop equipped with an Nvidia 5090 GPU with 24 GB of VRAM. Running Alibaba’s open-weight model Qwen3.5:35B through llama-server, he said the machine reaches around 90 tokens per second, a level he considers comfortable for everyday use.
He also tested alternative hardware. An AMD Ryzen AI Max Pro system with 128 GB of unified memory delivered around 51 tokens per second, while the DGX Spark reached about 60 tokens per second. Buterin said the DGX Spark, despite being marketed as a desktop AI supercomputer, was not especially impressive when judged on price relative to throughput, especially compared with a strong laptop GPU setup.
On the software side, he said he migrated from Arch Linux to NixOS, favoring its declarative system configuration model. He uses llama-server as a background daemon that exposes a local port, allowing multiple applications to connect to a self-hosted model endpoint. He added that even tools like Claude Code can be directed toward a local llama-server instance instead of Anthropic’s hosted infrastructure.
Sandboxing as the Core Security Layer
One of the most important parts of Buterin’s design is sandboxing. He uses bubblewrap to spin up isolated environments from any directory with a single command. Processes inside those sandboxes are restricted to explicitly allowed files and tightly controlled network ports. This minimizes the blast radius if a model, plugin, or agent workflow encounters malicious input.
In practice, this means the model is not treated as a trusted operator with broad system access. Instead, the model is boxed into narrowly defined execution environments. That approach reflects a core principle of secure system design: assume components can fail, and restrict what they are allowed to do in advance.
Buterin also open-sourced a messaging daemon on GitHub that wraps around signal-cli and email workflows. The daemon is designed to let the AI read messages independently and send messages back to Buterin himself without requiring approval. However, any outgoing message to a third party must receive explicit human confirmation.
The “Human + LLM 2-of-2” Model
Buterin described this approval structure as a “human + LLM 2-of-2” policy. In other words, the AI system can assist, draft, summarize, and prepare actions, but it cannot independently complete external actions that may have real-world consequences. The human remains an active co-signer for any high-risk output.
He argued that the same logic should apply to Ethereum wallet design. Rather than granting an AI agent unrestricted wallet access, developers should treat the human and the LLM as two separate confirmation factors that catch different classes of failure. A model may spot patterns the user misses, while the user may notice context, intent, or anomalies the model cannot reliably understand.
For teams building AI-connected wallet tools, Buterin recommended limiting autonomous transactions to $100 per day. Any transaction above that threshold, or any transaction whose calldata could potentially leak data, should require explicit human approval. The recommendation reflects his broader theme that autonomy must be bounded, especially where messaging, funds, or identity are involved.
Local Research, Search Privacy, and Offline Knowledge
For research tasks, Buterin compared a local research tool against his own setup based on the pi agent framework paired with SearXNG, a self-hosted privacy-focused metasearch engine. He said the pi plus SearXNG combination produced higher-quality answers in his testing.
To reduce dependence on external queries, he also maintains a local Wikipedia dump of roughly 1 terabyte along with technical documentation. The reasoning is straightforward: even if search results are useful, every external query can become a privacy leak. By moving as much retrieval as possible onto local infrastructure, he reduces both data exposure and reliance on outside services.
He also released a local audio transcription daemon on GitHub. According to his description, the tool can function without a GPU for basic usage, then pass transcript output to an LLM for correction and summarization. This fits with the same design philosophy seen across the rest of his stack: local processing first, with model assistance layered in carefully and under constrained conditions.
A Privacy-Preserving Path for Remote Inference
Buterin did not claim that every AI task can already be handled locally. For workloads where local models remain insufficient, he outlined a more privacy-conscious path for remote inference. He referenced his own ZK-API proposal with researcher Davide, the Openanonymity project, and the use of mixnets to make it harder for servers to correlate sequential requests through IP addresses.
He also mentioned trusted execution environments as a more near-term method of reducing data leakage in remote inference settings. At the same time, he noted that fully homomorphic encryption for private cloud inference is still too slow to be practical today. That distinction matters: he is not arguing that remote inference should never exist, but that privacy-preserving architectures must improve significantly before they can be trusted with sensitive workloads at scale.
Implications for Crypto and AI Infrastructure
For the crypto industry, Buterin’s post lands at a time when AI agents are increasingly being explored for portfolio management, wallet assistance, onchain automation, research, and customer support. His message suggests that the temptation to combine powerful AI systems with direct wallet access or unrestricted communication channels should be resisted unless strict permissioning and human oversight are built in from the start.
That warning is especially relevant for Ethereum-related applications, where account abstraction, smart wallets, and richer automated user experiences are becoming more common. If AI is going to be integrated into those flows, Buterin appears to be arguing that the right model is not full autonomy, but constrained collaboration.
In that sense, his stack is more than a personal workflow reveal. It is a security thesis: keep inference local when possible, isolate execution environments, minimize external calls, and require human confirmation before messages or funds leave the system.
A Starting Point, Not a Finished Blueprint
Buterin closed with an important caveat. He said the setup he shared should be viewed as a starting point, not a finished product or a security blueprint that others can copy blindly. The individual tools, configurations, and workflows may evolve, and reproducing them exactly does not automatically make another user safe.
Still, the post offers a clear direction for developers and power users who are trying to reconcile AI convenience with privacy, operational security, and crypto-native risk management. As AI agents become more capable, Buterin’s argument is that guardrails should become stronger, not weaker.