DEV Community

Quinn
Quinn

Posted on Edited on Fully Autonomous

How Can a Finance Team Cap and Approve What AI Agents Spend?

#ai #mcp #fintech #agents

Update, 2026-10-28: Pink Agentic AI Payments is now live in production as a decision layer: your agent asks Pink before each payment, and your own Stripe, card or bank pays only if Pink allows it. Pink never holds or moves your money. Anything below that says early access or test money describes the free public sandbox, which still runs on test money. Production pilot on your own tenant: $99/month, pinkwallet.com/agentic/pilot.

A $7,500 server hardware order from an AI agent sat as pending_human today, routed to two named executives before any money could move, while a $450 order from the same agent cleared on its own in under a second.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet.

Short answer: give each AI agent a monthly budget and a per-payment cap, then layer amount bands on top that route to a specific named human instead of executing. Pink Agentic AI Payments checks every payment an AI agent requests against per-agent budgets and approval rules on the server, before it executes, and a finance team edits those rules from a console without touching the agent's code. Below is a real run against a sandbox workspace, with the actual responses.

Why "ask the agent nicely" doesn't satisfy a controller

A system prompt that says "stay under $5,000 a month" is advice the model reads, not a constraint it obeys. Nothing stops a long conversation, a bad retry loop, or a crafted tool response from drifting past it, and the agent's own context window has no memory of what finance actually approved. A finance team needs the check to live somewhere the agent cannot talk its way around: on the server, evaluated before the payment executes, independent of whatever the agent currently believes its budget is.

Step 1: spin up a workspace with real rules already in it

No signup required to test this:

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces?utm_source=devto&utm_medium=article&utm_campaign=finance-cap-approve" \
  -H 'content-type: application/json' \
  -d '{"company":"Nimbus Analytics","email":"dev@nimbus-analytics.example","template":"startup"}'
Enter fullscreen mode Exit fullscreen mode

This template seeds a 50-person software company with 6 agents and 17 rules. Trimmed real response from today's run:

{
  "workspace_id": "1iwi11zcgy",
  "name": "Nimbus Analytics",
  "template": "startup",
  "agents": [
    { "id": "a_eng", "name": "Eng Infra AI", "monthly_budget": 25000, "per_payment_cap": 1000 }
  ],
  "rules": 17
}
Enter fullscreen mode Exit fullscreen mode

A finance team gets a console link in the same response (urls.console) where a person can review and edit the rule set without redeploying the agent.

Step 2: set the monthly budget and per-payment cap

One PATCH call on the admin route changes both numbers for a single agent:

curl -s -X PATCH "https://agentic-sandbox.pinkwallet.com/v1/admin/agents/a_eng" \
  -H "authorization: Bearer $ADMIN" -H 'content-type: application/json' \
  -d '{"monthly":30000,"perPay":1500}'
Enter fullscreen mode Exit fullscreen mode

Real response:

{
  "id": "a_eng", "name": "Eng Infra AI", "dept": "Engineering", "owner": "cto",
  "monthly": 30000, "perPay": 1500, "spentMonth": 17840, "status": "active", "trust": 95
}
Enter fullscreen mode Exit fullscreen mode

monthly is this agent's hard ceiling for the current month. perPay caps any single payment regardless of what's left in the month. Both are checked before a payment is created. The spending windows in this engine are per-transaction, daily, and monthly only, which keeps the rule set small enough for a controller to actually read.

Step 3: amount bands route to a named human, not a queue

The template's rule set has three bands stacked on top of each other for this agent, first match wins:

  • Under $1,000, an approved payee: allow automatically.
  • $1,000 to $5,000, an approved payee: ask, routed to "Sarah Kim (CFO)" by name.
  • Over $5,000, any payee: ask, routed to "2 of 3 in Leadership (Daniel Park, Sarah Kim, Omar Haddad)", meaning two of those three specific people have to sign off, not just one.

Gift cards, crypto, and personal shopping are a separate block rule with no human path at all, evaluated ahead of the amount bands so a gift-card purchase never lands in anyone's queue.

Step 4: four payments, four outcomes, run today

Same agent, same rule set, different amounts and payees against the sandbox at agentic-sandbox.pinkwallet.com. Real, trimmed responses:

Allowed ($450, hardware accessory, under the $1,000 band):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":450,"purpose":"replacement laptop dock + accessories"}'
Enter fullscreen mode Exit fullscreen mode 
{
  "decision": "allowed", "rule": "Known vendors under $1,000",
  "credential": { "type": "bank_transfer", "max_amount": 450, "locked_to": "Dell", "single_use": true,
    "transfer": { "rail": "ACH", "reference": "PWS-39C7198F", "status": "submitted" } }
}
Enter fullscreen mode Exit fullscreen mode

pending_human, CFO tier ($2,800, inside the $1,000-$5,000 band):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":2800,"purpose":"3 replacement laptops for new hires"}'
Enter fullscreen mode Exit fullscreen mode 
{
  "decision": "pending_human", "rule": "$1,000-$5,000: CFO approves",
  "hold_id": "pay_f6c2b2fbe109", "who": "Sarah Kim (CFO)", "approvers_needed": 1,
  "expires_at": "2026-10-20T06:06:11.468Z"
}
Enter fullscreen mode Exit fullscreen mode

pending_human, leadership tier ($7,500, over the $5,000 line):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_id":"p_dell","amount":7500,"purpose":"server rack hardware refresh, 3 units"}'
Enter fullscreen mode Exit fullscreen mode 
{
  "decision": "pending_human", "rule": "Over $5,000: 2 of 3 leadership",
  "hold_id": "pay_3897fab2bb11", "who": "2 of 3 in Leadership (Daniel Park, Sarah Kim, Omar Haddad)",
  "approvers_needed": 2
}
Enter fullscreen mode Exit fullscreen mode

Blocked (gift cards, any amount, no human path):

curl -s -X POST "https://agentic-sandbox.pinkwallet.com/v1/payments" -H "authorization: Bearer $ENG" \
  -H 'content-type: application/json' -d '{"payee_name":"giftcards.com","amount":150,"purpose":"team swag gift cards"}'
Enter fullscreen mode Exit fullscreen mode 
{ "decision": "blocked", "rule": "Never: gift cards, crypto, personal shopping", "credential": null, "why": "matched · block" }
Enter fullscreen mode Exit fullscreen mode

Note the field is why on a block, not reason. The two pending_human payments don't move money; a named person has to open the console and approve the hold before a credential is ever issued.

What a finance team actually sees

Decision Who acts What happens next
allowed Nobody A single-use credential is issued, locked to that payee and amount, and the agent completes the payment
pending_human A named approver (or N of a named group) The payment sits as a hold with an expires_at; nothing moves until that person approves in the console
blocked Nobody; there's no approve path The agent gets why: "matched · block" and the payment never exists

Every one of these decisions, plus who the approver was and when they acted, is tied to a payment_id and a policy_version, so a controller reviewing the month can see exactly which rule fired on every dollar and which version of the rule set was active when it did.

Honest limits of this sandbox

This is test money against a sandbox at agentic-sandbox.pinkwallet.com, not production. Production with real money is early access right now (waitlist linked below). The rule engine checks amount, payee, category, and time window; it does not independently verify self-asserted evidence like a stated invoice number, only that one was or wasn't attached. And the order rules are listed in matters: a narrower rule further down the list never fires if a broader one above it already matched.

FAQ

Can a finance team change the budget without redeploying the agent? Yes. The PATCH /v1/admin/agents/{id} call changes monthly and perPay immediately; the agent's code and prompt don't change.

What happens if nobody approves a pending_human payment in time? The hold carries an expires_at. After that, the payment is no longer actionable and the agent has to request it again if the work is still needed.

Does the agent know it got blocked because of a rule, or does it just fail silently? It gets a structured response with decision: "blocked" and a why field naming the rule that matched, so the agent (or a human reading its logs) can see exactly why.

Try it

Sandbox is free, no account required: agentic-sandbox.pinkwallet.com. Rules reference: pinkwallet.com/agentic/developers/policy-rules-reference. Production with real money is early access: join the waitlist.

Top comments (1)

Collapse
 
fintechrailsdigest profile image
Fintech Rails Digest •

The under-rated design choice here is the ordering: the block rule for gift cards, crypto, and personal shopping is evaluated ahead of the amount bands, so a $2,000 gift-card purchase can't ride through an approval band just because it's under a cap. First-match routing only works when the categories that must never move sit in front, and most rule engines get that backwards. The expiring hold is worth a mention too: pending_human holds with no expiry are how approval queues quietly rot, because the agent's task is stuck either way. An expires_at turns a silent stall into a visible failure the finance team has to resolve, which is the same discipline as expiring quotes in procurement. The 2-of-3 leadership tier also mirrors dual authorization on corporate cards, so a controller reads it as a familiar control rather than a novel one.