How to Give Your AI Agent a Wallet — and Keep It Governed

Giving an AI agent its own wallet used to be the hard part. It isn't anymore: with infrastructure like Privy you can mint a wallet an agent controls programmatically in a few API calls, with the private key sealed in hardware and never exposed to the model. The hard part now is different — and quieter. It's making sure that when your agent can spend money, it only spends what it should. This guide walks through both: how to give your agent a wallet, and the governance layer a wallet alone doesn't give you.

New to the space? Start with the parent guide: What is Agentic Commerce?

The two problems everyone collapses into one

"Give my agent a wallet" is really two problems, and most teams only notice the first:

1. Custody and signing. Where does the private key live, who can sign with it, and how do you keep it out of the agent's prompt, memory, and logs?
2. Governance. Once the agent can move funds, what stops it from moving the wrong funds — too much, too often, to the wrong place, with no record your finance team can reconcile?

Wallet infrastructure has largely solved problem one. Problem two is where autonomous spend actually goes wrong, and it's a layer above the wallet. Keep the split in mind — it's the whole shape of this article.

Giving your agent a wallet with Privy

Privy's answer for agents is the server wallet: a wallet designed for autonomous, programmatic use with no human clicking "confirm." The private key is generated and held inside hardware-isolated trusted execution environments (TEEs), and — in Privy's own framing for agent use — "private keys are never exposed in agent prompts, memory, or logic" (Privy). The agent asks the API to sign; it never touches key material.

Creating one is a single server-side call. Over REST:

curl -X POST https://api.privy.io/v1/wallets \
  -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \
  -H "privy-app-id: $PRIVY_APP_ID" \
  -H "Content-Type: application/json" \
  -d '{ "chain_type": "ethereum", "policy_ids": ["<policy-id>"] }'

Or with the Node SDK:

const { id, address } = await privy.wallets().create({
  chain_type: "ethereum",
  policy_ids: ["<policy-id>"],
});

A few things worth noting from the create-a-wallet docs:

• chain_type spans far more than Ethereum — the API accepts ethereum, solana, stellar, sui, tron, bitcoin-segwit, near, ton, starknet and more, so one provider covers most chains an agent might touch.
• policy_ids attaches guardrails at creation time (more on those below).
• additional_signers grants scoped signing rights to other parties.
• owner ties the wallet to a user or an authorization key.

If instead you want an agent to act on an end user's existing embedded wallet, Privy has a browser-based delegation flow: the agent generates a short authorization code, the user signs in and approves a scoped set of permissions, and from then on the agent transacts "without ever handling private keys, credentials, or other sensitive information directly." Privy notes it's built to work across "CLIs, MCP servers, skills, and other agent environments" — the shapes agents actually ship in. There's even an official agentic-wallets skill that teaches an agent to do this end to end.

One more convenience that matters for agents: gas sponsorship. Privy can cover the network fee so your agent doesn't need to hold each chain's native gas token just to transact (Privy). Combined with a gasless payment scheme like the one x402 uses, an agent can pay in USDC without ever managing ETH or SOL for fees.

Guardrails: Privy's policy engine

This is the part that separates "an agent with a wallet" from "an agent with a wallet you can sleep next to." Privy's policy engine lets you attach rules that are checked before any transaction is signed, inside the same secure environment that holds the key. As Privy puts it, "if the request does not adhere to the policy, even if the request comes from your servers, it will not go through" — there is "no way to bypass it" (Privy).

The model has three primitives — policies, rules, and conditions — and conditions are expressed as a flexible field_source / field / operator triple. Roughly:

{
  "version": "1.0",
  "name": "agent-spend-guardrails",
  "chain_type": "ethereum",
  "rules": [
    {
      "name": "only pay allow-listed recipients",
      "conditions": [
        {
          "field_source": "ethereum_transaction",
          "field": "to",
          "operator": "in",
          "value": ["0xVendorA…", "0xVendorB…"]
        }
      ]
    }
  ]
}

(Illustrative — see the docs for the exact schema.) With those primitives you can express per-transaction value caps, recipient and contract allowlists and denylists, restrictions on the parameters passed to a contract call, and blocks on dangerous operations like delegatecall. Rules stack, so a wallet can be constrained several ways at once.

Two honest caveats before you lean on it:

• Chain coverage. Policy enforcement today applies to Ethereum (EVM), Solana, Tron and Sui. Privy can custody and sign on Stellar and other chains, but the on-chain policy engine doesn't cover them yet — so if you're on Stellar, guardrails have to live in your own code.
• What it doesn't do yet. The engine reasons about a transaction in isolation. Cumulative or velocity limits ("no more than $500 across all transactions today") and full transaction simulation are described by Privy as features still in development (Privy) — not something you can enforce at the wallet today.

That second gap is not a knock on Privy; per-transaction enforcement in a TEE is exactly the right primitive for a wallet to own. But it points straight at what a wallet, by design, can't see.

Where the wallet alone stops

A wallet — even a well-governed one — sees one transaction at a time, on one chain, for one agent. The questions that actually keep a finance or platform team up at night live above that line:

• Aggregate budgets. "This agent may spend $500/day and $5k/month, total, across every wallet, chain and provider." No per-transaction cap adds up to this.
• Human approval. "Anything over $200 pauses for a person to approve." A wallet either allows a transaction or rejects it — it has no notion of escalation.
• An audit trail you can reconcile. One ledger of every agent payment — across Privy wallets, other wallet providers, and payment rails like x402 or mandates like AP2 — that finance can actually close the books against.
• A fleet view and a kill switch. Fifty agents across three providers, one dashboard, one place to freeze spend when something looks wrong.

None of these are wallet features, because none of them are answerable from inside a single wallet. They're a control-plane concern — one layer up.

The governance layer: AgentLedger Wallets

That layer is what AgentLedger builds, and AgentLedger Wallets is the module for exactly this pattern: Privy holds and signs; AgentLedger governs and audits. You connect the Privy wallets your agents already use, and get the things a wallet can't give you on its own —

• Cumulative budgets per agent, per day and per month, across every wallet and chain (the limit Privy's per-transaction rules can't express);
• Human-in-the-loop approvals above a threshold, with a real escalation path;
• One unified ledger of agent spend across providers and across rails (x402, AP2, and more) — not one silo per wallet;
• A fleet view and kill switch over the whole set of agents.

AgentLedger is non-custodial — it never holds your keys. Privy keeps custody and does the low-level, per-transaction enforcement in its TEE; AgentLedger sits on top and governs the aggregate spend that no single wallet sees. And because the governance is backend-agnostic, the same controls apply whether the underlying wallet is Privy, Coinbase CDP, Turnkey or another provider — Privy is the first and recommended engine, not a lock-in.

You can watch the governance gate run on synthetic agents in the live demo — budgets, approvals and the ledger, working against simulated spend.

Getting started today

A practical path from zero to a governed agent wallet:

1. Create a Privy app and grab your PRIVY_APP_ID / PRIVY_APP_SECRET from the dashboard.
2. Mint a server wallet on an EVM chain (Base is a common choice for USDC) with the create call above.
3. Attach a policy — start with a recipient allowlist and a per-transaction cap. (The policy engine is available as an add-on on Privy's paid plans; the core wallet infrastructure and a generous free tier cover early development — see Privy pricing.)
4. Fund it with a little USDC on testnet and confirm a payment goes through.
5. Put governance on top — connect it to AgentLedger for cumulative budgets, approvals and a unified audit trail. Join the waitlist to get in early.

Frequently asked questions

What is an AI agent wallet?

It's a crypto wallet that an AI agent controls programmatically — creating, signing and sending transactions without a human clicking "confirm" each time — so the agent can pay for APIs, data, compute or goods on its own. The private key is typically held by wallet infrastructure (in a secure enclave), not by the model.

Is Privy custodial?

Privy uses a self-custodial model with keys secured in hardware TEEs; only the rightful owner can administer the wallet. For server wallets, your application's authorization keys control signing, so your backend — not Privy — decides when the wallet signs. Privy is the infrastructure that protects and executes; it isn't a custodian making spending decisions for you.

Which chains can an agent wallet use?

Privy can create and sign wallets on many chains — Ethereum and other EVM networks, Solana, Stellar, Sui, Tron, Bitcoin, TON, NEAR and more. Its policy engine, however, enforces rules on EVM, Solana, Tron and Sui today; on other chains (including Stellar) it custodies and signs, but guardrails have to live in your own application.

Is the Privy policy engine free?

Privy's core wallet infrastructure comes with a free tier (at the time of writing, up to 499 monthly active wallets, 50,000 signatures and $1M in monthly transaction volume). The policy engine is listed as a paid add-on rather than part of the base plan, so check current pricing before you depend on it in production.

Does AgentLedger replace Privy?

No — it sits on top of it. Privy is the wallet: custody, signing, and per-transaction enforcement. AgentLedger is the governance layer: cumulative budgets, approvals, a kill switch, and a unified audit trail across every wallet and payment rail. They're complementary, and AgentLedger works with Privy and other wallet providers alike.

How is this different from just setting a per-transaction limit?

A per-transaction cap stops one big payment; it does nothing about a thousand small ones. Governance is about aggregate behavior — total spend per agent per day, approvals above a threshold, and one ledger across all of an agent's wallets and rails. That's the layer a single wallet can't provide, and what AgentLedger is for.