A cap is not a signature — agent wallets meet PSD2

Cloudflare gave agents a wallet with a spending cap and a merchant allowlist. Under EU payments law those are not authorisation: strong customer authentication attaches to the transaction, and the exemption that makes agentic spending workable puts the authentication moment on amending the allowlist. So the security-critical event is a config change, and liability follows the logs.

Post

Your agent now has a wallet, a spending cap and an approved merchant list.

None of those three things is a signature.

On 4 August Cloudflare announced Wallets and cloudflare.pay — a stable identity for an agent, and a balance it spends from. Handles open now; wallets and per-agent Virtual Wallets come "in the coming months". The controls are what you'd design: a cap, an approved merchant list, a maximum transaction size.

Now hold that against European payments law.

If the stablecoin is an e-money token, MiCA Article 48(2) deems it electronic money, and PSD2 counts electronic money as funds. The EBA's opinion follows through: transferring them for clients is a payment service, and a custodial wallet that pays third parties is a payment account.

That drags in Article 97 — strong customer authentication when the payer initiates an electronic payment transaction, dynamically linked to a specific amount and a specific payee.

A cap does not link to an amount. An allowlist does not link to a payee. They authenticate a policy once, and every later payment inherits it.

The part that should change your architecture: the exemption that makes agentic spending workable is trusted beneficiaries, and its rule is one sentence. Providers shall apply strong customer authentication where a payer creates or amends the list of trusted beneficiaries.

The security-critical event is the config change. Not the payment.

And the law puts liability behind it. Article 73 refunds an unauthorised transaction by the end of the next business day, and in C-70/25 the Advocate General went further: refund first, argue later. Whoever proves authorisation afterwards proves it from logs.

What I'd do Monday:

Treat allowlist and cap edits as privileged operations — signed, reviewed, logged separately from the payments they authorise.
Never let an agent widen its own limits. An injected agent that amends its allowlist has done the one thing the rule exists to prevent.
Ask your wallet provider in writing whether the token is an e-money token and who holds the licence. Cloudflare's release names no stablecoin and says nothing about custody, KYC or the EEA.
Log per transaction: which instruction, which amount, which payee, which approval it inherited.

The wallet is months away. The logging decision is this sprint.

Could you show, three months later, who authorised one specific payment to one specific payee?

#AgenticAI #PSD2 #MiCA #AIEngineering #Berlin

AI disclosure: the narration voice and the cover art in this video are AI-generated. The script, the claims and the source checks are mine.

First comment

Sources, primary first —

Cloudflare's own press release, dated 4 August 2026 — the handle reservation, the "coming months" scope, and the spending cap / approved merchant list / maximum transaction size wording quoted above https://www.cloudflare.com/press/press-releases/2026/cloudflare-gives-ai-agents-an-identity-and-a-wallet/

EBA Opinion on the interplay between PSD2 and MiCA — e-money tokens are funds; transfers and custodial wallets are payment services and payment accounts; strong customer authentication is to be enforced in full https://www.eba.europa.eu/sites/default/files/2025-06/e2958c99-a1b0-4b07-9d31-bcba0a28dbe7/Opinion%20on%20the%20interplay%20between%20PSD2%20and%20MiCA.pdf

PSD2 Article 97 — authentication on initiating an electronic payment transaction, and the dynamic link to a specific amount and a specific payee https://service.betterregulation.com/document/208856

Commission Delegated Regulation (EU) 2018/389 Article 13 — the one sentence this edition turns on: SCA where a payer creates or amends a list of trusted beneficiaries https://service.betterregulation.com/document/326676

PSD2 Article 73 — refund of an unauthorised transaction by the end of the following business day https://service.betterregulation.com/document/208826

Case C-70/25 — Advocate General Rantos, 5 March 2026, on immediate refund. An Opinion, not yet a judgment https://chambers.com/articles/refund-first-argue-later-case-c-70-25-and-its-implications-for-the-upcoming-psd3-psr-framework

One point cut for length: whether any of this touches you turns on whether the token is an e-money token, and I could not verify from a primary which stablecoins Cloudflare will support — the release names none. If it settles in a token that is not an EMT, the payments analysis above changes shape entirely and MiCA's other limbs take over. Worth asking before you build on it, not after.

A note on dating: most coverage filed this on 5 August. Cloudflare's own release is dated the 4th, and that is the date used above.

AI disclosure: the narration voice and the cover art in this video are AI-generated. The script, the claims and the source checks are mine.

Claims

Sources

Corrections

No corrections. Two things were deliberately withheld. Cloudflare's release names no stablecoin, so the edition never asserts that any particular token is an e-money token — the whole payments analysis is stated conditionally and the reader is told to ask. And Case C-70/25 is an Advocate General's Opinion, not a judgment; the post says so.

Three instrument texts — PSD2 Article 97, PSD2 Article 73 and Article 13 of Commission Delegated Regulation (EU) 2018/389 — are quoted from a third-party reproduction rather than the Official Journal, and are flagged secondary-sourced in the claims index. The MiCA Article 48(2) and PSD2 Article 4(25) chain is read from the EBA Opinion rather than from the instruments directly.

Dating: most coverage filed the Cloudflare announcement on 5 August. Cloudflare's own press release is dated 4 August, and that is the date used throughout.

A cap is not a signature — agent wallets meet PSD2

Cloudflare gave agents a wallet with a spending cap and a merchant allowlist. Under EU payments law those are not authorisation: strong customer authentication attaches to the transaction, and the exemption that makes agentic spending workable puts the authentication moment on amending the allowlist. So the security-critical event is a config change, and liability follows the logs.

Post

Your agent now has a wallet, a spending cap and an approved merchant list.

None of those three things is a signature.

Now hold that against European payments law.

That drags in Article 97 — strong customer authentication when the payer initiates an electronic payment transaction, dynamically linked to a specific amount and a specific payee.

A cap does not link to an amount. An allowlist does not link to a payee. They authenticate a policy once, and every later payment inherits it.

The security-critical event is the config change. Not the payment.

What I'd do Monday:

Treat allowlist and cap edits as privileged operations — signed, reviewed, logged separately from the payments they authorise.
Never let an agent widen its own limits. An injected agent that amends its allowlist has done the one thing the rule exists to prevent.
Ask your wallet provider in writing whether the token is an e-money token and who holds the licence. Cloudflare's release names no stablecoin and says nothing about custody, KYC or the EEA.
Log per transaction: which instruction, which amount, which payee, which approval it inherited.

The wallet is months away. The logging decision is this sprint.

Could you show, three months later, who authorised one specific payment to one specific payee?

#AgenticAI #PSD2 #MiCA #AIEngineering #Berlin

AI disclosure: the narration voice and the cover art in this video are AI-generated. The script, the claims and the source checks are mine.

First comment

Sources, primary first —

PSD2 Article 97 — authentication on initiating an electronic payment transaction, and the dynamic link to a specific amount and a specific payee https://service.betterregulation.com/document/208856

PSD2 Article 73 — refund of an unauthorised transaction by the end of the following business day https://service.betterregulation.com/document/208826

A note on dating: most coverage filed this on 5 August. Cloudflare's own release is dated the 4th, and that is the date used above.

AI disclosure: the narration voice and the cover art in this video are AI-generated. The script, the claims and the source checks are mine.

Claims

Sources

Corrections

Dating: most coverage filed the Cloudflare announcement on 5 August. Cloudflare's own press release is dated 4 August, and that is the date used throughout.