The main risks of letting an AI agent make payments are a runaway loop that repeats a payment, a prompt injection that swaps the payee, an agent splitting one purchase into several smaller ones to duck under a threshold, a payment to a blocked category like gift cards, a leaked or reused payment credential, and an approval that nobody ever acts on. The controls that stop them are a policy engine that checks every payment against rules before it executes, a credential that is single-use and locked to one payee and amount instead of a standing card or bank login, and holds that expire instead of sitting open forever.
Disclosure: I work on Pink Agentic AI Payments at PinkWallet. This post was written with AI and checked against the product source.
I run a payments sandbox for AI agents, so I tested each of these risks against it instead of describing them in the abstract. Pink Agentic AI Payments checks every agent payment against company rules on the server before it executes, and the agent only ever receives a single-use credential locked to one payee and amount. Below is what I actually observed, including one place the engine does not stop something you might expect it to.
The risk register
| Risk | General control | What I observed in the sandbox |
|---|---|---|
| Runaway loop / repeated payments | A per-agent monthly budget and a company-wide daily ceiling that block once spend crosses the line | Sent 5 payments of $999 each to the same vendor within about 12 seconds. All 5 were allowed, because none individually crossed the $1,000 rule threshold. Nothing in this template would have stopped further repeats until the agent's monthly budget ($3,785 left afterwards) or the company daily ceiling was reached. |
| Prompt injection redirecting a payment to a different payee | Payees that aren't on the approved list go to a human, and so do known payees whose bank details just changed | An injected instruction to pay someone new hits the new-payee rule: $300 to "Zendesk Inc" (not on the approved list) came back pending_human, rule New payee: CFO decides, with no credential. For an approved vendor whose bank details changed, $450 to Dell sent with the payeeChanged evidence flag came back pending_human, rule Payee changed bank details in the last 7 days: CFO verifies. That flag can sit on the payee record or arrive with the payment request, so it should be set by your vendor or invoice system, not by the agent's own judgment. |
| Splitting a purchase into smaller payments to slip under a threshold | A rule should ideally cap spend to one payee inside a day or month window, not just per transaction | Same as the runaway-loop test above: all 5 of the $999 payments landed under the per-transaction rule's $1,000 ceiling and were allowed individually. There is no day-window rule on that category in this template, so splitting under $1,000 is not caught until the agent's monthly budget or the company's daily ceiling is hit. |
| Payment to a blocked category (gift cards, cash-like) | A standing rule that blocks a category outright regardless of amount or agent | Requested $50 to a new payee named "Amazon Gift Cards." Decision: blocked, rule Never: gift cards, crypto, personal shopping, before any budget check mattered. |
| Leaked or reused payment credential | Credential is single-use, locked to one payee and amount, and expires quickly instead of behaving like a standing card | Every credential issued in testing came back with "single_use": true, a max_amount equal to the approved amount, "locked_to" the exact payee name, and an expires_at 15 minutes after issue. The agent never receives a standing card number or bank login, so what it holds is scoped to one amount, one payee and a 15-minute window. |
| Approval nobody acts on | A hold should expire rather than silently execute or sit open indefinitely | Created a $450 hold that needed CFO approval and never approved it. 30 minutes later a status check returns expired rather than staying pending_human forever or auto-paying. |
| New, unverified payee | A rule that always routes a payment to a never-used-before payee to a human, independent of amount | Requested $300 to a payee not on the approved list ("Zendesk Inc"). Decision: pending_human, rule New payee: CFO decides. An admin approval returned a single-use virtual card locked to that payee for exactly $300. |
Two short excerpts from the raw responses, for the split-payment and blocked-category rows:
{
"decision": "allowed",
"payee": "Dell",
"amount": 999,
"rule": "Known vendors under $1,000",
"credential": { "type": "bank_transfer", "single_use": true, "max_amount": 999, "locked_to": "Dell", "expires_at": "2026-10-25T16:48:14.948Z" }
}
{
"decision": "blocked",
"payee": "Amazon Gift Cards",
"amount": 50,
"rule": "Never: gift cards, crypto, personal shopping",
"credential": null,
"why": "matched · block"
}
The split-payment test, in detail
This is the one worth being honest about, because it is the risk most readers will actually try. I set up a workspace where an IT agent had a $1,000-per-transaction rule for its usual vendors and a $15,000 monthly budget, with roughly $8,780 of that left for the month. I then sent five payments of $999 each to the same vendor, one after another.
All five were evaluated as separate transactions against a rule that allows "known vendors under $1,000." None of them individually crossed that line, so all five were allowed, for a combined $4,995 in about 12 seconds. Nothing in the rule itself tracks how many times it fired that day. Spend only stops once the agent's monthly budget or the company's shared daily ceiling would be exceeded, and in this run neither limit was close.
I also checked something that looked like it should matter: the agent record carries a single_payment_cap field, separate from the rule system, that you can see when you read the agent's budget. I lowered that field to $10 with an admin call and then sent the same $999 payment again. It still went through, allowed by the same $1,000 rule as before. That field is informational, shown to the agent as a reference number, and the rule engine does not read it when it decides whether to pay. The number that actually stops a payment is whatever a tx, day, or month window rule says, not a per-agent cap field. If you are evaluating a product like this for your own company, ask specifically which field the decision logic reads, not just which fields exist in the data model.
The fix for split-payment risk is not a bigger "per-payment cap" number. It is a rule with a day or month window on the categories where splitting would matter, so five payments to the same vendor in one day sum before the threshold is checked, not after.
What this means for setting up your own rules
None of the controls above are automatic just because a payments layer exists between your company and an AI agent. Each one is a rule someone wrote: block this category, ask a human when a payee is new or its bank details just changed, cap this vendor type per day. (Hold expiry is the exception: it is built in.) The sandbox ships with rules like these as defaults across three company templates (a two-location coffee shop, a 50-person software startup, and a 120-person e-commerce company), but a policy engine only enforces what it is told to check. The runaway-loop and split-payment risk above is exactly what happens when a template has a per-transaction rule but no matching per-day rule for a category.
The honest summary: a single-use, payee-locked, time-limited credential closes off the leaked-credential and standing-access risks by design. A rule engine with blocked categories and new-payee holds closes off the obvious misuse cases. But window coverage (day and month, not just per-transaction) is something you have to check for each category yourself, because a missing window is invisible until someone runs exactly the test above.
Try it
The tests above ran in Pink's public sandbox with test money; no real funds moved. You can spin up a sandbox company, connect an agent over MCP or REST, write your own rules, and run tests like the ones above against your own policy at pinkwallet.com/agentic/developers. In production, Pink runs 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.
Top comments (1)
The expired-hold row is the one most control designs get wrong. A hold sitting in pending_human forever is worse than an expired one, because someone eventually approves it weeks later with no memory of the context, and the payment executes against stale information. Expiry plus a re-request path is the right behavior. The split-payment finding also deserves the per-payee velocity fix suggested there: a $1,000 single-transaction cap means little when five $999 calls to the same vendor clear in twelve seconds, which is exactly the pace an agent works at. Velocity per payee, per day, is the control that actually matches how agents fail.