What an AI Agent Crypto Wallet Needs
An AI agent wallet needs to sign payments without a person present while making the worst case survivable. That means non-custodial keys the agent cannot exceed: a scoped session key with a spending cap, allowed assets and recipients, and an expiry, stored in protected storage, with the owner key and top-ups kept out of the agent's reach.
Why agent wallets are different
A person's wallet assumes a person reads each transaction before approving it. An agent's wallet cannot assume that, because the point of the agent is to act without being asked each time.
Three properties of agents make that harder than it sounds.
They read untrusted input. Web pages, API responses, documents, and tool outputs can contain instructions designed to redirect the agent, including instructions to pay someone.
They loop. An agent can repeat an action many times quickly. A mistake that would cost a person one bad payment can cost an agent hundreds before anyone looks.
They run code in shared environments. Dependencies, plugins, and tools run in the same process or machine, and any of them may be able to read what the agent can read.
So the design question is not whether the agent will behave. It is what the most it can lose is when it does not.
Four ways to give an agent a wallet
1. A raw private key in configuration. A funded key stored in an environment variable or file, used directly to sign. Simple, and every failure is total: anything that reads the environment can drain the account, and nothing limits what the agent signs.
2. A custodial wallet API. A provider holds the keys and exposes an API that the agent calls to send funds. The agent never touches a key, and the provider may offer spending controls. The risk moves to the provider's security, availability, and policies, and the API credential itself becomes the thing to protect.
3. Provider-managed key infrastructure. Keys split across parties or held in secure hardware run by a provider, with signing requested through an API. Stronger key protection than a raw key, with trust in the provider's design and operation.
4. A smart account with scoped session keys. The owner holds the account's main authority. The agent receives a session key the account only honours within set limits: amount per transaction and period, specific assets, specific recipients or contracts, and an expiry. The limits are enforced by the account onchain.
Option four is the one where the agent's worst case is defined by the owner in advance rather than by whatever the agent can reach.
The API credential problem
Options two and three replace a private key with an API key or token. If the agent's environment can read that credential, a compromised agent can use it exactly as it could use a key. Spending controls on the provider side help only if they cannot be changed with the same credential.
The properties to require
Non-custodial or explicitly trusted custody. Know who can move funds. If it is a provider, that is a deliberate choice, not a default.
Limits the agent cannot change. Caps, allowlists, and expiry enforced outside the agent's code, ideally by the account itself.
Protected key storage. The session key lives in an operating system keychain or hardware-backed store, released only to the authorised process.
Owner authority kept elsewhere. The key that registers or revokes session keys and refills the float is never available to the agent.
Bounded top-ups. Automatic refills within a period ceiling, with an alert when the ceiling is reached.
Per-payment records. Each payment logged with the key that signed it, the task that caused it, the counterparty, and the amount, so anomalies can be traced and the key revoked.
Fast revocation. One owner action removes a session key. Test it before you need it.
This is the structure CryptoCadet provides on Base: a non-custodial USDC rail where the agent spends from a float bounded by session keys, with custody through the OS keychain. It is built for agents and is not a consumer wallet.
Start on a testnet
Run the agent against a testnet with test USDC and deliberately attack its wallet: feed it an instruction to pay an unknown address, loop a payment, exhaust the float. Confirm that each attempt is stopped by the limits rather than by luck.
Frequently asked questions
- What is an AI agent crypto wallet?
- A wallet that an autonomous agent can use to sign payments without a person approving each one. Because it runs unattended and reads untrusted input, it needs limits the agent cannot change, such as a scoped session key with caps, allowed recipients, and an expiry.
- Is it safe to give an AI agent a private key?
- An unrestricted private key is the riskiest option, because anything able to read the agent's environment can drain the account and nothing limits what the agent signs. A session key scoped by amount, asset, recipient, and expiry caps the loss instead.
- Should an AI agent use a custodial wallet API?
- It can, as a deliberate choice. The agent never touches a key, and the provider may offer controls. The risk moves to the provider's security and availability, and the API credential becomes the thing to protect, since a compromised agent can use it too.
- How do you limit what an AI agent can spend?
- Use a smart account and give the agent a session key that the account only honours within set limits: amount per transaction and per period, specific assets, specific recipients or contracts, and an expiry. Keep the owner key and top-up authority out of the agent's environment.