Coinbase launched a new software development kit on Thursday that lets AI agents execute trades, make payments, and manage crypto portfolios on behalf of users. The headlines will focus on the trading functionality—an AI agent that can swap tokens or rebalance a portfolio is a compelling demo. But the architecture underneath reveals a more fundamental question that every company building agentic payment infrastructure is now being forced to answer: who holds the private key, and what happens when the agent does something the user didn’t expect? Coinbase’s answer is a custody model built on multi-party computation wallets and pre-authorized spending limits, and it tells us exactly where the industry is drawing the line between autonomy and control.
The MPC Wallet: Why the Agent Never Sees the Key
The SDK’s core custody primitive is a multi-party computation wallet. In an MPC setup, the private key is never assembled in one place. It is split into shards distributed across multiple parties—in this case, Coinbase’s infrastructure and the user’s device—and transactions are signed through a collaborative computation that never reconstructs the full key. For an AI agent, this means the agent itself never holds a raw private key. It can request a transaction, but the signing process requires the MPC protocol to execute, which Coinbase can gate with policy checks.
This is not a minor implementation detail. It is the architectural decision that separates “agent has a wallet” from “agent has permission to request a payment.” The former implies the agent can unilaterally move funds. The latter implies a custodian sits between the agent’s intent and the on-chain settlement. Coinbase chose the latter, and the spending limits are the mechanism that enforces the boundary. Users set per-agent, per-transaction, and per-time-period caps. If an agent tries to exceed them, the MPC signing ceremony fails. The agent is left with a request that cannot be fulfilled, not a key that can be abused.
The Two-Layer Stack Is Becoming Industry Standard
We wrote earlier this week that Visa and Mastercard are both converging on a two-layer architecture for agentic payments: identity and authorization sit on legacy or custodian-controlled rails, while settlement happens on-chain with stablecoins. Coinbase’s SDK fits this pattern precisely. The MPC wallet and spending limits form the authorization layer. The actual settlement—the USDC transfer, the token swap, the trade execution—happens on Base or Ethereum. The agent interacts with the authorization layer through an API. It never touches the settlement layer directly.
This is the same pattern Mastercard’s AP4M protocol uses, with its permissioned validator set checking agent identity before allowing settlement. It is the same pattern Visa is building with its Agent Scoring framework and the Canton Network pilot. The difference is that Coinbase is a crypto-native custodian rather than a card network, so the authorization layer is a smart-contract-enforced policy rather than a bank-mediated approval. But the structural logic is identical: separate the decision to pay from the act of paying, and put a gatekeeper in between.
What the Agent Can Actually Do—and What It Cannot
The SDK exposes three categories of capability. First, payments: an agent can send USDC to a specified address, within the spending limits. Second, trading: the agent can execute swaps, place limit orders, and rebalance a portfolio across assets available on Coinbase. Third, portfolio management: the agent can read balances, track performance, and generate reports. All of these are API calls that the MPC wallet signs if and only if the policy check passes.
What the agent cannot do is change the policy. It cannot raise its own spending limit. It cannot remove the MPC shard that Coinbase holds. It cannot export the private key. These restrictions are not enforced by the agent’s code—they are enforced by the custody infrastructure. That is the critical distinction. An agent’s code can be buggy, jailbroken, or prompt-injected. The custody layer is supposed to be the circuit breaker that holds even when the agent’s logic fails. Whether it actually does is a question of implementation quality, but the architecture at least acknowledges the problem.
The Unanswered Question: Who Is Liable When the Agent Messes Up?
Coinbase’s documentation does not appear to address liability for agent-initiated transactions that comply with the policy but produce undesirable outcomes. If a user sets a $1,000 daily limit and the agent executes a series of bad trades that lose the full amount, the MPC wallet will sign every one of them. The policy was followed. The agent did exactly what it was allowed to do. The loss is the user’s.
This is the frontier that no one has solved yet. Spending limits protect against a compromised agent draining a wallet instantly. They do not protect against an agent that is simply bad at its job, or one that is manipulated through prompt injection into making a series of individually permissible but collectively ruinous decisions. The industry is building the rails for agentic commerce at remarkable speed, but the liability framework is still a blank page. Coinbase’s SDK is a sophisticated answer to the custody question. The liability question remains wide open.