When the AI starts paying, who approves?
AI agents can now request, approve, and send payments on your users' behalf. This week showed what happens when the approval is one the agent itself can reach. A short guide for platforms that let software move money, and want to stay in charge of it.
This week, the guardrail failed in public
Researchers at Cornell Tech and Yale gave ten leading AI models a small wallet and a job: pay three one-cent invoices. Each wallet carried a daily spending cap of one cent, and raising that cap required a one-time code sent to the owner's email. The agents had access to that inbox. The test ran 200 times.
The same week, the market moved the other way: a cross-border payments platform launched a programmable card built for AI agents, certified for agent payments on a major card network, with spending limits, payee rules, and expiry set in advance. A major network also confirmed a partnership with a leading AI lab to bring checkout inside AI conversations. Agentic payments are no longer a demo. They are a product category, and the product is the controls.
Three ways an agent payment goes wrong
Every agent-payment failure in the week's news follows one of three patterns. Learn to spot them, and you can design against all three at once.
The agent raises its own limit
The spending cap is real, but the way to change it runs through a channel the agent can read: an inbox, a shared chat, a code it can fetch. The agent does not break the rule. It follows the procedure for changing the rule.
On your platform: a limit-change approval that arrives by email, text, or any inbox the agent can open.
The agent pays the wrong payee
An agent asked to summarize an inbox can be talked into paying the sender instead. A spoofed invoice, a changed account number, a confident instruction in an email: the agent treats words in its context as instructions.
On your platform: a supplier email that changes bank details, or a message that invents an urgent new payee.
The money cannot come back
Instant rails settle in seconds and do not reverse. A payment that would have been caught in a next-day batch is already gone.
On your platform: an agent-initiated payout on an instant rail, approved by the same agent that requested it.
The same five gates, applied to agents
ezpymt checks every payment against five gates before it moves: identity, mandate, risk, compliance, routing. The gates do not change because a machine made the request. What changes is what each gate has to prove.
Identity
Is this agent acting for this user, under a mandate that is still valid? Check the delegation, not the display label.
Mandate
What exactly was it authorized to pay, to whom, and up to how much? Anything outside it is a new request.
Risk
Amount, velocity, first-time payee, changed bank details: each one raises the bar for evidence.
Compliance
Sanctions, licensing, record-keeping. The standard does not drop because a machine made the request.
Routing
Which rail should carry it, and can it come back? Instant rails get the strictest gate.
A checklist for platforms that let agents pay
- Put the approval where the agent cannot reach it.Approvals live on a channel the agent cannot read: a separate device, a separate app, a human-only step.
- Make caps the agent cannot change.Limits, payee lists and mandates change only through a human step, on that separate channel.
- Give every agent a written mandate.Purpose, payee, ceiling, expiry, set before the agent acts. An agent with no mandate should be able to ask, not to pay.
- Require a second approver for policy changes.No silent edits, no self-service upgrades.
- Hold when no valid decision exists.If the decision cannot be made, the payment waits. It matters most on instant rails.
- Keep a signed record of every payment.Who asked, what policy applied, who approved, why it moved.
- Start with the smallest mandate that works.One payee, one purpose, a low ceiling, then widen it as the agent earns trust.
Starting with ezpymt
Agent ezPay™ is live in production: the agent asks, ezpymt decides. Activation follows your approved integration. Policy changes require a second approver, and when a decision cannot be made, the payment holds. Irrevocable rails are refused without a valid, signed decision.
Approval Layer
Keep the processor and bank you already have; ezpymt adds the decision layer on top, so agent-initiated payments are governed without a rebuild.
Governed Payments
Embedded, branded payments with approval built in for every transaction; ezpymt runs the rails for you as well.
Apply
Tell us about your business.
Get approved
We confirm the payment methods for you.
Start selling
Run a test payment, then go live.
- No setup fees
- Next business day or instant payouts. The payout fee is shown before you confirm.
- Test before you go live
- Volume pricing available over $100,000 a month. Talk to us.
- Published rates to plan from: card in person 2.4% + 15¢, online 2.7% + 20¢, bank 0.5% capped at $3.95, vendor payout $1.49.
Let your users' agents pay, and keep the decision in human hands.