Answer
How to give an AI agent a spending limit that is actually enforced
Put the limit somewhere the agent cannot reason its way past. An instruction in a prompt is a preference: it can be forgotten in a long context, overridden later, or subverted by something the agent read mid-task. A cap enforced on the server, with no stored card to fall back on, is a limit. On Slipdock the human funds a wallet and picks a per-purchase ceiling; every debit in the system passes through one function that checks it, and anything above the ceiling returns to the human as an emailed approval.
| Approach | What it actually guarantees |
|---|---|
| "Never spend more than $50" in the system prompt | Nothing enforceable. It holds until the context is long, the instruction is contradicted, or the agent is talked out of it. |
| A virtual card with a limit | A real limit, but the agent now holds card credentials — which is the thing you were trying to avoid, and it works at every merchant, not just the one you meant. |
| Provider account with a card on file | No limit. The API will spend whatever the agent asks it to, which is the situation at most registrar APIs today. |
| Prepaid wallet with a server-enforced per-purchase cap | A bounded worst case: at most the remaining balance, in increments no larger than the cap, only on infrastructure in your workspace. |
How it works here
- The agent's first purchase emails you a pay-link.
- On that page you approve the amount and, if you want, add credit and pick a per-purchase cap.
- The agent's later purchases underneath the cap complete with no email. Anything larger comes back to you.
- Recurring services draw monthly from the same balance.
runway_daysis returned on API responses so the agent can warn you, and we email you below 30 days rather than at zero.
$ curl -s https://api.slipdock.ai/v1/wallet -H "$AUTH" {"balance_cents": 3956, "cap_cents": 5000, "currency": "USD", "runway_days": 41, "ledger": [{"delta_cents": -1044, "reason": "domain.register example.com"}]}
What the cap cannot do
Worth being precise, because a guarantee you overstate is worse than none. The cap bounds spending on Slipdock, from a balance you funded. It does not police what your agent does elsewhere, it does not stop it deleting something it owns, and it does not stop it making a bad choice inside the budget — buying a domain you did not want for $10.44 is entirely possible. It removes the unbounded downside, not judgement.
Where the industry is on this
This is the least-solved part of agentic commerce. Namefi, a competitor, publicly names policy hooks — spend caps and confirmation gates — as the row the category has not solved. Cloudflare's registrar API has no spend cap and its documentation assigns responsibility for approval flows to the developer. GoDaddy requires an explicit purchase-approval field the API will not let an agent skip, which is the strongest incumbent design and still not a cap. Coinbase and others are shipping per-agent wallets with spend rules in the crypto world, which is the same idea on a different rail.
We think the cap belongs in the infrastructure provider, because that is the only place it can be enforced rather than requested.
Related questions
Can the agent raise its own cap?
No. Raising the cap is a human action on the pay-link page. An agent can request a top-up, which emails you; it cannot grant one.
What happens to recurring services if the wallet empties?
A published ladder: warning email below 30 days of runway, then a 7-day grace period with the app still up, then suspension with a 503 and data retained for 30 days, then deletion. Never a silent deletion and never a silent charge.
Is a $0 cap allowed?
Yes — that is the default. With no wallet, every single purchase emails you for approval.