The problem

You have given an AI agent the ability to pay, a funded wallet and a way to settle payments, and it works. But nothing bounds how much it can spend. In principle, the agent could spend the whole wallet balance, in one payment or across many, because there is no enforced limit between it and the funds. Nothing has gone wrong yet, but nothing would stop it if it did.

This is the no-spending-controls problem, and it is a latent risk rather than an active incident. The agent pays correctly today, so it is easy to leave the gap unaddressed. But an agent with payment ability and no limit is one bug or one manipulation away from spending far more than intended, with nothing to catch it. The symptom is an agent that can pay without any cap on what it pays, and the fix is to put the cap in place before it is needed.

Why it is dangerous

The danger comes from the fact that agents can be wrong or manipulated. An agent reasons over inputs, and those inputs can be malformed, adversarial, or simply lead it astray. A bug in its logic, a confusing task, or a prompt injection, where an attacker plants instructions in content the agent reads, could direct it to spend far more than you intended, or to pay the wrong party. With no enforced limit, there is nothing between that bad instruction and the wallet's full balance.

What makes this particularly hazardous is that the risk is invisible until it triggers. An unbounded agent looks fine right up until the moment it overspends, at which point the damage is whatever the balance allowed. So the absence of controls is not a problem you will notice in normal operation; it is a problem you discover the hard way. That is exactly why controls should be put in place proactively, as a safeguard against the day something goes wrong, rather than added after an incident.

The fix

The fix is a server-side spend policy: a per-transaction cap and a period allowance on the agent's wallet. The per-transaction cap is the most the agent can spend in a single payment; the period allowance is the most it can spend over a window such as a day, a week, or a month. Set these in the dashboard, and the system enforces them: a payment that would exceed the cap or the remaining allowance is refused, regardless of what the agent was told or tricked into.

This caps the worst case in advance. The agent keeps paying freely within the bounds, so normal operation is unaffected, but the balance beyond the limits is protected even if the agent misbehaves. Crucially, the policy is enforced server-side, where the agent cannot reach it, so it is a real control rather than a request the agent might ignore. The no-controls problem is solved by adding exactly the enforced bound that was missing, which is the difference between an agent that can spend and one that can overspend.

How to set it up

Setting up the spend policy is done in the dashboard, not in code. You configure the agent's per-transaction cap and its period allowance, expressed in USDC, choosing a window such as a day, a week, or a month. Once saved, the policy takes effect immediately, and the agent's payments are bounded by it from that point. There is no change to the agent's own code; the control lives on the wallet.

The agent can read its current limits through a GET to its spend-permissions endpoint, which lets a planner reason about budget, but it cannot change them, the policy is read-only through the API and edited only in the dashboard. That read-but-not-write design is what keeps the control in your hands. The step-by-step is in how-to-set-up-agent-spending-limits, and the concept behind it in what-is-an-agent-spend-policy. The point is that establishing controls is configuration you do once, not a development task.

Verify it works

Confirm the controls actually bind before relying on them. On Base Sepolia with a sk_test_ key, set a low per-transaction cap and have the agent attempt a payment above it; the payment should be refused, not completed. Then have it make a payment within the cap and confirm that one succeeds. That pair of tests, over-limit refused, within-limit allowed, proves the policy is enforced rather than merely configured.

For the period allowance, run several payments that together approach the allowance and confirm that a payment which would exceed the period total is refused even though each individual payment is under the per-transaction cap. If an over-limit payment goes through, the policy may not be set on the right agent or wallet, recheck the dashboard. Once both the per-transaction and period bounds demonstrably refuse excess, the no-controls problem is fixed: the agent is now bounded, and you have seen the bound hold.

Why server-side, not the prompt

It is worth being explicit about why the control must be server-side rather than in the prompt, because the temptation to just tell the agent its budget is strong. A budget in the prompt is a suggestion the agent may follow, but it lives in the same space the agent can be manipulated, so a prompt injection or a reasoning slip can override it. A prompt budget fails exactly when you need it, under attack or error.

A server-side spend policy does not depend on the agent's cooperation. It is enforced outside the agent's reach, so it holds whatever the agent is told or tricked into, and a compromised agent's overspending is refused at the policy bound. This is the whole reason the fix is a server-side policy and not a prompt instruction: security that relies on the agent behaving is not security. For an autonomous agent that can be wrong or manipulated, the enforced, out-of-reach control is the only kind that actually protects the balance, which is why it is the right and only real fix.

Make controls the default, not an afterthought

The deeper fix for no spending controls is to make setting a spend policy part of how you create every agent, not something you remember later. If provisioning an agent and funding its wallet always includes setting a per-transaction cap and a period allowance, then no agent is ever unbounded, and the latent risk never accumulates across your fleet. Treating the spend policy as a required step in onboarding an agent, like setting a password, removes the gap entirely.

This matters more as the number of agents grows. One unbounded agent is a manageable oversight; a fleet of them is a standing liability you may not even have inventoried. So beyond fixing the agent in front of you, adopt the habit: every agent gets a spend policy at creation, sized to its role, tightened for new or risky agents and loosened for trusted ones. That way the no-controls problem is solved not just once but by default, and you never have to discover an unbounded agent the hard way.

Related reading

If your agent has no spending controls, the fix is quick and worth doing before anything goes wrong. The step-by-step setup is in how-to-set-up-agent-spending-limits, and the concept is defined in what-is-an-agent-spend-policy. Together they take you from an unbounded agent to a bounded one in a few minutes of configuration. Pricing is on the pricing page.