Your AI Agent Has Your Wallet. Who Stops It From Spending Everything?

By Georgeonweb3👾🧬

First, credit where it's due. @yerbearserker called these things Farticles, and the name stuck. He surfaced the launch too. This is my first one.

The problem is not that agents are dumb

Give an AI agent a wallet and a job, and it will do the job. That is the whole pitch of agentic crypto. It is also the whole risk.

An agent that can sign can spend. There is no "are you sure?" moment, no daily limit, no second pair of eyes. A bad instruction, a poisoned tool result, one compromised plugin, and the wallet drains itself while doing exactly what it was told.

Prompt-level limits don't fix this. Telling an agent "don't spend more than $50" is a suggestion, not a lock. Suggestions fail. Locks don't.

Spending limits have to live before the signature

That is the one idea behind Aegis, the thing I've been building.

A spend control layer for AI agents. You set the limit in advance, per period, per agent. The limit is enforced before anything signs, on chain, not in the agent's head. If the agent tries to go over, the transaction doesn't happen. No appeal, no "but the prompt said so."

It's live as a demo on Base Sepolia right now: georgeonweb3.github.io/aegis-base

The good news: the pieces already exist

I spent a while mapping this space, and the honest answer is that Aegis doesn't invent the idea. It assembles it. The frameworks that do this properly today:

• Safe allowances, spending limits on a Safe
• MetaMask Delegation Framework, scoped permissions
• Coinbase Spend Permissions, audited by Cantina in Dec 2024 and Jan 2025
• Squads v4, Alchemy v2, Zodiac Roles

The pattern is the same in all of them. The permission is the product. The agent never holds the keys, it holds a narrow permission, and the permission has a ceiling.

The honest caveats

Because the details are where this breaks:

• Period edges double-spend. A limit that resets at midnight can be hit twice in a minute, once before the reset and once after.
• Signing is not validation. An approval that looks fine when signed can be stale by the time it executes. Coinbase's own Spend Permissions has this edge: an approval can read as valid after the permission was removed.
• NFT permissions confuse everyone. ERC-721 approvals behave differently from token approvals, and agents mix them up.

I keep a list of these because a spend guard that ignores them is a false sense of security, and a false sense of security is worse than none.

What I'm building next

Aegis stays on Sepolia while the guard gets hardened. Along the way the work has already shipped in pieces: a spend-guard catalog fix merged into the Hermes agent framework, a SpendGuard CLI, and a grant application for the full build. The demo is public, the code is public, and the fastest way to help is to try to break it.

If you run agents with wallets, set a limit before you set them loose. If you build agents, give your users a ceiling, not a promise.

Try the demo. Tell me where it fails. That's the whole point.