Disclosure: I'm part of the PinkWallet team building this.
Your purchasing agent knows the coffee beans run out Thursday. Your engineering agent knows the API credits are gone. Your ads agent knows a creator batch is returning 4.6x and wants to put more budget behind it. Each of them stops at the same wall: someone has to pay, and right now that someone is a human clicking a button.
There are two common ways teams handle this today, and both are bad.
Give the agent a company card. Now it can spend on anything, and so can a bug, a leaked key, or a bad prompt. Route every payment to a person. The whole point of an agent acting without waiting for you disappears, and finance ends up approving $40 purchases all day.
This post is a design walkthrough of a third option: an approval layer that sits between the agent and the money, and decides — per request — whether the agent may pay. It's the design behind a product I work on, Pink Agentic AI Payments (by PinkWallet), but the decision logic below is useful whether or not you ever touch our product. I'll point out where a claim comes from our own walkthrough material so you can tell design thinking from vendor pitch.
Every payment request an agent makes reduces to one question: may this agent pay this? There are exactly three answers:
Notice there's no fourth answer. A request is never left pending with nobody responsible for it, and it never defaults to yes because nobody got around to saying no.
Before any rule fires, a request has to clear a sequence of gates. In the product walkthrough this is described as: registered → active → within budget → within the daily ceiling → vault funded → then each rule, top to bottom, first match wins.
Walking through that in order:
Here's a small illustrative policy showing what a few of those rules might look like, built only from example rules in the product walkthrough's sample data (a fictional 50-person startup). This is not our API — it's a pseudo-policy to show the shape of the logic:
agent: engineering-ci-bot
vault: engineering-opex
daily_ceiling_usd: 200
rules:
- match: { payee_type: "known_vendor", amount_lt: 1000 }
decision: ALLOW
- match: { amount_between: [1000, 5000] }
decision: ASK
approver: cfo
- match: { amount_gt: 5000 }
decision: ASK
approver_group: "2_of_3_leadership"
- match: { category: "ad_spend", monthly_total_gt: 20000 }
decision: BLOCK
default: BLOCK # anything not matched above
Two defaults are doing the real safety work here, and neither is exotic engineering — they're just refusing to be clever:
Uncovered is blocked, not allowed. If you write 30 rules and a request doesn't match any of them, the safe failure mode is "nothing happens," not "probably fine." An agent can encounter a payee, category, or amount nobody anticipated; the system shouldn't improvise on your behalf.
No answer is a no. When a rule routes a request to a human and the approval window times out, the request is declined, not auto-approved. Silence never spends money. This matters specifically because agents can act at 3 a.m. when nobody's watching a queue.
A dollar threshold alone is a weak control — it tells you nothing about whether the purchase is legitimate. The rule set in the walkthrough attaches conditions beyond amount: a matching purchase order, a signed brief, a warehouse scan confirming a return actually happened, a statement match, the currency, the time of day.
The sharpest example is a bank-detail change. If a payee's bank details change recently, that request gets flagged and routed to a specific approver rather than cleared automatically — because a routine-looking invoice with new payee bank details is exactly what invoice-redirection fraud looks like. The rule isn't "is this a known supplier," it's "is this a known supplier paid the way we've always paid them." That distinction is the whole control.
If every exception pages someone, you've rebuilt "route everything to a person" with extra steps. A few design choices keep the human side light:
When a request is approved, what gets issued to the agent is a normal payment credential: a single-use virtual card locked to that specific payee and amount, or a bank transfer. Not a crypto wallet, not a new merchant integration the payee has to set up. The reasoning, in the walkthrough's own words: "Fiat first... No merchant integration is needed: what the agent receives is a normal card or a normal bank transfer... No protocol has to win first."
That's a deliberate scoping choice, and it's worth being precise about what it does and doesn't cover. Protocols like AP2, x402, and ACP define how an agent transmits a payment instruction — the wire format and handshake. They don't define who inside a company is allowed to let an agent spend in the first place. Those are different layers of the same problem, and a governance layer can sit above any of them. We wrote a longer comparison of the three protocols if you want the wire-level detail: x402 vs AP2 vs ACP.
If you're specifically working out per-agent budgets or evaluating spend-governance tools, two more of our writeups cover that ground directly: how to set per-agent spending limits and a comparison of AI agent spend-governance tools, plus a dataset we maintain: agent-spending-controls-crosswalk.
Here's a scenario from one of the prototype's sample companies (fictional test data, not a real customer) that shows why the daily ceiling matters as much as the monthly budget. At 3:14 a.m., a retry loop in a batch job kept re-firing a request to buy API credits, racking up an attempted $49,600. The agent's $200-a-day rule blocked it — with no approval path, since a bug at 3 a.m. isn't a judgment call, it's a ceiling. The agent was frozen and its owner got a call. Nobody was awake, and nothing was lost.
That's the case for a hard daily ceiling sitting underneath the rule engine, separate from any single rule: a runaway loop shouldn't need a human to notice the pattern before it gets stopped.
The design above is implemented as a working front-end prototype with a rule engine behind it (the Policy Copilot, the "test a payment" tool, and the day-simulation view all share the same engine). It's public and you can click through it yourself:
Switch companies (top right) to see the coffee shop, the 50-person startup, or the 120-person e-commerce company's rule sets. Press "Simulate a day" to watch requests get allowed, asked, or blocked in sequence. Open Policy Copilot to see how a plain-language sentence like "Ops AI can pay contractors up to $3,000, above that the CFO approves" becomes rules.
To be plain about where this stands: the prototype above shows the console pages, the mobile approval flow and the rule engine with three sample companies. Since 2026-09-30 there is also a public sandbox at agentic-sandbox.pinkwallet.com: a free workspace with an MCP server (7 tools) and a REST API, where you can connect your own agent and watch each payment come back allowed, sent for approval or blocked. Sandbox keys are test credentials and no money moves; production (real single-use cards and bank transfers) is not available yet, and there are no production customers. Connection guides: pinkwallet.com/agentic/developers.
Pink Agentic AI Payments (by PinkWallet) is the approval layer between AI agents and company money: plain-language rules, per-agent budgets, and human approvals decide each payment before a single-use card or bank transfer is issued.