Privy issues guide to agent USDC wallets on Base

Privy published documentation, updated September 27, 2026, that explains how to provision agent-owned wallets for USDC on Base. The guidance covers key custody inside Trusted Execution Environments, policy checks before signing, x402 payment settlement, and a command-line interface for shell-based agents.

The documentation directs operators to create authorization keys or a key quorum in the Privy Dashboard and store private material in an external secrets manager. Private keys are reconstituted only inside hardware-isolated TEEs and are not exposed to agent processes or prompts. Backends sign Privy API requests on behalf of agents using the stored authorization keys.

Privy describes policies as the enforcement mechanism that runs inside the enclave before any signature is produced. Policies can restrict allowed chains and tokens, require allowlisting of recipient addresses and contract addresses, and enforce per-transaction value caps. For Base USDC transfers the guide specifies allowlisting the USDC contract address 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and approved recipients. The guidance requires explicit eth_signTypedData_v4 rules for x402 payments because x402 authorizations use EIP-712 typed data.

When creating wallets, operators set the owner_id to the authorization key or key quorum and attach a policy_id array so each wallet inherits the guardrails. Wallet IDs and addresses should be stored in an agent registry and funded with USDC on Base before attempts to settle payments. The documentation notes that facilitators generally pay gas for x402 settlement, so agent addresses typically require USDC rather than ETH on the payment chain. For testing, Circle’s Base faucets are suggested and the Privy sandbox supports human funding for CLI flows.

For API-level payments, Privy provides x402 integrations. Node projects can use createX402Client from @privy-io/node and wrap fetch with @x402/fetch to auto-settle HTTP 402 challenges from the agent wallet. The guidance instructs teams to set a hard per-request maxValue cap expressed in USDC base units (USDC uses six decimals) to limit how much a single 402 challenge can spend. If a wallet uses Privy gas sponsorship, clients should pass documented signature options such as erc1271.

Privy’s Agent CLI, @privy-io/agent-wallet-cli, supports shell agents via device-authorization login, a fund flow through agents.privy.io, wallet listing, and rpc calls. The CLI exchanges OAuth tokens for ephemeral signing keys per request and does not expose wallet private keys to the agent process. Sessions can last up to 30 days with automatic token rotation; administrators can revoke sessions and rotate authorization keys from the management console.

The guidance lists operational risks including relying only on eth_sendTransaction allowlists while agents may sign x402 typed-data payments, using a root Privy user for agent signing since root principals bypass policies, sharing a single wallet across agents with different trust levels, omitting per-request maxValue caps, funding the wrong chain or wrong contract address, and leaving CLI sessions active after an incident.

Privy documents two authorization models. Agent-owned wallets are provisioned and controlled by the service via authorization keys and operate without user sessions. Delegated signing lets an agent act on a user’s wallet with a scoped, revocable authorization key. The documentation includes command examples, policy shapes, and integration notes for Node and React clients; operators must follow those pages for exact API calls and deployment details.