What you will configure

A spend policy with four rules: a daily total cap, a per-payment ceiling, an optional counterparty allowlist, and an optional time window. Together these bound every dimension of risk an autonomous agent introduces when it can spend money. The policy lives in the Blockchain0x wallet API for the agent; it is evaluated on every payment intent before settlement. This is the canonical way to put guardrails on an AI agent in 2026 - see the spending controls product page for the broader framing.

The whole configuration takes about 15 minutes for a new agent. The first three of the rules are the baseline; the fourth (time windows) is useful for predictable workloads like nightly batch jobs.

Why limits belong in the wallet, not the prompt

The single most important design decision in agent safety is where the budget limit lives. There are three options, and only one of them actually works.

In the system prompt. "Do not spend more than $50 per day." This is the most common first attempt. It fails because prompt injection can override it - an attacker who can get instructions into the agent's context can also remove the budget instruction. The prompt is not a security boundary.

In the agent's code. A check before every tool call that compares cumulative spend to a limit. Better than the prompt, but still in the agent's manipulable scope. If your agent is built on a framework where prompts can influence function arguments, an attacker can sometimes coerce the code-level check into letting a payment through.

In the wallet API. The wallet provider's server-side enforcement. The agent sends a payment intent; the wallet evaluates the policy; the wallet either pays or refuses. The agent cannot reach the enforcement code. This is the only design that survives a well-crafted prompt injection.

Blockchain0x implements option three. The rest of this guide is about configuring it.

Pick the right baseline numbers

Before you call the API, write down four numbers:

The most common mistake is leaving the defaults and discovering them only when an agent hits the cap mid-day. Spend 10 minutes on the numbers; it saves hours of debugging later.

If you have no usage history yet (brand-new agent), pick a number that would represent a busy-but-not-runaway day and run it for a week. The first week's data tells you whether to tighten or loosen. Refusing to set any cap because "I do not know the right number" is the worst option - an agent with no cap is one prompt injection away from emptying its workspace's balance overnight.

Set a daily cap and per-payment ceiling

import { Blockchain0x } from "@blockchain0x/sdk";

const client = new Blockchain0x({ apiKey: process.env.BLOCKCHAIN0X_ADMIN_KEY! });

await client.agents.updateSpendPolicy("agt_01J9QKE...", {
  daily_cap_usdc: "20.00",
  per_payment_cap_usdc: "2.00",
});

from blockchain0x import Client

client = Client(api_key=os.environ["BLOCKCHAIN0X_ADMIN_KEY"])

client.agents.update_spend_policy(
    "agt_01J9QKE...",
    daily_cap_usdc="20.00",
    per_payment_cap_usdc="2.00",
)

That is the baseline policy. Every payment intent now passes both checks. A single anomalous request for $5 fails the per-payment cap immediately; a stream of normal $0.50 requests stops when it hits $20 cumulative for the day.

Restrict to a counterparty allowlist

If your agent's legitimate payees are a known small set, this is the strongest single control. Listing them turns prompt-injection-driven payment redirection from a probabilistic concern into a structural impossibility.

await client.agents.updateSpendPolicy("agt_01J9QKE...", {
  daily_cap_usdc: "20.00",
  per_payment_cap_usdc: "2.00",
  allowed_counterparties: [
    "0xPaidMcpServerA...",
    "0xPaidDataApiB...",
    "0xWorkspaceTreasuryC...",
  ],
  default_action: "deny",
});

client.agents.update_spend_policy(
    "agt_01J9QKE...",
    daily_cap_usdc="20.00",
    per_payment_cap_usdc="2.00",
    allowed_counterparties=[
        "0xPaidMcpServerA...",
        "0xPaidDataApiB...",
        "0xWorkspaceTreasuryC...",
    ],
    default_action="deny",
)

default_action: "deny" means anything not on the allowlist is rejected. Without it, the allowlist is informational only - useful for auditing but not enforcing.

Use the allowlist when your agent's vendor set is finite. Skip it when the agent legitimately browses paid MCP tools across the open web; for that case, the daily cap is your control.

Add time-window restrictions

For predictable workloads, restrict payments to the hours the agent is expected to be active. Off-hours payments are a strong signal of either a runaway loop or an exploitation attempt; failing them by default catches both.

await client.agents.updateSpendPolicy("agt_01J9QKE...", {
  daily_cap_usdc: "50.00",
  per_payment_cap_usdc: "2.00",
  time_windows: [{ start: "01:00", end: "05:00" }],
});

Times are in the agent workspace's local timezone, configured per workspace. Multiple windows are supported if your workload runs twice a day.

Subscribe to policy events

Every rejected payment intent emits a policy_violation webhook event with the rule that fired and the requested amount. Subscribe to it. A reasonable alert: more than 5 rejections per hour from one agent, or any rejection from an agent that has never had one before. The rule field tells you which control fired; the amount tells you how close the agent got to the cap before being stopped.

The full webhook setup is documented in the handle-agent-payments-with-webhooks guide. The same handler that watches payment.confirmed should also watch policy_violation.

Common mistakes

Five mistakes that defeat the policy you spent time configuring.

Putting the cap in the agent's system prompt for "defense in depth". This is not defense in depth; it is a false confidence multiplier. Prompts are not security boundaries. Only the wallet-side policy counts. Tell the agent about the cap in the system prompt for behavior tuning, but never as the only line of defense.

Setting the daily cap from a vanity number. The right cap is 2-3x your real daily usage, not whatever round number sounds safe. A $1000/day cap on an agent that normally spends $5/day is not "more conservative"; it is no cap at all.

Forgetting allowlists are address-exact. A new payee with a new wallet address is rejected, even if it is the same merchant rebranding. Update the allowlist when your vendor set changes, the same way you update any other access control.

No alert on policy_violation. Every rejected payment is a signal. If you do not watch them, you miss both real incidents and policy misconfigurations.

Giving the agent runtime your admin API key. The agent runtime needs only the scoped key for its day-to-day operations. The admin key (which can rewrite the spend policy) belongs in your dashboard, your secret manager, and nowhere the agent's prompt can reach.

The full safety story includes verification badges on the agent's public profile, audit logs reviewed weekly, and an incident runbook drilled at least once. See /pricing/ for the per-agent tiers that unlock the full spend-policy feature set. For wallet-level decisions that complement these limits, see /lp/best-wallet-for-ai-agents. For the parallel pattern of payments-from-MCP-servers (a place where these limits are especially load-bearing), see /lp/how-to-add-payments-to-mcp-server. The canonical companion topics on overspending prevention and broader agent-payment security are planned LPs at /lp/how-to-prevent-ai-agent-from-overspending and /lp/how-to-secure-ai-agent-payments; the secure-your-agent-wallet guide covers most of that ground today.