Should This AI Agent Be Allowed to Pay? Designing the Approval Layer Between Agents and Company Money

A member of the PinkWallet team outlined a design for an approval layer that sits between AI agents and company money, deciding per payment request whether an agent may pay. The proposed logic runs requests through ordered gates (registered, active, within budget, within daily ceiling, vault funded) and rules with first-match-wins decisions of ALLOW, ASK or BLOCK, defaulting to BLOCK for unmatched requests and declining any request whose human approval window times out. The design also attaches non-amount conditions such as matching purchase orders, signed briefs and warehouse scans, and flags payees whose bank details recently changed as a fraud control.

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: illustrative pseudo-policy, not our API 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 https://pinkwallet.com/agentic/learn/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 https://pinkwallet.com/agentic/learn/how-to-set-per-agent-spending-limits/ and a comparison of AI agent spend-governance tools https://pinkwallet.com/agentic/learn/ai-agent-spend-governance-tools-compared/ , plus a dataset we maintain: agent-spending-controls-crosswalk https://github.com/Pink-Agentic-Payments/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 https://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 https://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.