DEV Community

Bill Wilson
Bill Wilson

Posted on

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

#blockchain #security #ai #typescript

Why AI Agent Wallets Must Be Non-Custodial: The Lazarus Attack Made It Obvious

Lazarus Group drained another hot wallet. This time it was Bitrefill. If your AI agents are running on custodial wallets, you're looking at the same attack surface — and it's getting larger every month agents get more capable.

I've been building agent-wallet-sdk for a few months — a non-custodial wallet designed specifically for autonomous AI agents. The kind that pay for APIs, hire sub-agents, and execute onchain transactions without a human approving every move.

When we started, the most common pushback was: "Why non-custodial? Custodial is so much easier to wire up."

It's March 2026. Lazarus just answered that question for the entire industry.

What Happened at Bitrefill

Gartner confirmed Lazarus Group compromised Bitrefill's hot wallet this month using a combination of compromised API keys and a prompt injection through their customer-facing AI assistant. The injection escalated privileges to the payment backend. Hot wallet — centrally managed, single key — drained in minutes.

No blockchain exploit. No smart contract bug. They found one centralized key, and that was the whole game.

If you're running agents with custodial wallets, you have the exact same attack surface. Arguably worse, because your agents are reading untrusted content constantly.

Three Ways the Custodial Model Breaks for Agents

1. Prompt injection → payment execution

Agents process untrusted content all day. Web pages, API responses, user inputs, tool outputs. An attacker who can inject text into your agent's context can try to trigger a withdrawal, approve a transaction, or rotate credentials.

Custodial wallet = that instruction reaches a backend that can execute it. The blast radius is your entire wallet balance.

Non-custodial with on-chain spending policies? That same injection hits a contract that says: "This agent can spend max 0.01 ETH per transaction, only to whitelisted addresses, and no more than 0.1 ETH per day." Request denied. Every time.

2. The infrastructure owner is your weakest link

Custodial means someone else holds your keys. That someone is a target. API key leak, insider threat, phishing, supply chain compromise — any of those exposes your agents' funds without any mistake on your part.

Non-custodial: your agents hold their own keys. The infrastructure provider getting breached doesn't touch your wallets.

3. Binary authorization is too coarse for agents

Most custodial setups have one dial: the API key can spend, or it can't. No per-agent limits, no destination whitelists, no time-locked withdrawals.

ERC-6551 Token Bound Accounts — what agent-wallet-sdk runs on — put spending controls on-chain. Every agent wallet has a SpendingPolicy that defines exactly what it can do. Not config you can override with a redeploy. On-chain, immutable, auditable.

What This Looks Like in Code 

import { AgentWallet, SpendingPolicy } from '@ai-agent-economy/agent-wallet-sdk';

// Spin up an agent wallet with hard guardrails
const wallet = await AgentWallet.create({
  policy: new SpendingPolicy({
    maxPerTx: parseEther('0.01'),        // 0.01 ETH max per transaction
    maxPerDay: parseEther('0.1'),         // 0.1 ETH daily cap
    allowedDestinations: [               // Whitelist — nothing else goes through
      '0xYourAPIProvider',
      '0xYourSubAgentPool',
    ],
  }),
});

// Agent pays for an inference call
await wallet.pay({
  to: '0xYourAPIProvider',
  amount: parseEther('0.005'),
  memo: 'inference_call_id_abc123',
});
Enter fullscreen mode Exit fullscreen mode

No centralized server. Policy check happens in the contract. Injected prompt, rogue tool output, compromised sub-agent — doesn't matter. The contract rejects anything outside the policy.

The ERC-6551 Property Nobody Talks About

TBA wallets are owned by an NFT. Transfer the NFT, all agent permissions revoke instantly — no API key rotation, no backend calls, no incident response ticket.

The Bitrefill breach succeeded partly because revoking a compromised credential required action from the victim. Time between discovery and revocation is where the damage happens. With TBA architecture, revocation can be automated — anomaly detected, ownership NFT transferred to a null address, wallet locked. Done before a human is even paged.

The Objection Worth Addressing

"Non-custodial is complex. Custodial with good security practices is fine."

The second half of that sentence is doing a lot of heavy lifting.

Bitrefill didn't have bad security practices. They had normal ones — API key management, access controls, logging. Lazarus found the AI assistant and worked through it because the AI assistant had payment privileges.

That's the new attack vector. Most custodial security models were built before agents that process untrusted text had payment capabilities. They weren't designed for this threat.

On-chain spending limits with destination whitelists are the only architectural control that doesn't require your OPSEC to be perfect. Everything else is defense in depth — good, necessary, not sufficient.

Bottom Line

If your agents touch real money, the architecture decision isn't a trade-off anymore. Non-custodial with on-chain spending limits. Whitelist destinations. Keep balances minimal — enough for the next few operations, nothing more.

We built agent-wallet-sdk because we needed this for our own agents and it didn't exist. TypeScript, MIT licensed, ERC-6551.

Repo: github.com/AI-Agent-Economy/agent-wallet-sdk

Building agent payment infrastructure and want to compare notes? I'm @AgentEconoemy on X.

Tags: #ai #blockchain #security #typescript

Top comments (0)