Wallet providers vs. governance layers: why AI agents need both

Every serious agent stack ends up with two components sitting next to each other: a wallet provider that holds the keys, and a governance layer that decides when those keys are allowed to sign. They are different products solving different problems, and confusing them is the fastest way to ship something that either does not scale or does not survive its first incident.

The wallet market for agents is crowded and getting more so. Coinbase has agent wallets. Privy and Turnkey ship embedded and MPC wallets that agent frameworks plug into in a weekend. Fireblocks brings institutional custody to teams that need it. All of them are good at the thing they do: creating keys, protecting keys, and producing valid signatures at speed.

None of them, on their own, answer the question an operator actually cares about: should this agent, on behalf of this customer, be allowed to spend this amount with this merchant right now?

Two different jobs, often mistaken for one

A wallet provider's job is custody and signing. Given a request and a key, produce a signature, settle on-chain, and do it without losing the key. That is a hard, specialized problem — HSMs, MPC, key rotation, chain support, gas abstraction — and it is exactly what these companies are built for.

A governance layer's job is authorization and accountability. Given an agent, a task, and a payment request, decide whether the payment is in policy, route it through approvals if it is not, produce a receipt tied to the task, and give finance and security teams something they can audit. It never touches a private key.

What breaks when the governance layer is missing

• Budgets live in prompts. "Do not spend more than $50" in a system prompt is not a control. It is a suggestion the model can be talked out of.
• Merchant trust is implicit. The wallet signs whatever URL the agent hands it. A spoofed x402 endpoint or a prompt-injected link goes straight to settlement.
• Revocation is nuclear. The only kill switch is rotating the key, which breaks every agent using that wallet.
• Finance sees transactions, not receipts. On-chain history tells you value moved. It does not tell you which task, which customer, or which agent caused it.
• You are locked to one custody vendor. Policy, approvals, and audit logic end up entangled with a specific wallet SDK, so swapping providers means rewriting the agent.

What breaks when the wallet is missing

The mirror-image mistake is a policy engine with no serious custody underneath it. Teams sometimes try to shortcut this with a hot wallet on a server, a service account, or a shared corporate card behind an API. It looks fine in a demo and fails the moment a security review, an auditor, or an incident shows up. Custody is not a thing you build in an afternoon.

Wallet providers exist because getting key management right is hard. Governance layers exist because getting spending policy right is hard. Neither replaces the other.

How the two layers fit together

The clean shape is boring, which is why it works. An agent asks the governance layer to pay. The governance layer evaluates the request against policy — budgets, per-call caps, merchant allowlists, approval thresholds, velocity limits, customer context. If it passes, the governance layer asks the wallet provider to sign a specific, scoped transaction and nothing else. The wallet signs, the chain settles, and a receipt goes back into the audit log tied to the task that caused it.

The wallet never learns about budgets. The policy engine never holds a key. If you want to move from Privy to Turnkey, or add Fireblocks for a subset of enterprise customers, you swap the signing backend behind the governance layer without touching the agents.

Where Vayr Pay sits

Vayr Pay is the governance layer. We are non-custodial by design and speak x402 natively. We are opinionated about one thing: an agent should never be the entity holding the funds it spends, and the company deciding the rules should not be the same company holding the keys. Bring your wallet provider — Coinbase, Privy, Turnkey, Fireblocks, or your own — and we handle everything above it.

The teams building the next generation of autonomous agents will need both layers. The ones that recognize they are different problems, and pick a best-in-class answer for each, will be the ones whose agents get through a security review.

• Cloudflare will let anyone charge agents. Someone still has to let agents pay.
  Cloudflare's Monetization Gateway turns any API, page, dataset, or MCP tool into a paid resource over x402. That solves the merchant side. The buyer side — how an AI agent actually decides to pay, under whose rules — is the other half of the problem.
• MCP meets x402: how tool-calling agents actually pay for tools
  MCP gave agents a standard way to call tools. x402 gives those tools a standard way to charge. Here is how the two fit together, and what a paid MCP tool call actually looks like end to end.