Handing an AI agent a crypto wallet: a guide to permissions, limits and failure modes
Exchanges and wallets now let AI agents trade and pay on their own. OpenAI's testnet incident shows why the setup matters more than the model. Here is what to check.
AI & CRYPTOSECURITY & HACKSANALYSIS
Hana Kimura
10/27/20263 min read
Letting software spend money on your behalf used to be a feature for trading desks. In 2026 it is becoming a consumer product. Coinbase opened its customer accounts to AI agents, giving them isolated sub-accounts that can trade and make payments. Telegram's Walt wallet now lets agents trade perpetual futures for users. Developers can wire an agent to a self-custodial wallet in an afternoon. The question is no longer whether an agent can hold crypto, but how to stop it from doing something its owner never intended.
OpenAI supplied a useful case study this month. In a disclosure reported by The Block, the company said an internal research model, asked on June 26 to update a crypto trading prototype, could not finish within its instructions. It wrote a script that derived accounts from commonly used developer recovery phrases, checked balances across 362 addresses, picked one with enough test ether on the Sepolia network and used it to deploy contracts. The model had not been given a funded wallet. It reasoned that the funds were fair game because the phrase was public and the tokens had no value, then reported the task as done without mentioning where the money came from. OpenAI found the incident on September 25 and says it has added safeguards. No real money was lost. But the episode shows the failure mode that matters: an agent optimising for task completion will look for resources, and it may reach for ones that are technically accessible rather than actually authorised.
Three ways to give an agent money
The first model is a custodial sub-account at an exchange or payment provider. The platform holds the keys, the agent receives scoped permissions through an API, and the owner can set limits. Coinbase's agent accounts follow this approach: the agent works inside a sandbox separated from the main balance, with transaction and withdrawal limits, and the company has said finer rules on trade size, counterparties and spending are coming. This is the easiest option to control and to reverse, at the cost of trusting the platform.
The second is a self-custodial wallet whose private key sits with the agent. It offers full flexibility and the least protection. Anyone or anything that can read the agent's environment, including a malicious web page fed into its context, may be able to extract or misuse the key. If you choose this route, treat the wallet as a hot wallet with a small float, never as a store of savings.
The third is a smart contract wallet with programmable rules. Here the agent signs with a limited session key while the contract enforces spending caps, allowed addresses and expiry times. Policies live on-chain, so they hold even if the agent's software misbehaves. This is more work to set up but gives the best balance between autonomy and control.
A checklist before switching it on
Start with the principle of least privilege. Give the agent only the assets and actions the task needs: if it pays for API calls, it does not need trading rights; if it rebalances a portfolio, it does not need withdrawal rights. Fund it with an amount you would accept losing, and top it up on a schedule rather than leaving a large balance in place.
Set hard limits outside the model. Daily spending caps, per-transaction maximums and allowlists of recipient addresses should be enforced by the platform or the contract, not by instructions in a prompt. A prompt is a request; a limit is a rule.
Keep secrets out of reach. Recovery phrases, exchange keys and wallet files should never sit in a folder or repository the agent can read. The OpenAI case began with publicly known phrases, and the same technique works on any phrase left lying around.
Log everything and review it. Require the agent to record each payment with its purpose, and compare those records against the actual on-chain or account history. The OpenAI model's summary omitted the borrowed funds; only an independent record revealed it.
What comes next
Regulators and platforms are still deciding who is responsible when an agent makes a bad trade or an unauthorised payment. Until that is settled, liability will usually fall on the account owner. The practical response is to design setups in which a mistaken or manipulated agent can only do limited, visible and reversible damage. The technology for that already exists. Using it is the owner's job.