Product announcement published on the **Cloudflare** blog on **August 4, 2026** by **Will Papper**, as part of **Agents Week**: **Cloudflare Wallets**, presented as *"the programmable wallet for the agentic Internet"*. **The problem stated** is precise and well chosen: an agent that wants to try an API has to go through a login page **designed for humans**, have a human add a payment method, generate an API key, then figure out how to call the service. Two structural gaps explain this — *"Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs"* — with the consequence that *"AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans"*. **The proposed architecture comes down to two wallet types**: **Account Wallets**, intended for humans who own a Cloudflare account (fund, delegate, withdraw), and **Virtual Wallets**, intended for agents, **operating via API key** and whose spending cap is **set by the account holder**. The announced guardrails are explicit: **allocation, allow list, maximum amount per transaction**. **The payment rail is the x402 protocol** (payments attached to HTTP requests) and the currency is **stablecoin** — which places the offering in a distinct camp from schemes built on card networks. **The most interesting argument is counterintuitive and central**: *"These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000."* → **the cap is not what constrains autonomy, it is what makes it acceptable.** **Second component, more strategic than the first**: identity, via a **`cloudflare.pay`** namespace — a research agent could live at `research.example.cloudflare.pay`, giving the merchant certainty that it is talking to the agent of an identified organization. Cloudflare claims a deliberately minimal ambition (*"a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS"*), built on its existing building blocks (**Turnstile**, Bot Management, **Web Bot Auth** and its keypairs), and states its intent to adopt the schemes of the **x402 Foundation** as they emerge. **A decisive caveat about the status of the text**: **almost everything is in the future tense**. What exists on the day of the announcement is the **reservation of a handle**; payments, Virtual Wallets, guardrails, and the ramps for accessing funds are announced (*"Soon, you will be able to…"*). This is a **staking of position on a namespace**, more than a service going live.
#Cloudflare Wallets#agentic commerce#Agents Week
**Will Papper** — auteur de l'annonce sur le blog Cloudflare (lecture annoncée : 8 minutes). Publication rattachée à l'**Agents Week** de Cloudflare et étiquetée *Agents Week · AI · AI Bots · Developer Platform · Developers · Payments · Product News · x402*.
Tech-watch note by **Didier Girard** dated **August 2, 2026**, prompted by a colleague's question ("what is ACP?") to address a problem that is not terminological but **documentary**. **Three protocols compete for the acronym**, with no technical overlap whatsoever: **Agent Client Protocol** (client ↔ agent — Zed, August 2025, JSON-RPC 2.0 over stdio, Apache-2.0, "what LSP did for languages"), **Agentic Commerce Protocol** (agent ↔ merchant — OpenAI + Stripe, Sept. 29, 2025, competing with Google's **UCP** of Jan. 11, 2026 backed by **AP2**), and **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal but polluting searches). **The core of the note is not the disentangling but its observed failure**: the author searches "ACP" in their tech-watch knowledge base and gets **twelve results, all about the commerce protocol, zero about Zed's** — *"our watch agents had indexed the acronym without disambiguating it"*. Hence a knowledge-engineering rule: ***"a bare acronym is never indexed"*** — the entity is "Agent Client Protocol", "ACP" is **only an alias**, carried by three distinct entities. A structuring clarification follows (**MCP connects an agent to its tools, ACP connects a client to an agent; the two stack**), then the textbook case: **Buzz**, published by **Block** on July 21, 2026 under Apache-2.0 — a self-hostable workspace built on **Nostr**, where every human or agent participant is a **key pair** and every message, workflow step, or git push is a **signed event** in an append-only log. An entirely protocol-based architecture (`buzz-acp` an ACP harness over stdio, `buzz-agent` an ACP agent calling an LLM, `buzz-dev-mcp` an MCP shell + editing server), hence agent agnosticism: **Goose, Claude Code, and Codex** plug in through the same harness, and **Hermes** (Nous Research) connected to it without Block writing a single line — *"N+M instead of N×M, running in production"*. The note closes on the question of the **Claude subscription** versus third-party agents, with a five-stage 2026 timeline and a **design rule** that holds beyond this case: the line is not legal but **architectural** — ***"who is consuming, and on whose behalf"*** (an `owner-only` agent consumes your subscription on your behalf; an `anyone` agent in a shared channel routes your colleagues' requests through your account). **Verification carried out on this corpus**: the thesis holds, and more starkly than the note claims — not only is "Agent Client Protocol" **completely absent**, but the bare acronym `ACP` **is already typed as an entity** in two fiches, and the KB page `Agentic-Commerce-Protocol` **already attributes the protocol to Google** when it belongs to OpenAI + Stripe. The collision described is not a future risk: it has **already produced an attribution error** in the graph.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Product announcement published on the **Stripe** blog on **April 29, 2026** by **Dan Hill** (Product Manager, Link Consumer Product), following on from the **Stripe Sessions 2026** keynote: the launch of **Link's wallet for agents**, built on a new building block, **Issuing for agents**. **The diagnosis fits in one sentence, and it is the most important one in the text**: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* → **Stripe acknowledges that machine-native payment protocols are not ready, and delivers a workaround for existing rails rather than a bet on new ones.** **The mechanism**: a consumer grants an agent access to their Link wallet via a **standard OAuth flow**; the agent then issues a *spend request* and receives either a **single-use card**, or a **Shared Payment Token** — backed by the cards and bank accounts already present in the wallet. Cardinal point: *"The agent never gets access to your raw payment credentials."* The credential is **scoped** (amount, currency, merchant) and the agent must supply the **transaction context** so the human understands what they are approving — the example given in the CLI is explicit: `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **The structuring constraint is temporal, and it is owned as such**: *"Today, each request requires the person's review before the credential is shared with your agent"* — **human** approval, **transaction by transaction**, on the web or in the **new Link iOS and Android apps**. Spending limits and cases where the agent would act **without additional approval** are announced, not delivered. **The second layer is the real infrastructure product**: **Issuing for agents** opens the full set of Issuing APIs to anyone building their own agentic wallet — single-use virtual cards, fund storage, spend controls, card-level permissions, **at-authorization** antifraud controls, real-time visibility. Four use cases are cited: internal spend automation, agentic cards embedded at **fintechs**, **vertical SaaS** platforms issuing cards to SMBs under their own brand, **marketplaces** whose selling agents pay suppliers and logistics. **Distribution argument**: Link claims **more than 200 million consumers**, and the article cites **OpenClaw** as an example of a personal agent that benefits. **Two reservations worth flagging up front**: per-transaction approval is presented as a design convenience when it is actually **an admission that delegated agent authorization is not solved**; and stablecoin, *agentic tokens*, and "other payment methods" are all in the **future tense** (*"coming soon"*).
#Stripe#Link#wallet for agents
**Dan Hill** — Product Manager · **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe · rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public** · pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.