Agent wallets: Coinbase CDP vs a local key

An agent that pays x402 APIs needs a wallet that signs USDC transfer authorizations. Where that wallet's key lives decides what a spending policy can really enforce. This guide compares the two modes Burnbound supports, a Coinbase CDP wallet and a key on your own machine, and is direct about what each one does not protect against.

Burnbound never stores a wallet private key and never holds funds in either mode. Payments go from your wallet to the seller.

The short answer

• Use Coinbase CDP if the agent can run shell commands (Claude Code, Cursor, any coding agent), runs unattended, or you need the policy to hold even if the agent misbehaves. The agent never holds anything that can sign.
• Use a local key if you want the key on your own machine, nobody else involved in signing, and you accept that an agent with shell access on that machine could bypass the policy.

How each mode signs

Coinbase CDP: the agent holds nothing that signs

You create a wallet in the Coinbase Developer Platform and paste into the Burnbound dashboard its API key ID, API key secret, wallet secret and address. When a payment passes the agent's policy, Burnbound asks CDP to sign it and returns the signed payload to the MCP server, which sends it to the seller.

What it protects against: the agent's machine has only the agent key (bb_agent_…). That key can ask Burnbound to authorize a payment, but every request goes through the policy, and the key cannot change the policy, raise a cap or approve a payment. An agent that reads every file on the machine still finds nothing that can move USDC.

What you trust: Burnbound holds credentials that can request signatures. They are encrypted at rest, decrypted only to request a signature, and never shown again or returned by the API. They are still powerful, so treat the CDP wallet as a spending wallet: keep in it only what your agents should be able to spend.

Local key: your machine, your signature

You create the wallet on your machine and register only its address:

npx -y @burnbound/mcp wallet init

The private key is stored in the macOS keychain, the Linux Secret Service (GNOME Keyring, KWallet) when a session bus is available, or otherwise a file in ~/.burnbound/wallets/ that only your user can read. It is never in the MCP config, never in the environment, and never sent to Burnbound.

When a payment passes the policy, Burnbound returns exactly what to sign: the seller's own offer, a nonce derived from the payment, and a short validity window. Before signing, the MCP server checks that the local wallet is the one registered for the agent, that the offer belongs to the host that asked, that the amount is within the call's maxAmountUsd, and that the window is at most 300 seconds. It only signs USDC TransferWithAuthorization on Base or Base Sepolia.

What it protects against: Burnbound cannot get anything signed. If Burnbound were compromised, it would hold your address and nothing else.

The cooperative limit of a local key

This is the part to be honest about. Client-side signing works only while the agent goes through the MCP server. A process that runs as your user can read what your user can read: an agent that can run shell commands on the machine could read the key from the keychain or the wallet file and sign a transfer without asking Burnbound.

The MCP server makes that harder, not impossible:

• the key is loaded only at the first fetch_paid, never by the read-only tools;
• every request to Burnbound and to sellers is checked for the key and blocked if it appears;
• the server refuses to start if a BURNBOUND_* variable looks like a private key;
• wallet export prints the key only on an interactive terminal, after you type the address to confirm.

With Claude Code you can also deny the agent the usual ways to read the key, in .claude/settings.json. These rules reduce accidents; they are not a sandbox:

{
  "permissions": {
    "deny": [
      "Read(~/.burnbound/**)",
      "Edit(~/.burnbound/**)",
      "Bash(security find-generic-password:*)",
      "Bash(security dump-keychain:*)",
      "Bash(secret-tool lookup:*)",
      "Bash(npx -y @burnbound/mcp wallet export:*)"
    ]
  }
}

Detecting spending outside the policy

For local wallets, Burnbound watches the address on-chain and records a payment.out_of_policy event when USDC leaves it without a matching payment it allowed: a transfer authorization with an unknown nonce, one sent to a different payee or amount, a plain transfer(), or an approve()/permit() that grants an allowance. The event shows in the audit and as a warning on the agent's page, usually within minutes. It detects after the fact; it cannot block or reverse the transfer.

In both modes: keep the balance small

The wallet balance is the real ceiling on what a misbehaving agent can spend outside the policy. With a local key, an agent that reads the key can spend the whole wallet; in any mode, a wallet holding a week of spend loses at most a week of spend.

• Fund it with a few days of expected spend and top it up. x402 calls usually cost cents: see current prices in the x402 API catalog.
• Keep no ETH in a local wallet. x402 payments do not need it, and without it the wallet cannot send an ordinary transaction itself.
• Use one wallet per agent (--profile <name> for local wallets), so a problem in one does not reach the others.

Mixing modes across agents

Each Burnbound agent has its own wallet connection, policy and keys. You can give an unattended agent a CDP wallet and a local key to an agent you watch at your desk, and both show up in the same dashboard and audit log.

Read more

• The full trust model: Security.
• Signing modes in reference form: Concepts.
• Set up an agent with either mode: Quickstart.