DEV Community: veto

Prompt-level spend limits don't hold: how to actually stop an AI agent from overspending (x402, AP2, and the payment path)

veto — Tue, 07 Jul 2026 15:56:10 +0000

You told the agent: "Don't spend more than $50 on this task."

The agent spent $340.

If you're building on x402, Google AP2, or any rail that lets agents pay autonomously, this isn't a hypothetical. It's an architecture problem, and the fix isn't a better system prompt.

When you put a spend limit in a prompt, you're relying on the model to honor it. That works until it doesn't: a multi-step task where the agent loses context, a tool call that concatenates several individually-small charges, a subagent spawned by the top-level agent that never saw the original instruction, or just a model that decides the task is important enough to override a soft constraint.

Prompt instructions are not enforcement. They're requests.

This distinction matters more now than it did 18 months ago. x402 (the HTTP-402 + stablecoin payment protocol) has settled over $50M across 480,000+ agents. Google AP2 lets agents pay each other autonomously. The surface area for uncontrolled agent spend is real, it's growing, and there's no native policy mechanism baked into either protocol. You are currently shipping agents that can spend money with no hard stop between them and the payment rail.

The payment path is where the limit needs to live. It needs to be in the path that every payment traverses, regardless of which model issued the request, which tool called it, or how many layers of subagents the chain involved. That's not the prompt. This is the same insight that makes RBAC work for databases. You don't enforce access control by asking the application to be polite. The control has to be structural, not instructional.

An enforcement layer at the payment level intercepts the transaction before the rail executes it, checks it against policy, and either approves, denies, or escalates. The agent can't bypass this by ignoring a prompt constraint, because the constraint isn't in the prompt.

Veto is built around this model. It sits between an agent and the money it's about to spend across any agent, any payment rail. A few things that matter technically:

Mandates, not promises. Rather than trusting that an agent intends to stay within budget, Veto uses mandates — explicit buyer-side authorizations ("may my agent spend $X?"). These are signed artifacts, not prompts. They're cryptographically issued, and the merchant side can verify them locally at zero latency before any capture happens.
A fixed enforcement order. The Acceptance Gate runs in a fixed sequence before any payment executes: verify mandate, check replay, evaluate reputation, run policy. The docs are explicit about why the order matters: "The order is the chargeback defense." And: "The rail only ever executes a spend the gate already approved." There's no shortcut, no layer an agent can skip.
Rail-agnostic. The policy engine sits above the settlement layer. x402 is the primary rail, but the architecture is pluggable (mock for offline testing, card as a future stub). One policy surface covers whichever rail you're using — "one policy, one audit surface, every rail."
Signed receipts. Every approved transaction produces a merchant-signed artifact linking back to the buyer's mandate. The dispute trail is created at the moment of transaction, not reconstructed from logs after the fact.
Non-custodial. Veto never holds funds. You bring your own receiving address.

If you're using Claude Code with payment-capable tools, Veto ships a PreToolUse hook that intercepts payment-shaped tool calls before they run — transfers, sends, swaps, cast send, solana transfer, x-payment / HTTP-402 flows, Stripe calls. The hook queries Veto for allow / deny / escalate before the tool executes.

That's the right abstraction. By the time the agent has decided to spend money and is calling the tool, no amount of system-prompt hedging is relevant. The firewall either lets it through or it doesn't. Slash commands (/veto:authorize, /veto:receipts, /veto:policy) give you inspection and override directly in the workflow.

If you're building an agent that spends money — API calls, onchain transactions, anything on x402 or AP2 — there's one question prompt engineering can't answer: what actually stops the agent from exceeding its authorization?

If your spend limit is only in the prompt, it's not a limit. It's a suggestion.

Selling to AI agents: what merchants need to know about x402 checkout, mandates, and chargeback-free settlement

veto — Mon, 06 Jul 2026 08:21:25 +0000

If you're building a platform that sells digital goods, API access, data subscriptions, or any service an AI agent might buy programmatically, you've probably noticed your existing checkout flow wasn't designed for this. A Stripe-hosted payment page expects a human to read it. A PayPal redirect expects a browser session. Neither exists when the buyer is a LangChain agent or a scheduled curl script.

Here's what actually changes when the buyer is autonomous, and what infrastructure you need to handle it safely on the merchant side.

The core problem: human checkout flows break with autonomous buyers

Traditional payment flows are built around human intent signals. A user loads a cart, sees a price, enters card details, clicks confirm. Fraud prevention leans heavily on behavioral signals from that session. Chargebacks exist partly because the system can't verify at authorization time whether the human who clicked "pay" was actually authorized to do so.

AI agents remove most of those signals. No browser session, no mouse movement, no card-on-file tied to a human who can call their bank later. What you get instead is a programmatic request with a cryptographic authorization attached, which is actually more verifiable than what you get from a human, if you know how to check it.

Most merchant infrastructure doesn't know how to check it.

What x402 is, and why it matters here

x402 is an HTTP-native payment protocol built on the long-dormant 402 Payment Required status code. The idea: an agent hits your endpoint, you respond with 402 and a payment descriptor, the agent settles stablecoin payment on-chain, attaches proof to the next request, and you fulfill. No redirect, no session, no human in the loop.

For pure machine-to-machine commerce, this is the right primitive. The payment proof is on the request. Settlement is final. There's no card network sitting in the middle that can reverse it three weeks later.

But x402 alone doesn't solve the merchant's problem. It just moves where the problem lives. Instead of wondering whether a human's card was stolen, you're wondering whether the agent that just paid was actually authorized to spend that money in the first place. Different liability, equally real.

What a mandate is, and why you need to verify one

In agentic payment systems, a mandate is a cryptographically signed authorization stating that an operator (a company, a developer, a human principal) has explicitly authorized a specific agent to spend funds up to certain limits for certain purposes. Think of it as a scoped, machine-readable power of attorney.

Before you capture funds from an agent, you want to verify three things:

The mandate is real (the authorization signature is valid and wasn't forged)
The mandate is current (it hasn't been revoked or replayed from a previous transaction)
The transaction is in scope (what the agent is trying to buy matches what the mandate actually permits)

This verification has to be fast. If you're selling API access at request time, you can't afford a round-trip to a third-party verification service on every call. Latency aside, you also can't have your payment authorization path go down every time an external service is unavailable.

The right architecture verifies mandates locally, with no network dependency. A signed authorization you can check offline gives you both the latency and the resilience properties you need.

Why order matters more than you think

Even with mandate verification in place, you need to think carefully about the sequence of checks before capturing payment. Skipping steps or running them in the wrong order isn't just a quality issue — it's a liability issue.

Veto Checkout's documentation describes a fixed four-step gate that runs before any money is captured:

Verify the mandate (confirm the authorization signature is valid)
Check for replay (ensure this transaction token hasn't been used before)
Evaluate reputation (check what's known about this agent or operator)
Run policy (apply your own merchant-defined rules: rate limits, spend caps, allowed product categories, etc.)

The docs describe this sequence explicitly: "The order is the chargeback defense." And: "The rail only ever executes a spend the gate already approved."

That framing is useful. The gate is what makes "settlement is final" mean something. If you capture funds before completing these checks, you've already lost the structural advantage that agentic payment gives you over card payments. You're back to relying on post-hoc dispute resolution.

Non-custodial settlement and rail flexibility

One architectural detail worth understanding

This post is from the team at Veto. Veto Checkout is our merchant-side SDK for exactly this: agents discover your products, the acceptance gate verifies the mandate before you capture, and settlement lands instantly in USDC on Base. If you are thinking about selling to agents, the merchant docs show the whole flow in about 30 seconds.