An AI agent that pays for APIs and services as it works is not simply a piece of software with a credit card attached. It is a system that must solve three distinct infrastructure problems simultaneously: where the signing keys live, how the agent uses them without human involvement, and how payments reach their destination quickly enough to not block the agent's work.
Each of these problems has multiple solutions in 2026, each with different security, operational, and cost trade-offs.
Layer 1: the wallet
A stablecoin wallet is a key pair — a private key and a corresponding public address. The public address is where funds are held on-chain (as a stablecoin balance). The private key is what the agent uses to sign payment transactions or vouchers.
For agentic payments, the wallet must be:
- Programmatically accessible — the agent signs payments autonomously, with no human click to authorize each one.
- Pre-funded — the wallet must hold stablecoins before the agent can pay for anything. Funding is a separate, operator-initiated step.
- Scoped — ideally, the wallet is limited to a specific agent or task, so that a compromised agent key cannot drain the operator's entire treasury.
The simplest implementation is an externally owned account (EOA) — a standard blockchain wallet. The agent holds the private key directly as a secret in its runtime environment. This is straightforward but creates a single point of failure: if the key is exposed, the wallet is fully compromised.
Layer 2: key custody
Key custody is where most of the operational complexity lives. The agent needs to sign transactions autonomously, but the key must be protected.
Three models are in production use by mid-2026:
| Model | How it works | Trade-offs |
|---|---|---|
| Software EOA | Private key stored as an environment secret in the agent's runtime | Simple; single point of compromise |
| MPC wallet | Key split into shares across multiple parties; agent triggers signing via API | No single point of compromise; adds latency per signing call |
| HD derivation | A master seed generates per-agent subkeys via hierarchical deterministic derivation | One seed governs many agents; master seed is still a single point of compromise |
Multi-party computation (MPC) wallets are the model gaining the most infrastructure investment for agent use cases. In an MPC wallet, the private key is never assembled in one place. Each signer holds a key share, and signing requires a threshold of shares to cooperate. Coinbase launched agent-specific MPC wallet infrastructure in early 2026. MoonPay and Ledger have partnered on hardware-grade key storage for agent wallets.
The practical result: the agent calls a signing API to authorize a payment, the MPC network cooperates to produce a valid signature, and the signed transaction goes on-chain — without the agent ever holding the full key.
Spending limits and authorization policies
A funded agent wallet is, from the chain's perspective, as powerful as any other wallet. The blockchain does not enforce spending limits. Those controls must be implemented at the custody layer.
Common patterns:
- Per-transaction limits — the custody layer rejects any signing request above a set value.
- Rolling time-window limits — the agent can spend up to $X per hour or per day before signing requests are paused and the operator is alerted.
- Allowlisted destinations — the agent can only sign payments to a set of approved addresses (known API providers), preventing an exploited agent from sending funds elsewhere.
- Session budgets — in MPP Sessions, the escrow amount is set at session open and cannot be exceeded during the session; this is an on-chain enforcement, not just a software policy.
Layer 3: settlement — finality, cost, and gas
Payment confirmation speed matters for agents because the agent is blocking on the payment before it can proceed. A settlement that takes minutes is a multi-minute stall in the agent's task.
Three properties determine whether a chain is viable for agent payments:
Finality time. Probabilistic finality (where a transaction might theoretically be reversed) is problematic for machine payments. An API server that accepts payment wants assurance the transaction will not be re-organised. Tempo's Simplex BFT consensus provides deterministic finality — once a block is confirmed, it cannot be reversed — in approximately 500 milliseconds.
Per-transaction cost. If each payment costs $0.01 in fees, a pipeline making 1,000 API calls at $0.001 each pays ten times more in fees than in service value. Tempo targets fees under $0.001. On chains like Ethereum mainnet, gas costs during congestion can make micropayments uneconomic.
Gas token requirement. Most blockchains require the sender to hold a separate native token to pay gas — ETH on Ethereum, SOL on Solana. An agent holding only USDC cannot send a transaction on those chains without also holding some native token. Tempo eliminates this: gas is paid in the TIP-20 stablecoin the agent already holds. This removes an entire operational dependency for agent operators.
MPP Sessions as infrastructure
The MPP Sessions mechanism is not just a protocol feature — it is an infrastructure design that changes the cost model for agent payments. Rather than requiring a funded wallet to submit an on-chain transaction per API call, Sessions require:
- One on-chain transaction to open the session (deposit escrow).
- Zero on-chain transactions for intermediate API calls (off-chain signed vouchers).
- One on-chain transaction to settle the session (server submits the final voucher; unused funds return).
From an infrastructure standpoint, this means the agent's on-chain activity scales with the number of tasks, not the number of API calls per task. A task involving 10,000 API calls still produces exactly two on-chain transactions.
Observability: auditing what agents spend
An operator deploying agents that spend stablecoins needs to know what was spent, on what, and when. Blockchains provide an immutable record of the two MPP session transactions and any direct on-chain payments. Off-chain vouchers are not recorded on-chain — the server holds the voucher history and the final settle transaction records the total.
Building a full audit trail requires instrumenting the agent itself (logging each voucher signed) and reconciling against the on-chain settle transaction. This tooling is in active development across the agent payment ecosystem as of mid-2026.
For the protocols that use this infrastructure, see The Machine Payments Protocol (MPP), explained and How AI agents use stablecoins to pay for APIs. For what this infrastructure means for businesses on the receiving side, see Agentic commerce: what it means for businesses.