AI agents executing crypto payments need strict permission limits, audit trails and controls, not disclaimers, to prevent real financial harm.
Most of the debate about AI in financial services is centered on whether or not it should recommend individual products to buy. Far more interesting to me is when it actually gets to spend money on behalf of a client.
A client asks a chatbot whether they should buy Bitcoin, a tokenized fund or stocks. After delivering a response with confidence, someone attempts to do it, and then much later, there is a heated debate whether the model provided advice or just information.
Of greater interest is when the AI moves from answering queries for the user, to facilitating actual transactions. The AI does not have to state “buy this” to start making a serious financial impact. Grant the AI product the permissions to pay, to swap, to top up a balance, to work within a price bracket, and commentary becomes mandatory.
What actions can the AI take? Which assets will it interact with? What routes will it use? A disclaimer saying your AI is not a financial advisor does not make a bad permission model safe.
The payments industry is already building around this. For example, Visa has been testing out agentic commerce pilots as part of their trusted-agent payment flows. A brief look at how x402 (Coinbase’s AI agent to pay for goods and services in USDC) and Mastercard’s Agent Pay for Machines (API enabled credentialing, permissioning and spending limits for automated machine payments) are using software near the point of execution to make payments. These things all sound like software near execution.
For crypto, there are more reasons to be worried about this than for most industries. Traditional finance involves lots of friction when moving money, from bank rails to permissions, account management and even time of settlement.
Crypto removes most of the friction involved in a transaction. So a transaction can be signed, and then forwarded, swapped, bridged etc., all within software. Many of these steps would normally require user intervention but instead are done by an AI agent.
A crypto-movable AI agent can cause great harm while still complying with its ‘authorization’ even if it only follows a very general instruction. It could proceed along a route that the user would not have authorized were they to find out, switch to a wrong asset or just repeat a series of actions. “Technically authorized” in finance does not equal “client has understood what is happening”. A functional permission layer for real money is lots of fine grained configuration to get right: limits, windows, amounts, categories. Can an AI do a swap? If it can do a swap then can it do cross-chain swaps? If it can pay then can it choose the settlement asset for that payment? While it can rebalance and optimize fees, can it also sell during volatility and will it hold off on executing a trade that the user needs right away?
Products offering access to Crypto markets already face similar challenges. The intent of a user arriving at a product to buy/sell crypto, for example, can require management of multiple aspects such as the required levels of liquidity, fees and various risk checks. In addition to the users not being present when a decision is made by an AI system, the scope of product responsibility changes when a user has delegated future actions. The user needs to be able to see what they have approved and the limits of this approval.
Businesses will care even more about the controls needed to manage the money that is moved around by the AI agent than retail users care about being able to set up and manage accounts and make trades using the AI agent.
No corporation will ever allow an operational amount of money to be moved by an AI demo which looks smart. This“agent” will require controls, audit trails, expenditure rules, clear settlement processes and a means to cease activity whilst not bringing the rest of the process to a grinding halt.
This permission structure will need controls, an audit trail, expenditure limits, clear payment limits and the ability to cancel in flight without affecting the rest of the workflow. Although the agent may be independent it is likely that the business will want to know who is responsible for what.
I imagine that many of the companies that offer AI-powered “agents” to manage payments will go out of business rather quickly as a “bubble” bursts. If I granted one app permission to pay my suppliers and then the supplier’s provider laid off all their staff and shut down service would I like to know whether or not I will have to pay the invoice(s) and potentially pay again for them myself? Allow takeover without waiting for the support team to respond (which may never come).
