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.

• x402 now has a formal attack surface. Four flaw classes, and what they mean for anyone letting agents spend.
  The first systematic security analysis of x402 identifies four flaw classes — cross-resource substitution, duplicate-settlement races, allowance overdraft, and denial of settlement — reaching 100% resource leakage against official SDKs. Here is what each one actually does, and why a payment protocol was never going to be the place where spending gets controlled.
• 200 million x402 transactions, $15 million moved. What the numbers actually say.
  The x402 Foundation is live under the Linux Foundation with 40 members including Visa, Mastercard, Amex and Stripe. Transaction counts are enormous and dollar volume is tiny — roughly 14 cents a payment. That ratio is not a failure. It is the whole point, and it changes what the control layer has to look like.