AI agent payments involve AI proposing payments or transfers on a person's behalf, or directly approving and executing them within granted authority. In February 2026, wallets for agents launched with spending controls and private key isolation (p.32). In Europe, card networks and banks have already carried out real agent payments (p.34).
The question is increasingly which transactions to delegate, rather than whether AI can pay. An agent deceived by instructions hidden in a document can cause an unwanted transaction to be signed without a private key ever being leaked (p.32).
A KCBCA Signals contributor calls for giving agents an identity, spending limits and action records from the start (p.35). This article focuses on payments and transfers, including independent checks immediately before signing (p.33).
This article draws on research contributions in KCBCA Signals Vol.1 Issue 1 (p.32-35).
How far AI agent payments have come
The spread of AI agent payments into shopping is often called agentic commerce. One card network projected that millions of people would shop through AI agents by this year's holiday shopping season. However, the separately developed systems do not connect to each other (p.34).
When money leaves despite secure keys
An attacker hides instructions in an attachment explaining the purpose of a transfer. If the agent reading it skips approval conditions, it may approve a request it should reject. This is indirect prompt injection, in which external material changes the model's behavior (p.32).
If a signing service processes the transaction on that approval alone, an unwanted corporate transaction is signed while the private key remains protected. Checking only key protection is unlikely to reveal this weakness (p.32).
Dividing agent authority
For AI agent payments, first distinguish transactions the agent can approve alone from those requiring human review (p.32).
| What to define | Criteria |
|---|---|
| Permitted scope | Transfers between designated corporate wallets (p.32) |
| Per-transaction and cumulative limits | A maximum amount for each transaction and a cumulative transfer cap over a defined period (p.32) |
| Authorization | Approval by the designated business owner (p.32) |
| Higher limits | Separate approval at a higher level (p.33) |
| Out-of-scope transactions | Reject or refer for independent human review (p.32) |
The transaction system must enforce the defined authority. Expecting the agent to follow instructions in a prompt is insufficient (p.33).
Check outside the agent immediately before signing
Pre-signing checks for AI agent payments compare the recipient, asset, amount and contract behavior against the approved authority. They also examine permissions that allow a third party to withdraw funds later (p.33).
Keeping the check outside the agent's control allows a transaction to be rejected even when the model believes the request is legitimate (p.33).
Human review needs independent information
People reviewing high-risk transactions should not rely only on the agent's explanation. If it rests on manipulated material, the reviewer may also approve the attacker's intended transaction. Present independently verified transaction details and effects, and bind approval to the single transaction actually submitted (p.33).
Before delegating real funds, use deliberately deceptive inputs to test whether repeated transfers exceeding limits are blocked. Rehearse a kill switch that suspends authority and revokes remaining permissions (p.33).
The handoff between blockchains and banks
AI agent payments do not end with the blockchain. More than $300 billion in stablecoins exists, but about 88% of transaction volume consists of trading, bots and arbitrage. Paying rent, suppliers or wages eventually requires banks, with funds generally moving slowly through international payment networks (p.34).
What is presented as 'my account' may actually be a ledger entry within a fintech company's pooled bank account. If that company fails, customers discover whose money it really was (p.35).
The contributor expects the weakness to emerge at the handoff between blockchains and banks, where everyone assumes someone else is guarding it. The recommendation is to assume compromise and establish transfer caps and kill switches for each agent (p.35).
If a shared service is compromised
If a shared service generating transaction requests and verification information is compromised, companies that individually protected their wallets can simultaneously approve harmful transactions. If that service also handles investigation and recovery, the response is obstructed too (p.33).
The contributor proposes identifying shared tools and providers and testing recovery without them, following the Financial Stability Board's (FSB) approach to third-party risk management (p.33).
Checks before adopting AI agent payments
| What to check | Criteria |
|---|---|
| Identity and records | Is each agent identified and its activity recorded? (p.35) |
| Authority and limits | Are there permitted scopes, per-transaction and cumulative limits, and a process for approving increases? (p.32-33) |
| Pre-signing checks | Are recipient, asset, amount and behavior checked outside the agent? (p.33) |
| Human review | Does the reviewer use independent information and approve only that transaction? (p.33) |
| Kill switch | Have suspension of authority and revocation of remaining permissions been rehearsed? (p.33, p.35) |
| Handoff and recovery | Which account actually holds the money, and can recovery proceed without shared services? (p.33, p.35) |
Frequently asked questions
Q1. Does this apply to individuals shopping with AI?
The contributions mainly address companies and exchanges. Their ideas can be adapted into general precautions for personal AI agent payments. Set limits if the service supports them, directly check the recipient and amount on the payment screen, and keep payment records.
Q2. Are transaction limits enough?
Unwanted transactions can be approved within a limit. Independent pre-signing checks, action records and procedures to suspend authority are also needed (p.32-33, p.35).
Q3. Who is responsible when an incident occurs?
The law has not yet answered who bears losses from transactions approved by the protocol, procedures and people alike. One KCBCA Signals contribution recommends defining liability for AI agent actions in contracts and using time locks and circuit breakers for large transfers (p.25). Recovery of stolen assets is covered further in the article on cryptoasset hacking scheduled for October 22.
At a glance
- AI agent payments are already happening, and faulty approvals can move money even when private keys are safe
- Set permitted scope and per-transaction and cumulative limits, with separate approval for increases
- Immediately before signing, check recipient, asset, amount and behavior outside the agent
- Use independent information for human review, and check kill switches and handoffs
The authority defined before delegating AI agent payments sets the boundaries of transactions.
Read KCBCA Signals Vol.1 Issue 1 in full (p.32-35)
References: KCBCA Signals Vol.1 Issue 1; Marc Krisjanous (Founder and Principal Consultant, Zanarc), p.32-33; Carl Ma (Co-founder and CEO, OnyxRails), p.34-35; Heo Wang (lawyer at Wins Law Firm), p.24-25. This article is not investment advice.
