Can You Trust an Eliza Agent With a Wallet in 2026?

The AI-agent sector that Eliza helped invent is having a good year. The tokens grouped in CoinGecko’s AI Agents category are worth roughly $3.94 billion between them, with Venice’s VVV alone accounting for more than a third of that at a $1.29 billion market cap. Autonomous software that holds its own wallet, signs its own transactions and chases yield without a human in the loop is no longer a curiosity; it is a product line, and capital is flowing into it again.

Eliza, the framework that put on-chain agents on the map, is not sharing in the boom. The ELIZAOS token trades near $0.0001626, a market cap of about $1.22 million, ranked below 2,850 on CoinGecko and more than 98% down from its migration-day high. Founder Shaw Walters declared the token dead in August and began winding the foundation down after settling a class action, telling markets there was no treasury left to defend it (CoinDesk).

And yet the code is very much alive. The elizaOS/eliza repository still carries about 19,500 GitHub stars, ships under an MIT license, and describes itself, without irony, as “Your agentic operating system.” The framework that lost its token remains one of the most-forked ways to give a large language model a crypto wallet and let it loose.

That sets up the question that actually matters in late 2026, and it is not whether the framework survives. It clearly has. The question is whether you can trust it with money. An Eliza agent is, at bottom, a program that can move funds on your behalf based on text it reads from the internet. A year of security research, plus a real drain or two, points to an uncomfortable answer: only under tight constraints, and only with amounts you can afford to lose.

The framework that outlived its foundation

The split between Eliza-the-token and Eliza-the-code is old news to anyone who has followed the project, and we have covered the collapse in detail before (see our account of how Eliza’s token died while the framework survived). The short version: the project launched in October 2024 as ai16z, a memecoin-funded AI hedge fund on Solana’s daos.fun launchpad; a shout-out from the real Marc Andreessen pushed it toward a multi-billion-dollar valuation; it peaked around a $2.39 billion market cap in early January 2025 before rebranding to ElizaOS. A 2026 class action from Burwick Law, filed in the Southern District of New York for a Spanish investor, alleged the a16z branding was misleading, that the fund’s autonomy was oversold, and that a token migration steered roughly 40% of supply to insiders. Walters settled by transferring what was left of the foundation’s treasury to holders.

His post-mortem was blunt. “The token is dead. Completely,” he wrote, adding that there was no foundation and no supply coming to save holders. What he did not do was walk away from the software. “I am starting over, since I own the IP, and I am never letting a token come close to Eliza again,” he said, promising to keep building no matter what. The framework, in other words, is now decoupled from the asset that funded it.

Strip away the token and what remains is a general-purpose framework for building autonomous agents in TypeScript. It handles the plumbing every agent needs: a persistent identity, memory, the ability to call external tools and, crucially for this discussion, the ability to hold keys and sign transactions. That last capability is what turns a chatbot into something that can be robbed.

What an Eliza agent is actually made of

To see where an Eliza agent can be attacked, you have to see what it is built from. The framework centers on a runtime, the AgentRuntime, that loads a character file (the agent’s personality, goals and configuration) and then orchestrates a handful of primitives.

Four of them matter. Actions are the things an agent can do: send a token, call a contract, post a message. Providers feed it context: wallet balances, price feeds, the contents of a chat channel, retrieved documents. Evaluators run after a response to extract facts, score outcomes or update state. Services are long-running connections to the outside world, from Discord to an RPC endpoint. Around these sits a plugin system in which everything, from a blockchain integration to a model provider, registers through a single plugin interface, and the catalogue is large and still growing.

Memory is the fifth piece, and the most consequential for security. An Eliza agent does not just react to the current message; it retrieves relevant past interactions and facts from a vector store and folds them into the model’s context. That is what makes an agent feel continuous and competent. It is also, as researchers have shown, an attack surface in its own right.

Read that architecture through a security lens and a pattern jumps out. Every primitive is a channel through which untrusted text reaches a model that can move money. Providers pull in data an attacker might control. Memory persists whatever the agent has learned, including things it was tricked into learning. Actions and plugins map the model’s text output onto privileged operations. The design that makes Eliza flexible is the same design that makes it hard to secure.

The wallet is the trust boundary

Every conversation about agent security eventually collapses to one point: the wallet. An Eliza agent that can only talk is a novelty. An Eliza agent that can sign is a fiduciary, and a fully autonomous one signs without asking.

Crypto users already know this failure mode from hardware wallets, where blind signing (approving a transaction you cannot fully read) is behind a large share of drains. An autonomous agent is blind signing by design: it decides what to sign based on its own reading of the situation, and the situation is text it pulled from a channel, a webpage or its own memory. The discipline crypto spent years teaching humans, verify what you sign, split keys across parties, and add a checkpoint for anything large, maps awkwardly onto software meant to act on its own. The trade-offs are the same ones we walk through for multisig versus MPC custody, except now one of the signers is a language model that can be talked into things.

The plumbing here has improved. Modern agent stacks lean on smart accounts and session keys so an agent can be granted narrow, revocable, time-boxed permissions rather than the run of a raw private key. That is the promise of account abstraction, and it is a genuine mitigation, though as we have argued it also introduces new middlemen and new failure points. A session key that caps an agent at small swaps on one venue is far safer than an agent holding a private key with god-mode. But a cap bounds the damage; it does not prevent the attack.

Prompt injection, or why the model cannot tell instructions from data

The root vulnerability is the oldest one in the large-language-model book, and it has never been properly fixed. A model reads a stream of tokens and cannot reliably tell which are trusted instructions from its operator and which are untrusted data from the outside world. Hide a command inside data the agent is meant to merely read, and the model may follow it. OWASP ranks this prompt injection as the number-one risk for LLM applications, and for an agent with a wallet the consequence is not a rude reply; it is a transfer.

The attacks get creative because the input surface is enormous. A malicious instruction can arrive in a reply on X, in the description of an NFT the agent inspects, in a token’s metadata, in a webpage the agent summarizes, or in a document a user uploads. The agent’s own helpfulness is the weapon: it was built to read the world and act on it, and the world can write back.

Defenses exist, but they are partial. System prompts that beg the model to ignore embedded instructions, classifiers that try to flag injections, and strict separation of tool-calling from free text all raise the bar. None close the gap, because the gap is architectural: instructions and data share a channel. Until models can cryptographically separate the two, prompt injection is a risk to manage, not one to eliminate.

Memory injection is the worse problem

The sharpest research on Eliza specifically comes from Princeton. In a paper titled Real AI Agents with Fake Memories, Atharv Singh Patlan, Peiyao Sheng, S. Ashwin Hebbar, Prateek Mittal and Pramod Viswanath demonstrated a class of attack they call context manipulation, and they chose ElizaOS as the representative Web3 agent framework (arXiv).

The finding that should worry anyone deploying an agent: models are significantly more vulnerable to memory injection than to prompt injection. A prompt injection has to win in the moment; if the agent does not act on the malicious text right away, the attack is over. A memory injection is patient. Feed the agent a poisoned fact that gets written to its long-term store, and it sits there, retrieved and re-injected into the model’s context on future turns, quietly shaping decisions long after the attacker has gone. As Decrypt put it, the agent can be gaslit into losing millions. At the time of the study, agents built on ElizaOS were collectively managing more than $25 million.

To measure the problem the team built CrAIBench, a benchmark of more than 150 realistic blockchain tasks (transfers, trades, bridges, cross-chain interactions) and more than 500 attack cases. Their conclusion cuts against the easy fix: once stored context is corrupted, standard prompt-injection defenses lose much of their bite, because the poison now lives inside the trusted channel. Fine-tuning the model against these attacks helped more than prompt-level guards, but helped is not solved. The paper’s description of the attack surface is worth keeping in mind, because it reads like a list of Eliza’s own primitives: context manipulation exploits unprotected context surfaces, including input channels, memory modules, and external data feeds.

From injection to execution

Injection is bad when it moves money. It is worse when it takes over the host. In May 2026, Microsoft’s security researchers published a study of remote code execution in AI agent frameworks that reframed the whole risk. Their conclusion, in their words: “vulnerabilities in the AI layer are no longer just a content issue and are an execution risk” (Microsoft Security).

The mechanism is the part every Eliza builder should sit with. The models, Microsoft found, mostly behave correctly; the danger is in how frameworks map a model’s untrusted text output onto privileged system tools. When an agent is wired to plugins that can run code, write files or download payloads, a prompt injection stops being a matter of the agent saying something wrong and becomes a matter of the agent doing something catastrophic. The researchers documented concrete flaws, including one (CVE-2026-26030) where unsafe string handling let an attacker slip past a validator into arbitrary code execution, and another (CVE-2026-25592) where a file-download tool with no path checks let injected commands write to a host’s startup folder and break out of its container. The frameworks named were Semantic Kernel, LangChain and CrewAI, not Eliza. But the failure pattern is framework-agnostic, and Eliza’s action-and-plugin design is exactly the kind of model-output-to-privileged-tool mapping the paper warns about.

For a wallet-holding agent, the two risks compound. An attacker who can inject text can try to move funds; an attacker who can escalate to code execution can lift the keys directly and skip the agent’s judgement entirely.

The plugin supply chain nobody budgets for

If the model is one attack surface, the plugin ecosystem is another, and it is the one builders underrate. Eliza’s power comes from its plugins, and the catalogue is large; Walters has put the count above 250, alongside support for the Model Context Protocol that lets agents plug into a still-wider universe of third-party tools. Independent teams run their own registries: Automata Network and Nethermind, an Ethereum client team, both maintain forks of the plugin registry. That serious infrastructure teams take the framework this seriously is a good sign. It is also a reminder that agents routinely load code from many hands.

Every one of those plugins is a dependency you are trusting with, potentially, signing rights. This is a classic software-supply-chain problem, now pointed straight at a wallet. Vitalik Buterin, writing about how to run LLM agents safely, reported that “roughly 15% of the skills we’ve seen contained malicious instructions” (vitalik.eth.limo). A poisoned plugin, or a poisoned update to an honest one, does not need to defeat the model at all; it can simply do the wrong thing when called.

This is where the economics of a dead foundation start to bite, a theme we return to below. Someone has to review plugins, fund audits and pay for the bugs that researchers find. Across the rest of crypto, that job increasingly runs through bug bounties, where the going rate for a serious flaw is now measured in five and six figures on Solana and Move chains. A framework with a live treasury can run that program. A framework whose foundation is winding down cannot, at least not the same way.

A drain in the wild

These are not hypotheticals. The clearest public example of the injection-to-drain pipeline did not involve Eliza, but it involved exactly the attack class the research describes. On 4 May 2026, an attacker drained an agent built on the Grok and Bankr stack by hiding instructions in Morse code inside a reply on X, paired with a gifted NFT that unlocked transfer rights; the agent moved roughly 3 billion units of a token then worth somewhere in the low hundreds of thousands of dollars on Base. The OECD’s AI incident monitor logs it as a prompt-injection case, OWASP LLM01 (OECD.AI). It is the template: untrusted input, a privilege the agent should never have granted, and money out the door.

A second cautionary tale, Step Finance, shows how agent permissions amplify a more ordinary failure. In January 2026 the protocol lost 261,854 SOL, around $27 million, in what turned out to be a compromise of the team’s own devices and keys rather than a language-model failure or a contract bug (CoinDesk). The agentic lesson is in the blast radius: when autonomous components hold broad, poorly isolated permissions, a key compromise anywhere drains everything those permissions can reach. Step wound down the following month.

The autonomy-versus-safety dilemma

Here is the trap. Every effective defense against these attacks reduces the very autonomy that makes an agent worth deploying. Cap an agent’s spending and it cannot seize a real opportunity. Require a human to approve anything above a threshold and you have reinvented the manual trade. Sandbox it aggressively and it loses access to the tools that made it useful. The safest agent is one that cannot do anything, which is to say it is not an agent.

Buterin’s prescription, published in April 2026, leans hard toward containment: “All LLM inference local first. All files hosted locally. Sandbox everything.” He runs models locally himself rather than trusting a remote endpoint, and his 15%-of-skills-are-malicious figure is the reason. The philosophy treats the agent as hostile by default and boxes it in, trading capability for control.

Walters, who built the thing, has been unusually candid about the limits of trusting agents with money. “You probably do not want to give an AI agent a bunch of money and expect it to make you more,” he told a Token2049 audience in 2025. Coming from the founder of the framework that pioneered on-chain agents, that is close to a warning label.

Verifiable compute proves the wrong thing

A large slice of the crypto-AI industry is betting that verifiable compute will make agents trustworthy. The pitch is that you can prove an AI computation ran correctly and privately, using trusted execution environments (secure hardware enclaves), zero-knowledge machine learning, or optimistic fraud proofs. Eliza’s ecosystem plugs into this directly: Automata Network’s attestation plugin uses Intel’s DCAP remote attestation to prove an agent is running the code it claims inside a genuine enclave, and adjacent projects such as Ritual, opML systems and Gensyn are racing to make model execution checkable. The same idea drives the confidential-compute push in decentralized GPU markets like Akash, where the goal is to run a workload on someone else’s hardware without trusting them with your data.

This is real and useful. It is also, for the specific problem in this article, beside the point. Verifiable compute proves that a computation was performed faithfully and, in the enclave case, privately. It does not prove that the computation was a good idea. If a poisoned memory tells the agent that sending funds to an attacker is the correct action, a trusted execution environment will faithfully, verifiably, confidentially execute that transfer. Integrity and confidentiality are not the same as injection-resistance. A perfectly attested agent can still be perfectly fooled.

Who patches a framework whose foundation just died?

Which brings us to the question no one in the sector likes to ask about Eliza: with the foundation winding down and the token worthless, who is on the hook for security?

Open-source software normally leans on a maintaining organization to triage vulnerabilities, ship patches, fund audits and run a bounty. Eliza had that in the Eliza Foundation. It does not anymore. Walters owns the IP and has vowed to keep building, and the community is large. But a founder plus volunteers is a different security posture than a funded foundation, especially for software that signs transactions. Security work is unglamorous, and the unglamorous work is exactly what unfunded projects ship late.

Three groups now share stewardship, and each has different incentives. Walters and Eliza Labs hold the IP and the roadmap, but no token treasury to draw on. Commercial adopters (Nethermind and Automata maintaining registry forks, and firms building products on top of the framework) have a business reason to keep their own deployments patched, though not necessarily to secure the shared core for everyone. And volunteer contributors do what open-source volunteers always do: valuable, uneven, unpaid work. The healthy read is that a 19,500-star project with commercial backers does not simply rot. The cautious read is that no one now owns the pager for a vulnerability that drains other people’s agents.

The comparison with rival frameworks is instructive, less because any of them is safe and more because their support structures differ. When you pick a framework to hold keys, you are also picking a maintenance organization.

The point of the table is not that Eliza is uniquely dangerous. Every framework here inherits the same underlying injection problem, and the two general-purpose ones were the subjects of the RCE research, not Eliza. The point is narrower: Eliza is the one whose funded maintainer just dissolved, and that is a security variable, not a footnote.

Who is liable when an agent is drained

An agent has no legal personhood. It cannot be sued, fined or jailed, and it does not file a tax return. When an Eliza agent signs away someone’s funds, the liability lands on a human or a company: the person who deployed it, the developer who wrote the faulty plugin, the user who funded the wallet, apportioned, when it comes to that, by who actually controlled the failure.

US regulators have been circling the general area without landing on agents specifically. The SEC and CFTC issued a joint interpretation of digital-asset markets in March 2026 that, notably, did not mention AI agents at all. SEC Chair Paul Atkins has framed the agency’s role in the on-chain, AI-driven markets to come as refereeing rather than picking winners; the job, he said, is “to set the rules of play and referee the game, not to pick the winning team.” For now, that leaves the question of who answers for a hacked agent mostly to ordinary law: contract, negligence, and the terms of service of whatever you deployed.

Compliance adds another edge. An agent that makes stablecoin payments is moving value across borders at machine speed, and the anti-money-laundering rules that catch human transfers, chiefly the Travel Rule, do not switch off because the sender is software. As we have written about the FATF grey list as crypto’s real enforcement lever, the pressure flows through the regulated on- and off-ramps, and an autonomous agent is only ever a few hops from one.

A builder’s security checklist

For anyone actually shipping on Eliza, the defensive posture is not mysterious; it is just demanding. The recurring advice from the research and from operators reduces to a few rules.

• Give the agent the narrowest permissions that let it do its job, using session keys and smart-account limits rather than a raw private key.
• Cap spending per transaction and per day, and require a human signature above a threshold you could stand to lose.
• Treat memory as untrusted: validate what gets written to the agent’s long-term store, and keep the ability to inspect and purge it.
• Pin plugin versions, review third-party plugins as if they were signing code (because they are), and prefer first-party or audited integrations.
• Sandbox tool execution and, where feasible, run inference locally, per Buterin’s local-first stance.
• Assume prompt and memory injection will happen, and design so that a successful injection loses a bounded, survivable amount.

None of this makes an agent safe the way a cold wallet is safe. It makes an agent’s inevitable bad day survivable. In 2026 that is the realistic bar.

The verdict

Where Eliza stands as of 30 September 2026, in figures worth keeping next to any trust decision:

So, can you trust an Eliza agent with a wallet? The framework is durable; the token’s death did not touch the code, and the sector it helped create is worth billions. But durable is not the same as trustworthy. The research is clear that the underlying injection problem is unsolved, memory attacks make it worse, plugins widen it, and verifiable compute does not close it. The one genuinely new risk for Eliza specifically is governance: a wallet-holding framework whose funded foundation just dissolved.

The honest answer is the one a careful custody desk would give about any powerful, imperfect tool. Yes, with guardrails: least privilege, hard caps, human checkpoints for anything that matters, audited plugins, and small amounts. No, if the plan is to hand it a treasury and walk away. Walters, who has more reason than anyone to oversell his creation, essentially said as much. The agents are getting better every month. The trust model is not there yet.

Frequently Asked Questions

Is the Eliza framework still maintained after the token died?

Yes. The elizaOS/eliza repository remains active under an MIT license with about 19,500 GitHub stars, and founder Shaw Walters, who owns the intellectual property, has said he will keep developing it. What changed is the funding: the Eliza Foundation is winding down, so security patches and audits now depend on Walters, commercial adopters and volunteers rather than a token-funded treasury.

What is the difference between the ELIZAOS token and the Eliza framework?

They are separate things. ELIZAOS is a Solana-based token that Walters declared dead in August 2026 after settling a class action; it trades near a $1.22 million market cap, more than 98% below its peak. The Eliza framework is open-source software for building AI agents, and its code continues regardless of the token. Framework quality and token price are not linked.

What is memory injection and why is it dangerous for crypto AI agents?

Memory injection is an attack where a malicious statement is written into an agent’s long-term memory, so the agent retrieves and acts on it across many future interactions rather than once. Princeton researchers using ElizaOS as their test case found that models are significantly more vulnerable to memory injection than to ordinary prompt injection, because once the trusted memory channel is corrupted, standard defenses weaken.

Can verifiable compute or a TEE make an AI agent safe?

Not on its own. Trusted execution environments and zero-knowledge proofs can show that a computation ran correctly and privately, but they cannot show that it was the right computation. If a compromised agent decides to send funds to an attacker, a secure enclave will execute that transfer faithfully. Verifiable compute addresses integrity and confidentiality, not the injection problem.

How do you safely deploy an Eliza agent that holds funds?

Use least privilege. Grant the agent narrow, revocable session keys instead of a raw private key, cap spending per transaction and per day, and require human approval above a threshold. Treat memory and plugins as untrusted, pin plugin versions, sandbox tool execution, and only risk amounts you can afford to lose. The aim is to bound the damage from an inevitable attack, not to assume you can prevent one.

Marcus Okafor covers AI and crypto infrastructure for HOGE Wire.