Agent Wallet Setup — Choose, Fund, and Cage a Signer

Every autonomous payment starts with one question: where do the keys live? Get it wrong and your agent is either paralyzed (can't sign without a human click) or dangerous (a raw key sitting in an env var, one prompt injection away from draining). This skill is the decision layer the vendor docs don't give you: which signer fits your situation, the guardrails that are mandatory regardless of vendor, and the handoff into x402 payments.

The one rule that overrides everything

The agent never sees a private key. Ever. Not in an env var it can read, not in a file it can cat, not in its prompt or context. The agent should hold, at most, an API credential that lets it request signatures from a signing service that enforces policy. If your design has the agent holding a key, the design is wrong — an agent that can read its own key can be tricked into leaking or misusing it by a single hostile webpage or poisoned tool result. (This has happened in production: the AIXBT trading bot lost 55+ ETH in March 2025 because nothing bounded what its compromised wallet could sign.)

The decision tree

Answer these in order; stop at the first match.

1. Does a human review every transaction anyway? → Use a browser wallet (MetaMask, Rabby, Coinbase Wallet). The human clicks each signature. Zero automation, zero standing risk. Right for: one-time registrations, occasional manual purchases, testing a marketplace before committing. Wrong for: anything the agent does while you sleep.

2. Is this a production agent that transacts autonomously? → Use a managed signing service with a policy engine. Keys live in the provider's secure enclave (TEE); the agent calls an API; the provider refuses to sign anything that violates your policy. Pick among:

All three keep keys in enclaves and enforce policy at the signing layer — a compromised agent still cannot sign outside the cage. Do not duplicate their setup docs from memory; each vendor ships an official quickstart (and Privy and Coinbase both publish their own agent skills). This skill's job is the choice and the cage, not the vendor's API reference.

3. Is this a throwaway experiment with ≤ $5 at stake? → A raw key (e.g. cast wallet new) in a dedicated wallet is acceptable for learning, on the strict conditions that it never holds more than you'd hand a stranger, it is never reused for anything else, and it is treated as already-compromised. This is the only legitimate use of a raw key by an agent, and it does not graduate to production. There is no step 4 where the raw key becomes acceptable at higher balances.

The cage — mandatory regardless of provider

Configure ALL of these before the wallet holds a cent. They map to native policy features on CDP and Privy, and to the spending-guard section of any x402 client skill:

1. Per-transaction cap. Set it at or just above your expected payment size (e.g. $1–2 for x402 micro-payments). A $0.10 API call gets signed; a $50 "payment" from a hostile 402 gets refused by the signer itself.
2. Per-session / daily cap. Bounds total damage if the agent loops or is manipulated repeatedly. Cap ≈ (expected daily spend) × 3.
3. Asset and chain restriction. USDC on Base only, if that's all the agent does. An agent that can only move USDC can't be tricked into approving a malicious token contract.
4. Contract / recipient allowlisting where possible. If the agent pays a known set of endpoints, allowlist those payTo addresses or the USDC contract methods (transferWithAuthorization) it may sign.
5. Minimal standing balance. Fund the wallet like a lunch wallet, not a treasury: a few dollars, topped up when low. The cage limits the rate of loss; the balance limits the total.
6. Audit trail. Log every signature request (amount, recipient, timestamp, what triggered it). CDP and Privy both expose webhooks/events; wire them to somewhere a human reads.
7. A kill switch you've actually tested. Know the exact call that revokes the agent's credential or freezes the policy, and confirm it works before launch — not during an incident.

Funding on Base

• The wallet needs USDC on Base: contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, 6 decimals.
• It usually needs no ETH at all: x402 payments use EIP-3009 transferWithAuthorization (the facilitator pays gas), and CDP smart accounts route through Coinbase's paymaster on Base. If your agent's only job is paying x402 endpoints, an ETH balance is just extra attack surface.
• Cheapest funding paths: send USDC directly on Base from an exchange that supports Base withdrawals, or bridge from another chain. Verify you're sending Base USDC, not Ethereum USDC (0xA0b8...eB48) — they are different contracts on different chains and mixing them strands funds.
• Fund AFTER the cage is configured, never before.

Handoff to payments

Once the wallet exists, is caged, and holds a few USDC, the agent pays x402 endpoints by: requesting an EIP-712 signature over TransferWithAuthorization typed data from its signing provider, then attaching it as an X-PAYMENT header. The full client loop (parsing the 402, authorization windows, nonces, polling, failure modes, and whether a failed call charged you) is its own skill — pair this one with an x402 client/autopay skill. The division of labor: this skill decides who signs and within what bounds; the payment skill decides what gets signed and when.

Common mistakes

• Key in an env var the agent's shell can read. echo $PRIVATE_KEY is one injected instruction away. Managed signer or human-click only.
• One wallet for everything. Your personal wallet, your deploy wallet, and your agent's spending wallet must be three different wallets. Agent compromise should never touch your holdings.
• Caging in the prompt instead of the signer. "Never spend more than $2" in a system prompt is a suggestion; the same rule in a CDP/Privy/Turnkey policy is physics. Prompts get injected; policy engines don't read prompts.
• Funding before caging. The order matters. An uncaged funded wallet is live risk from minute one.
• Treating testnets as proof. A policy that works on Base Sepolia still needs verification with a $0.10 real transaction before you trust it with more. Test the kill switch at the same time.
• Skipping the vendor's own docs. Provider APIs change. Use the official quickstart for the API calls; use this skill for the decisions the quickstarts assume you've already made.

Example

Input: "My research agent needs to buy datasets from x402 endpoints, ~$0.25 each, maybe 20 per day, unattended."

Output of following this skill: CDP Server Wallet (step 2 of the tree — autonomous, Base, x402-native) with policy: $1 per-tx cap, $15 daily cap, USDC-on-Base only, transferWithAuthorization method allowlisted; webhook logging to the operator's Slack; kill-switch call tested; funded with $10 USDC on Base after policy attach. Agent credential = CDP API key with access to that one wallet. Time to set up: under an hour. Maximum theoretical loss if everything goes wrong at once: $15.

Model recommendation

sonnet is sufficient. The judgment is encoded in the decision tree; the remaining work is following a vendor quickstart and configuring policy JSON.