How Do I Give an AI Agent Its Own Wallet and Spending Limits?

We set one AI agent's monthly budget to $19,000, watched it spend $1,050 in two approved payments, then watched the next two payments get blocked for the same reason, "$18,890 used of $19,000, this would exceed it," with the real numbers to prove it.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.

Short answer: don't give the agent a wallet, give it a spending identity. A funded wallet or a private key is something an agent holds and can use anytime, for anything, until someone notices. A budget is something the agent asks against every time, that a server checks before money moves. Pink Agentic AI Payments gives each AI agent its own budget and checks every payment against company rules on the server, before it executes, so the limit lives outside the agent, not inside a key it's holding.

Wallet vs spending identity

A wallet is bearer access, if the agent has the private key or the card number, it can spend, and the only backstop is whatever the agent's own code decides to do. A spending identity flips that: the agent gets an account on the payment server, that account has a monthly budget and its own rules, and the agent never receives anything it can spend until a specific request clears those checks. Ask the server "can I pay $150," and if yes, you get one single-use, payee-locked credential, good for that payment, expiring in 15 minutes. There's no standing balance an agent can quietly drain over a weekend, because there's nothing sitting in its hands to drain.

We ran this with a real agent, "Eng Infra AI," for a fictional company, Calder Robotics, buying API credits and cloud capacity.

The budget object, before and after

A fresh pink.get_budget call for this agent, before we touched anything, returned:

{
  "agent": "Eng Infra AI",
  "monthly_budget": 25000,
  "spent_this_month": 17840,
  "left_this_month": 7160,
  "single_payment_cap": 1000,
  "company_daily_ceiling": 40000
}

That's the budget in one object: a monthly ceiling and how much of it is already spent. We tightened it with one call to PATCH /v1/admin/agents/a_eng, setting monthly to 19000 (we also set perPay to 500; more on that below). That endpoint is the only way to change the budget, there's no separate "wallet balance" to top up or drain, the budget itself is the only thing that moves. The agent record after the patch:

{
  "id": "a_eng",
  "monthly": 19000,
  "perPay": 500,
  "spentMonth": 17840,
  "status": "active"
}

$17,840 was already spent against the old $25,000 ceiling, so tightening the monthly number to $19,000 left only $1,160 of headroom for the rest of the month, something we confirmed before making any payment, not after.

A day window doing its job

The company also had a rule scoped just to this agent, visible through pink.list_rules, capping API-category purchases at $200 a day: "API credits: $200 a day per agent, then stop." We sent $150 to OpenAI for eval pipeline testing, and it cleared:

{
  "decision": "allowed",
  "payee": "OpenAI",
  "amount": 150,
  "rule": "API credits: $200 a day per agent, then stop",
  "credential": { "max_amount": 150, "locked_to": "OpenAI", "single_use": true }
}

A second request for $100 to Anthropic pushed the day's API spend to $250, over the $200 window, and the server blocked it before it got anywhere near a payment rail:

{
  "decision": "blocked",
  "payee": "Anthropic",
  "amount": 100,
  "rule": "API credits over $200 a day: blocked",
  "credential": null,
  "why": "matched · block"
}

That's a day-window rule doing exactly what it's for, a ceiling that resets daily and exists independent of the monthly budget. A $900 AWS invoice went through separately under a different rule for cloud invoices that match a billing statement, bringing the day's total spend to $1,050.

Note that the $900 cleared even though we had set perPay to 500. In the current sandbox, perPay is shown to the agent as single_payment_cap but the engine doesn't enforce that field on its own. A hard per-payment limit is an amount rule with window tx, scoped to the agent. We'd rather show you that than hide it.

When the monthly budget runs out, everything stops, regardless of size

With $18,890 of the $19,000 monthly budget used, we sent two more requests: a $200 AWS line item, and a $1,500 laptop purchase from Dell for a new engineer. Both came back blocked, with identical reasoning:

{
  "decision": "blocked",
  "payee": "Amazon Web Services",
  "amount": 200,
  "rule": "Eng Infra AI's monthly budget is used up",
  "credential": null,
  "why": "$18,890 used of $19,000 · this would exceed it"
}

{
  "decision": "blocked",
  "payee": "Dell",
  "amount": 1500,
  "rule": "Eng Infra AI's monthly budget is used up",
  "credential": null,
  "why": "$18,890 used of $19,000 · this would exceed it"
}

Notice the Dell laptop would otherwise have qualified for a different rule entirely, a mid-size purchase that normally routes to the CFO for a yes or no. It never got that far, the monthly ceiling for this specific agent is checked ahead of that, and once it's exhausted, nothing clears for this agent until the next billing cycle or a human raises the number. The final get_budget call for the day confirmed it: "left_this_month": 110, "spent_today": 1050.

Where human approval fits, briefly

Some requests in this same rule set don't resolve to allow or block at all, they come back pending_human and sit with a named approver until someone acts. That's a separate layer from the budget, approval bands decide who signs off on a given amount; the budget decides whether the agent gets to ask in the first place. This post is about the budget, not the approval chain.

The actual contrast

Compare this to handing an agent a raw card number or a wallet's private key. There, the limit exists only if the agent's own code enforces it, and a bug, a prompt injection, or a bad tool call bypasses it instantly because the agent is the thing holding the money. Here, the agent asked for $1,500 and the server said no on its own, the agent's code didn't have to get that check right, because it never had the option to skip it.

Try it

Spin up a free sandbox workspace with test money, no signup required: POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=agent-wallet-spending-limits. Full docs at pinkwallet.com/agentic/developers. The same kind of rules (budgets, amount and payee rules, approval chains) also run in production as a decision layer: your agent asks Pink first, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. A pilot on your own production tenant is $99/month: pinkwallet.com/agentic/pilot.