x402 spend controls compared: Shotoku, AgentPay MCP, x402-cfo and PolicyLayer

November 6, 2026 · By the Shotoku team

Short answer: x402 defines how an agent pays for a request. A budget that spans many requests has to come from something else, and the check has to run after the 402 response and before the agent signs. Four tools do this in different ways:

• x402-cfo if you want a drop-in client with hourly, daily and session budgets, analytics and anomaly detection.
• AgentPay MCP if you want the wallet and the payment tools in one MCP server, with optional limits on-chain.
• Shotoku if you want a deterministic local policy, human approval and a tamper-evident record, in a tool that never touches your keys.
• PolicyLayer needs a check first. Its x402 SDK was last published in January 2026, and its website now describes a different product.

How do the four tools compare?

Where should an x402 budget check run?

Between the 402 response and the signature. Before the 402, there is no amount to check. After the signature, the payment can settle. That gap is the only point where the agent knows the full cost and nothing irreversible has happened. All four tools work there. What differs is who can override the check and what is left afterward.

What should you check in any x402 spend control?

1. Can the agent change its own limit?AgentPay’s README is direct about this: the same agent can call set_spend_policy again. Its on-chain limits avoid that, but only if the wallet owner sets them on the contract.
2. Does spending history survive a restart? If rolling totals live in memory, a restart resets the budget. AgentPay documents this. x402-cfo fixes it with a storage adapter, so make sure you configure one.
3. Is the human gate separate from the agent? An approval the agent can grant itself is not an approval. Check where the approval key or command lives.
4. Does it trust the 402 body? The server asking to be paid writes that response. A hostile server can name an allowlisted vendor as the resource and put its own address in payTo. Ask which fields come from the server and which come from your own request.
5. Can you prove the log later? A plain log can be edited without trace. A hash chain breaks if a past entry changes.

What does this look like in Shotoku?

This policy allows small payments to one API at one address, caps every agent at $5 a day, and sends everything else to a human:

rules:
  - resource: api.weather.xyz
    recipients: ["0x000000000000000000000000000000000000dEaD"]
    actions: [purchase]
    verdict: approved
    maxAmount: 0.10
    maxDailyAmount: 1.00

defaultVerdict: pending_approval

budgets:
  - actor: "*"
    maxDailyAmount: 5.00

The check goes between the 402 and your signing code:

import { authorizeX402Payment, parseX402Response } from "@shotoku/core";

const requirements = parseX402Response(body, { requestUrl: url });
const decision = await authorizeX402Payment("agent-1", requirements, {
  policyPath: "./policy.yaml",
  ledgerPath: "./data/decisions.jsonl",
});

if (decision.approved) {
  return signPayment(requirements.option); // your wallet signs, not Shotoku
}
throw new Error(`Payment blocked: ${decision.status} [${decision.decisionId}]`);

We ran this policy against five simulated 402 responses, using USDC on Base:

Where does Shotoku fall short?

• It isn’t drop-in for x402. You add the call yourself. x402-cfo wraps fetch, and AgentPay gives the agent an x402_pay tool.
• Code that skips the check isn’t stopped.Shotoku holds no key, so if your agent can sign directly, it can pay without asking. To close that route, keep the key behind a service that verifies Shotoku’s signed receipts. AgentPay’s on-chain limits are stronger here, because the contract enforces them whatever the process does.
• No analytics or anomaly detection. Rules are deterministic by design. If you want burn rate, cost estimates or statistical anomaly blocking, x402-cfo has them.
• Budgets are daily only. There are no hourly or session windows yet.
• Only USDC on Base works by default. Other assets must be registered. Unknown tokens are refused.
• It’s beta, and npm is behind main. Recipient rules, agent budgets, the request-host check above and the local dashboard and Telegram approvals are in the repo but not in the current npm release. The table describes main.

Which x402 spend control should you use?

These aren’t all exclusive. On-chain limits work as a hard ceiling underneath a local policy that decides each payment.

Common questions

Can a prompt enforce an x402 budget?

No. A prompt is an instruction the model can misread or ignore, and a prompt injection can override it. A budget has to be enforced by code outside the model.

Does a spend control need to hold my private key?

No. A decision only needs the amount, the recipient and the resource. Shotoku and x402-cfo leave signing to your wallet, and PolicyLayer says keys stay on your server. AgentPay loads the key because it is also the wallet.

What about AWS, Visa and Mastercard?

Platforms such as Amazon Bedrock AgentCore Payments are adding agent payments with their own limits. We left them out because this post covers tools you can add to an x402 client yourself.

Try it

Read the x402 guide or start with the quickstart. Shotoku is open source, deterministic, holds no funds and runs on your machine.

Sources

• agentpay-mcp on npm and GitHub
• x402-cfo on npm and GitHub
• @policylayer/sdk on npm and policylayer.com
• Shotoku on GitHub
• x402.org

Related

• How to set a hard spending limit on an AI agent
• How to require human approval before an MCP tool call
• How to stop an AI agent from deleting your production database