Sources: Visa press release · fintechnews.sg coverage · pinkwallet: x402 vs AP2 vs ACP · inriver: payment protocols for agent commerce
Now the honest question. In this pilot, the buyer still approves every invoice before the agent pays it. Would you trust a verified agent with a pre-approved spend policy — or does payment execution stay human-gated for you? And if your agent already touches money somewhere, where is it? I'm genuinely curious what people are shipping here.
Update (Oct 22): A reader (Arun, in the comments below) made the point this map was missing: the axis that matters isn't whether a human approves each payment — it's where the mandate lives. A spend policy stored in the agent's own config is enforced by the very thing you're worried about. UK Commercial VRP shows the other shape: caps and an end date agreed up front, consent held at the bank, revocable in the banking app, so a compromised agent stops dead at the cap. Any revision of this map will score protocols on mandate location, not just human-in-the-loop.
Top comments (2)
UK regulated payments has a specific answer to this and it is not the one the protocol map implies.
The axis that matters is not whether a human clicks. It is who holds the limit. An agent with a pre-approved spend policy stored in its own config is unsafe whether or not a person approved each invoice, because the thing enforcing the cap is the thing you are worried about. An agent operating under a mandate held somewhere else is a different risk entirely.
Commercial VRP is live in the UK under the UK Payments Initiative, and the shape is exactly that: the customer agrees periodic caps and an end date up front, the consent sits at their bank, and they can see it and cancel it in their banking app. The agent cannot widen it. A compromised agent can spend up to the cap and then stops, and the person who can change the cap is not reachable through the agent at all.
So my answer to your question is yes to a pre-approved spend policy, and no to one the agent can read its own limit from. Human-gating each payment is a slower version of the same control, and it degrades the way your article's own pilot will degrade once the volume goes up and approving becomes clicking.
What I do not have a good answer for: the mandate is per payee. That is fine for a utility bill and awkward for an agent that is supposed to find the cheapest supplier, because the useful case is precisely the one where you do not know who gets paid when you set the limit.
This is the correction the map needed, honestly.
You're right about the axis. I framed it around approval — who clicks — and that's the weak version of the control. If the spend policy lives in the agent's own config, the thing enforcing the cap is the thing you're worried about. And human-gating doesn't fix it, it just slows it down until approving becomes reflex clicking — I've watched exactly that happen once volumes climb.
VRP is the shape that should have been in there: mandate held at the bank, caps and an end date agreed up front, revocable in the banking app, and a compromised agent's blast radius stops dead at the cap. The map needed a "where does the mandate live" column, not just a human-in-the-loop one. I'm adding a short update note to the piece crediting this.
Your open problem is the one I keep circling too: per-payee mandates break exactly where agents get useful, when the whole point is not knowing the payee in advance. The closest fix I've seen floated is a mandate to a category with a period cap instead of a named payee — but that widens the blast radius again, so it's not really a fix. If you ever write that up, I'd read it.