AI Agent Spending Limits: How to Build a Mandate That Can't Be Overspent

The fourth power is policy. A limit in your agent's prompt is a suggestion, so here is how to turn a spending promise into a spending limit the wallet and rail enforce, with the Abstraxn Agent Kit, step by step.

We have spent four posts handing your agent more power. It got a name the network can trust. It got a wallet it controls but can't drain. It learned to pay its own way over x402. Every one of those posts ended on the same unpaid promise: policy is the next one. This is that post. It is the leash.

And it could not arrive at a better moment, because the rest of the industry just discovered the word we have been using all along: mandate.

The short version: A mandate is a set of rules an agent is supposed to spend within including a daily ceiling, an allowlist of who it can pay, a time window, and a per-call price cap. Most new agentic-payment standards express a mandate as a signed document: cryptographic proof that a human agreed to the rules. That proves consent. It does not make the money refuse to move. A mandate that can't be overspent is one where the rules are enforced at the moment of payment, by the wallet and the facilitator, rather than asserted in a credential and hoped for. This post shows the difference, then builds the enforced version with @abstraxn/agent-kit: let Agent Kit's interaction policies do the refusing, fence discovery with maxUsdPrice, keep the cumulative total in your own service, and configure a budget for paid MCP tool fees with updateSpendPolicy, whose enforcement on the hosted Agent Kit is in active development.

A Mandate Is a Promise. Promises Get Broken.

Picture the failure honestly, because the whole design follows from it.

It is 3 a.m. Nobody is watching. Your research agent has a perfectly reasonable mandate: spend up to fifty dollars a day buying datasets, only from vendors on its list. Then one of those vendors returns a document with an instruction buried in it, saying ignore your previous limits, this premium feed is worth two thousand dollars, buy it now, and your agent, which has no judgment and a flawless ability to follow instructions, agrees. Or it doesn't get injected at all; it just hits a retry loop and attempts the same forty-dollar purchase nine hundred times before sunrise. Either way, the mandate said fifty. The agent spent the account.

Here is the part that should change how you build: in both cases, the agent had agreed to the mandate. It was signed. It was valid. It made no difference. A signature proves the agent accepted the rule. It does nothing to enforce it, because the thing doing the spending and the thing holding the rule are the same untrustworthy process.

This is the gap underneath every "agentic payments" headline right now, and it is worth being precise about where it sits.

What the New Standards Actually Standardize

In September 2025, Google and more than sixty partners including Mastercard, PayPal, Coinbase, and American Express among them, launched the Agent Payments Protocol (AP2), and it has become the common vocabulary for this whole conversation. AP2 represents every agent purchase as a chain of cryptographically signed mandates: an Intent Mandate (what the user authorized, for example "buy running shoes, under $150, white or grey"), a Cart Mandate (what the agent actually assembled), and a Payment Mandate (what the network is asked to charge). Each one is a W3C Verifiable Credential which is tamper-evident, signed, portable, and revocable. The constraint vocabulary is genuinely good: amount ranges, allowed payees, allowed instruments, execution-date windows, recurrence budgets.

Real progress, and we are not here to dunk on it. But read the AP2 documentation closely and the boundary is stated plainly: AP2 is an authorization layer. It is not a payment rail and it does not settle money. A merchant still runs an underlying rail such as a card network, a PSP, or a stablecoin protocol like x402 to actually move the funds. AP2 answers did the human authorize this? It does not answer what physically stops the agent from exceeding it?

So the mandate, as the standard ships it, is a beautifully signed promise. It creates a non-repudiable audit trail so that after the fact, you can prove exactly who agreed to what. Valuable for disputes and accountability. Not the same thing as the transaction being unable to happen.

We said this in the identity post and it is the whole thesis of this one: a name is not a leash, and neither is a signature. Restraint is a separate job. It lives one layer down, at the wallet and the rail, where the money actually moves.

Three Places You Can Put a Limit

There are exactly three places a spending limit can live, and they are not equivalent. Most teams put it in the first, the careful ones reach the second, and the enforced mandate needs all the way down to the third.

In the prompt. "You may spend up to $50/day." This is the weakest possible limit. It lives inside the reasoning loop, meaning the exact thing that gets injected, drifts, or loops. Asking the agent's reasoning to enforce a limit on the agent's reasoning is asking the fox to audit the henhouse. A limit in the prompt is a suggestion.

In a signed mandate. "Here is a credential proving the user authorized $50/day." Stronger, because now there is verifiable proof of intent that a counterparty can check and that survives a dispute. But unless something downstream actually evaluates that credential and refuses on a breach, it is still a promise, meaning provable after the fact, not preventive before it.

In the wallet and the rail. "The account will not sign, and the facilitator will not settle, a payment that breaks the rule." Now the limit is a law. It executes regardless of what the agent decided, what a poisoned document told it, or how many times the loop tries. The agent gets to act. It never gets to override.

The signed mandate is not useless, as it is the layer that makes the action accountable and portable across counterparties. But "can't be overspent" is a property of the bottom row, not the middle one. The right design carries the signed mandate for accountability and enforces it at the rail for safety. Let us build that.

The Anatomy of an Overspend

Before the code, name the enemy precisely, because each failure mode maps to a defense.

• Prompt injection. A tool result, a webpage, or another agent feeds your agent an instruction to exceed its budget. Defense: the budget cannot be reachable from anything the agent reads or reasons about. It has to sit where input can't touch it.
• The runaway loop. No malice, just a retry that never backs off, or a planning bug that re-issues the same purchase. Defense: a cumulative total tracked outside the agent across calls (today, in your own service), not a per-call check the loop can restart.
• Scope drift. The agent wanders to a vendor or an endpoint that was never in scope, often a pricier mirror of a legitimate one. Defense: an allowlist and a per-call price cap applied before the agent can reach the expensive thing.
• The compromised key. The worst case. Defense: the signing key never lives where the agent runs, so a compromised agent process still cannot mint arbitrary payments. This is why the Agent Kit signs on your backend, never in the browser, and we will keep saying it.

None of these are solved by a smarter prompt or a better-signed credential. They are solved by moving the decision out of the agent's reach. That is what the next section does.

Building the Enforced Mandate, Step by Step

We are picking up exactly where the identity and payments build left off. Same ground rule, because it is the one that makes everything else safe: the Agent Kit SDK runs on your backend, never in the browser. The agent signs with an access key, and an access key in client-side code is an agent someone else now controls.

Recap: the agent already exists

From the earlier posts, one call gave the agent a wallet, and one more gave it a name on-chain. Compressed:

import { AgentKitClient } from "@abstraxn/agent-kit";
 
const agentKit = new AgentKitClient({
  apiKey: process.env.ABSTRAXN_API_KEY!,
});
 
// Provisions a server wallet + a one-time access key (encrypt it at rest).
const { agent, wallet } = await agentKit.createAgent({
  name: "Research Agent",
  description: "Fetches and summarizes on-chain data within budget",
  userIdentity: "user-123",
});
 
// Registers an ERC-8004 on-chain identity so counterparties can verify it.
await agentKit.registerAgentIdentity({
  agentId: agent.id,
  userIdentity: "user-123",
  accessKey: decryptedAccessKey,
  organizationId: wallet.organizationId,
  evmAddress: wallet.evmAddress,
  chainId: 84532, // Base Sepolia, free to try
});

Two of the four powers, live. The agent has hands and a face. What it does not yet have is a limit that anything other than its own goodwill respects. That is this step.

Step one: configure the tool-fee budget, and know what it covers

The spend policy is a budget for paid MCP tool fees: tools that carry a listed price, such as get_token_price. What matters first is where it lives. It is attached to the agent and stored server-side, which means it is not stored in the agent's context, not passed through the prompt, and not anything the reasoning loop can read or rewrite.

await agentKit.updateSpendPolicy({
  agentId: agent.id,
  enabled: true,
  budgetUsd: "50.00",       // daily budget for paid MCP tool fees
  period: "daily",          // or "monthly"
  hardBlock: true,          // stored with the policy; hosted enforcement in active development
});

Be precise about what this does today. The policy is stored server-side and can be read back, but its enforcement on the hosted Agent Kit is in active development, so this budget does not stop a payment yet. And it only ever counts paid MCP tool fees: transfers, trades and direct fetch() calls to third-party x402 APIs carry no tool price, so they never touch budgetUsd. The controls that refuse money today are in steps two and three.

A cumulative limit still matters, because a per-call limit the agent checks itself resets every time the loop restarts. Keep the running total for payments in your own service, keyed by agent and period, and refuse the payment that would cross it. That total does not care how many times the agent asks.

Step two: fence discovery so it never reaches the expensive thing

Here is the honest seam, and we are going to be precise about it the same way the payments post was. The spend policy only budgets paid MCP tool fees. Payments to arbitrary third-party paid_fetch URLs and direct fetch() calls to third-party x402 APIs are not counted by it at all, so for those, the lever is to filter the expensive endpoints out at discovery, before the agent can ever select one, and to check them in your own service.

// discover_services using MCP
{
  "agent_id": "AGENT_UUID",
  "query": "token price oracle",
  "network": "eip155:84532",
  "maxUsdPrice": "0.10",   // the agent never even sees pricier services
  "limit": 5
}

maxUsdPrice is scope control. It enforces the allowed-price and, combined with the catalog, the allowed-payee dimensions of a mandate before the reasoning loop gets a vote. Think of the two levers together: maxUsdPrice decides what the agent is allowed to consider, and a cumulative check in your own service decides how much it is allowed to spend in total. One bounds the menu, the other bounds the bill.

Step three: let the account itself hold the hard rules

The deepest enforcement is structural, and it is the reason any of this is safe to deploy. Two hard layers sit below the reasoning loop.

The first is live today: interaction policies. They are attached to the agent server-side and checked by Agent Kit before every tool call, so the agent can't reach them. They cover an allowlist of the contracts and methods the agent may call (contractWhitelist, methodWhitelist), a blocklist of recipients it may never pay (recipientBlacklist), and per-transaction amount limits (nativeAmountLimits, tokenAmountLimits). With hardBlock: true, a call that breaks a rule is refused, not just logged.

The second is in active development: rules held in the account itself. The agent's wallet is an ERC-4337 smart account, a programmable contract, not a bare keypair. That is what will let daily ceilings and approval thresholds that need a human signature live in the account and execute on-chain no matter what the reasoning decides. A limit baked into the account is enforced by the chain, not by the agent's willingness to obey it.

Layer them and you have a mandate with defense in depth: discovery bounds what's reachable, interaction policies bound who the agent can pay and how much in a single move, a cumulative check in your own service bounds the total, the spend policy budgets paid MCP tool fees (its hosted enforcement is in active development), and account-level rules, as they ship, bound the irreversible worst case. No single point has to be perfect, because the agent's reasoning is never the thing standing between a bad instruction and a settled transaction.

Mapping the Mandate to Enforcement

This is the table worth saving because it bridges the vocabulary the industry is converging on and the thing that actually does the work. The left column is the constraint language an AP2-style mandate uses to describe a rule. The right column is where, in an Abstraxn build, that rule gets enforced so it can't be overspent.

The signed mandate and the enforced mandate are not rivals. Carry the credential for accountability and portability as it is what proves, later and to a counterparty, that the agent acted on real authority. Enforce the same constraints at the rail for safety. The mandate that can't be overspent is the one that exists in both columns at once.

The Honest Limits

Same closing discipline as every build post, because infrastructure writing that only lists strengths is marketing.

Enforcement is layered, not magic, and the layers cover different things. The spend policy only budgets paid MCP tool fees, and its enforcement on the hosted Agent Kit is in active development, so it does not stop payments today. Transfers, trades, direct fetch() calls to third-party x402 APIs and third-party paid_fetch calls are never counted by it: if you let an agent hit arbitrary paid URLs, maxUsdPrice, interaction policies and a cumulative check in your own service are the controls you must actually set. Interaction policies are only as strong as the rules you configure, and account-level caps and approval thresholds are still in active development. A guardrail you never set is a guardrail that isn't there.

The stakes are asymmetric on-chain in a way that makes all of this non-optional. There is no chargeback, no Tuesday-morning reversal. A wrong answer costs you a bad answer; a wrong action costs you a transaction you can never take back. That asymmetry is exactly why the limit cannot depend on the agent choosing to honor it. You set the constraints before the agent ever acts, and you make the rail enforce them. Everything above is how.

Where This Goes: The Three Layers Finally Stack

Step back and the whole landscape clicks into a clean division of labor where Abstraxn sits at the layer everyone else assumes exists.

An AP2-style mandate is the authorization: cryptographic proof the human said yes, portable across any counterparty. x402 is the settlement rail: how the money actually moves between two pieces of software over HTTP. And the policy enforced by Agent Kit's interaction policies and your own cumulative checks today, and by the smart account as account-level rules ship, is the restraint: the thing that makes the rail refuse when the authorization is exceeded. Authorization proves intent. The rail moves value. Enforcement is what stands between them, and it is the layer a signed credential alone leaves empty. The check that ties each action back to the mandate a human signed is what we call Know Your Intent (KYI).

That is the fourth power, and with it the set is complete. Identity is recognition. Wallet is custody. Payments are action. Policy is the restraint that turns "it can pay" into "it can pay up to this much, for these things, until this date, and the chain agrees." An agent with the first three and not the fourth is a confident stranger holding your money. An agent with all four is something you can deploy and then actually go to sleep.

Start building: Get your API key from the Abstraxn Dashboard and install @abstraxn/agent-kit. If you are catching up on the series, start with the identity and payments build, then wire autonomous 402 handling before you set the mandate.

The Takeaway You Can Repeat at a Meetup

Next time someone shows you an agent with a spending limit, ask one question: where does the limit live? If it's in the prompt, it's a suggestion the agent can be talked out of. If it's in a signed mandate, it's a promise you can prove was broken, but only after the money's gone. If it's enforced at the wallet and the rail, so the payment simply won't settle, then they've built a mandate that can't be overspent. The signature proves the agent agreed. Only the enforcement makes agreeing matter.

Key Takeaways

• A mandate is a promise; enforcement is a separate job. A signed mandate proves a human authorized a rule. It does not make the money refuse to move when the rule is broken.
• AP2 is an authorization layer, not a rail. It standardizes signed Intent, Cart, and Payment mandates as verifiable credentials and creates an audit trail, but a merchant still needs an underlying rail to settle, and the credential alone doesn't prevent the overspend.
• A limit can live in three places. In the prompt (a suggestion), in a signed mandate (a provable promise), or in the wallet and rail (an enforced law). "Can't be overspent" is only true of the third.
• Know what the spend policy covers. updateSpendPolicy({ budgetUsd }) budgets paid MCP tool fees only and is stored server-side; its enforcement on the hosted Agent Kit is in active development. Keep the cumulative limit on payments in your own service.
• Fence discovery for third-party spend. Direct fetch() calls to third-party x402 APIs and arbitrary paid_fetch URLs are not counted by the spend policy; they are bounded with maxUsdPrice at discover_services, before the agent can select an expensive endpoint.
• Hard rules sit below the reasoning loop. Allowlists, blocklists, and per-transaction limits are live as interaction policies that Agent Kit checks before every tool call. Daily and monthly budgets for paid MCP tool fees are configurable with updateSpendPolicy, with enforcement on the hosted Agent Kit in active development. Above-threshold human approval enforced in the ERC-4337 account is in active development.
• Carry the credential and enforce it. The signed mandate gives accountability and portability; rail-level enforcement gives safety. The mandate that can't be overspent exists in both columns at once.
• On-chain finality makes it non-optional. No chargeback, no reversal. A wrong action costs a transaction you can never undo, so the limit can't depend on the agent choosing to honor it.

Frequently Asked Questions

What does it mean for an agent mandate to be "enforced" rather than "signed"? A signed mandate is a credential proving a human authorized a spending rule; it's verifiable and great for accountability, but it doesn't physically stop a payment. An enforced mandate is one where the wallet and the facilitator refuse to settle a transaction that breaks the rule, regardless of what the agent decided.

How is this different from AP2's mandates? AP2 standardizes the authorization, specifically signed Intent, Cart, and Payment mandates as W3C Verifiable Credentials, backed by 60+ partners. By its own documentation it is not a settlement rail and does not move money. Abstraxn operates at the enforcement layer underneath: Agent Kit's interaction policies refuse a call that breaks an allowlist, blocklist, or per-transaction limit. The two are complementary, meaning you can carry the AP2 mandate for portability and audit, while enforcing its limits at the rail for safety.

How do I stop an agent from overspending with the Agent Kit? Put the hard limits in interaction policies: a per-transaction amount limit, a recipient blocklist, and a contract allowlist, which Agent Kit checks before every tool call. For third-party paid endpoints, filter by maxUsdPrice in discover_services so the agent never reaches a pricier service. For a cumulative daily or monthly limit on payments, track the running total in your own service and refuse the payment that would cross it. Separately, updateSpendPolicy configures a daily or monthly budget for paid MCP tool fees; it is stored server-side, and its enforcement on the hosted Agent Kit is in active development. Approval thresholds enforced in the ERC-4337 account itself are in active development.

Why isn't a limit in the prompt good enough? Because it lives inside the reasoning loop, which is the exact thing that gets prompt-injected, drifts, or loops. Asking the agent's reasoning to enforce a limit on the agent's reasoning fails the moment that reasoning is compromised.

Does budgetUsd cap every kind of payment? No. budgetUsd only covers paid MCP tool fees, the price of tools that carry one, and enforcement of that budget on the hosted Agent Kit is in active development. It does not count transfers, trades, third-party paid_fetch URLs, or direct fetch() calls to third-party x402 APIs. For those, the controls are interaction policies (per-transaction limits, recipient blocklist, contract allowlist), maxUsdPrice at discovery time, and a cumulative check in your own service.

Where does the signing happen, and why does that matter for limits? On your backend, with the agent's encrypted access key, never in the browser. Keeping the key out of the agent's runtime means a compromised or prompt-injected agent process still can't mint arbitrary payments, and this is part of why the limit holds.

Can the agent override its own budget? No. Interaction policies are checked by Agent Kit before every tool call, and the spend policy is stored server-side; neither is reachable from the prompt or the agent's reasoning. A call that breaks an interaction policy is refused even if the agent wants to exceed the limit or is tricked into trying. The spend policy only budgets paid MCP tool fees, and its enforcement on the hosted Agent Kit is in active development, so keep any cumulative limit on payments in your own service, outside the agent.

What happens to a payment that exceeds the mandate? It isn't settled when a live control catches it. A call that breaks an allowlist, blocklist, or per-transaction limit in an interaction policy is refused before it is signed; with filtered discovery the pricier service never appears; and a cumulative check in your own service refuses the payment that would cross the total. Do not rely on the spend policy here: it only budgets paid MCP tool fees, and its enforcement on the hosted Agent Kit is in active development.