AI agents with a wallet: what they can spend, and what stops them

An agentic wallet is a control layer that decides what an AI agent can do with real money — which assets, up to what amount, on which contracts, and what has to happen before anything gets signed. It isn't a place to store keys with a chatbot bolted on. And the risk it manages isn't the one most people expect: on 4 May 2026, an attacker took somewhere between $150,000 and $200,000 out of a wallet linked to an AI agent without stealing a key or exploiting a single line of contract code. They just gave the agent an instruction it believed.

Last updated: August 2026

1. What is an agentic wallet?

An agentic wallet is a wallet architecture that lets an AI agent prepare and execute on-chain actions inside limits you define. The important word is limits — a normal wallet asks whether you approve this transaction; an agentic wallet asks, in advance, what class of transactions this software is allowed to propose at all.

That's a different security question, and it needs a different answer. A normal wallet's threat model assumes a human reads each request. An agent can generate more requests than a human will read carefully, and it can turn one instruction into several actions without being asked to.

The technology underneath

Three pieces make an agentic wallet different from a regular one.

The agent. A language model wrapped in tooling that can read a request in plain language, work out which on-chain action satisfies it, and assemble the transaction. It is software that interprets — which is both the whole point and, as section 4 shows, the whole problem.

The policy layer. The rules that sit between the agent's proposal and the signature: spend caps, contract allowlists, asset and chain scope, session expiry. This is the part that makes it a wallet rather than a script with keys.

The signer, and where the keys sit. Three custody designs show up, and the difference decides what a compromise costs you.

A single private key held by the agent's software is the simplest and the worst — one compromised environment means the whole balance. MPC splits the key into shares held by different parties, so a complete key never exists in any one place and no single compromise is enough. A trusted execution environment (TEE) takes a different route: the key stays whole but sits inside isolated hardware, and the limits are checked there rather than inside the agent's own logic.

TEE and MPC get used interchangeably in marketing and they aren't the same thing. One isolates the key; the other splits it. Both are better than handing an autonomous program a raw private key, which is still what some setups do.

Two modes: prepare-and-approve, or autonomous

"Agent" covers a spectrum, and the two ends behave very differently.

At one end the agent prepares and you approve. Coin98's Cypheus multi-agent system works this way: separate transfer, swap and staking agents turn a plain-language request into a prepared transaction, and you review the summary and hold the Confirm button to execute it. The agent does the assembly; the signature is still a deliberate human act. The AI wallet documentation is explicit about why that matters — a confirmed transfer can't be reversed afterwards, by the agent or by anyone else.

At the other end the agent signs on its own inside pre-set rules, and you find out afterwards. That's the design most agentic wallet infrastructure is built for, and it's where the interesting failures live.

Most products sit somewhere between: a default mode requiring your approval for anything outside your stated rules, and an opt-in mode that trades that approval for speed.

2. What can an agentic wallet do?

Given a plain-language request and a funded wallet, an agent can:

• Send tokens. Turn "send 50 USDC to this address" into a prepared, correctly-formatted transfer on the right chain.
• Swap assets. Route a trade, pick the venue, set slippage, and assemble the transaction — the work you'd otherwise do across a DEX interface.
• Stake and unstake. Enter and exit staking positions, and handle the multi-step sequences those often require.
• Read and explain wallet state. Balances, positions, pending approvals, transaction history — summarised rather than scrolled.
• Run pre-execution checks. Simulate the transaction to show balance changes before it's sent, scan the destination for known threats, and reject transactions flagged as malicious.
• Chain several steps from one instruction. Approve, then swap, then stake — one request becoming a sequence, without asking again between steps.
• Act on a schedule or a trigger, in autonomous mode: rebalance, top up, pay on a recurring basis, react to a price level.
• Pay other agents and services. Machine-to-machine payments, usually small and frequent, are the use case the infrastructure is actually being built for.

The last two are where the capability stops being a convenience and starts being a risk surface, because they remove the human from the loop between the instruction and the money.

How much of this is real today

Agent payments are real and small. Both halves matter.

By March 2026, the leading agent payment protocol had processed more than 35 million transactions on Solana alone. More than 24,000 agents registered under the on-chain agent identity standard in the months after its 29 January 2026 mainnet launch.

Now the other side. Across 2025, total AI agent payment activity was measured at roughly $50 million across about 40,000 on-chain agents — about 0.0001% of stablecoin settlement volume. Millions of transactions, almost all of them tiny, adding up to a rounding error next to what stablecoins actually move.

That combination is the honest picture: the plumbing works and is being used heavily for small machine-to-machine payments, while the economic weight is still ahead of it. It's early enough that security practice and regulatory treatment are both still forming.

3. Limits and controls on an agentic wallet

Five controls do the real work, and the useful question about each one is not what it's called but where it's enforced.

Pair those with the pre-execution checks a good wallet already runs — simulation, destination scanning, malicious-transaction rejection — and the agent is operating inside a fairly small box.

Enforced in code, or asked politely

This is the distinction worth carrying away from the whole topic.

A limit enforced in code sits below the agent. The agent can propose a transaction that breaks the rule, and the infrastructure refuses to sign it. Nothing the agent is told, tricked into, or reasons its way toward changes that. The constraint is structural, not advisory.

A limit expressed in an agent's instructions is a preference, and preferences lose arguments. Anything that can change what the agent believes can change what the agent does.

When you're evaluating any agent product, that's the question: is this cap something the system enforces, or something the model was asked to respect?

One thing agents don't get to skip: an agent moving your tokens still needs token approvals like any other contract, and those approvals outlive the session that created them.

4. How an agentic wallet gets exploited

The characteristic attack on an agent isn't a stolen key or a contract bug. It's prompt injection — putting text somewhere the agent will read it, phrased so the agent treats it as an instruction rather than as data.

The reason it works is architectural, not a bug anyone can patch. A language model treats the system prompt, the user's request, and any text pulled in from outside as a single stream of tokens. There's no built-in boundary marking which part came from you. So an agent that reads a webpage, a message, or another agent's output is reading all of it with the same authority it gives your own instructions.

That's why prompt injection maps to six of the ten categories in the 2026 OWASP Top 10 for Agentic Applications. It isn't one risk among many; it's the shape most of the others take.

The Grok drain, step by step

On 4 May 2026, an attacker drained between $150,000 and $200,000 — three billion DRB tokens — from a wallet on Base linked to a public AI agent. The sequence is worth reading slowly, because every step is mundane.

1. The attacker sent an NFT to the wallet. That NFT was a membership token, and in the connected bot's own logic, holding it granted the wallet elevated permissions that bypassed its standard transfer limits. No exploit — the permission system was designed to trust the token.
2. The attacker posted a message on a public social platform encoded in Morse code, and asked a well-known AI agent to translate it.
3. The agent translated it publicly. The decoded text was an instruction to drain the wallet.
4. A second bot read the first agent's output, treated it as an authorised instruction, and executed the transfer.

Security researchers classified it as AI agent permission chain abuse: one AI system's output accepted as trusted financial authorisation by another, with no independent check on where the instruction came from or whether the owner meant it.

Why an audit wouldn't have helped

The incident record makes the point better than a summary can: the exploit relied on how the AI interpreted user input, not on smart contract vulnerabilities.

Every contract involved behaved correctly. The signature was valid. The permission was real. What failed was the assumption that anything reaching the agent as text was a legitimate request — and no amount of contract auditing tests for that, because it isn't a contract problem. It's the same shape as ordinary social engineering, aimed at software instead of a person, and running at software speed.

Two design lessons follow. Permissions attached to assets an attacker can send you are a liability, not a feature — anyone can put a token in your wallet. And an agent's output should never be another agent's authorisation.

5. Considerations and controls when using an agentic wallet

If you want to use an agent today, the setup matters more than the product choice.

• Fund a dedicated wallet. Give the agent its own wallet holding only what you'd accept losing, not the address holding everything else.
• Start with prepare-and-approve. Keep a human confirmation on every action until you've watched the agent handle a few real transactions.
• Set the caps before the first transaction, not after — per transaction and per day, so a fast sequence of small actions can't add up to a large one.
• Check where the caps are enforced. Infrastructure or hardware, not the system prompt. Ask the product directly; the answer tells you what the limit is actually worth.
• Read the summary, not the intent. Check the amount, the asset, the recipient, and the source wallet against what you asked for. A confident explanation is not verification.
• Keep the session short. A permission with an expiry limits how long a compromise stays useful.
• Never grant permissions based on assets you receive. Anyone can send you a token or an NFT; treat nothing that arrives unsolicited as an authorisation.
• Check afterwards, on a schedule. Wallet Health and the approval review show what's still live, and revoking what you no longer need closes doors the agent left open.

FAQ

Does an AI agent need my seed phrase? No, and we'd strongly recommend against any product that asks for one. Agent setups use a dedicated key held in isolated hardware, a key split into shares so no complete copy exists, or a session-limited permission granted by your existing wallet. A service asking for your seed phrase is asking for permanent, unlimited, unrevocable control of every wallet derived from it.

Can an agent send my money without asking me? That depends on the mode you chose. In a prepare-and-approve setup, no — the agent assembles the transaction and you sign it, which is how Coin98's Cypheus agents work. In an autonomous setup, yes, within the caps and allowlists you configured. The important question isn't whether it asks, it's whether those caps are enforced by the infrastructure or merely written into the agent's instructions.

What is prompt injection? It's text placed where an AI agent will read it, written so the agent treats it as a command rather than as content. It can arrive in a webpage the agent browses, a message it's asked to process, a token name, or another agent's output. It works because a model reads your instructions and outside text as one continuous stream, with no built-in marker separating them.

Would a smart contract audit have prevented the Grok drain? No. Every contract involved worked as written and the signature was valid. The failure was that an agent accepted a translated public message as a spending instruction. Contract audits test code against its specification; they can't test whether an agent should have believed what it read.

How do I turn an agent off? End the session or revoke its permission in your wallet, then check what's still live. Disconnecting an app or ending a session stops new actions but doesn't cancel token approvals already granted — those need revoking separately. If the agent held its own key, move the remaining funds out of that wallet rather than assuming the key is now idle.

The takeaway

Agentic wallets move the security question from "is this signature safe" to "what is this software allowed to do at all." Caps, allowlists, session expiry and a human confirmation are the answer, and the one that matters most is whether those limits are enforced below the agent or merely described to it. Coin98's Cypheus agents sit deliberately at the cautious end — they prepare the transaction, run fraud and threat checks, and still make you review the summary and hold to confirm before anything moves.