Skip to content

CONCEPT Cited by 1 source

Agent wallet over raw credential issuance

Definition

An agent wallet is an architectural abstraction in which an AI agent interacts with the user's payment system through a wallet endpoint"issue me a scoped credential for this cart" — rather than through raw credentials (cards, bank accounts, API tokens). The wallet endpoint decides:

  1. What kind of credential to mint (single-use virtual card, SPT, future stablecoin, future agentic token, …).
  2. What scope fields to bind (amount, currency, merchant, time window).
  3. When to require additional consent (e.g. per- transaction human approval, future cap-based skips).

The agent never sees the user's underlying funding sources or their raw representation on a payment network.

Canonicalised by Stripe's 2026-04-29 launch of Link's wallet for agents: "Link handles the abstraction across payment options your agent might need — like cards and SPTs (with stablecoins and other payment methods coming soon)."

The wallet abstraction vs the raw-credential shape

── raw-credential shape (pre-2026) ────────────────────────
   user  ──▶  copies card data  ──▶  agent
   ✗ agent holds PCI-scope credentials
   ✗ no scope enforcement at the credential
   ✗ single revocation = cancel the card, fan out to
     every service charged
   ✗ scale-out to multiple agents = multiple copies of
     the same card in multiple places

── wallet-over-credential-issuance (2026-04-29 Link) ──────
   user  ──▶  Link wallet (holds funding instruments)
                 │   per-spend:
                 │     ← spend-request (from agent)
                 │     ← human approval
                 │     → scoped credential (card or SPT)
                 agent uses scoped credential once
   ✓ agent never touches the funding instrument
   ✓ scope enforced on the issued credential itself
   ✓ single revocation = revoke OAuth grant at wallet
   ✓ scale-out = many agents × many OAuth grants;
     wallet is canonical source

Why a wallet abstraction (not just scoped credentials)

You can have scoped credentials without a wallet — e.g. a developer could integrate Issuing for agents directly and mint single-use cards on every spend. The wallet adds value on top of that primitive:

  1. Payment-method abstraction. The wallet picks the right credential type for the merchant — card if the merchant accepts cards, SPT if the merchant runs on ACP, stablecoin if future rails support it — without the agent integrating each rail.
  2. Consumer-anchored identity. The wallet has a consumer account; each user's funding instruments are aggregated there. Agents get a single access surface per user ("grant access to my wallet") rather than per funding-instrument ("grant access to my Chase card, grant access to my BofA account, …").
  3. Consent centralisation. The consent UI — approval screens, spending limits, autonomy tiers, connected- agent management — lives in one place. Without a wallet, these controls fragment across each rail each agent uses.
  4. Observability centralisation. Agent-spending history is visible from one surface (the wallet UI), not reconstructed across multiple card statements.
  5. Ecosystem portability. The agent integrates with a wallet API; moving from one wallet provider to another doesn't require changing the agent's payment-method integration.

Structural properties

  • Agent-visible surface is issuance, not storage. The agent has no operation to read funding-source details — only to request a scoped credential.
  • Each credential is fresh. No long-lived token shared between agent and wallet; each spend produces a new credential with the scope of the spend bound in.
  • Wallet is the policy enforcement point. Human approval, spend caps, merchant allowlists, time windows, autonomy tiers — all enforced at credential-issuance time by the wallet, not distributed across the downstream payment rails.
  • Revocation is wallet-grained. A compromised agent gets its OAuth grant revoked at the wallet; no need to rotate funding instruments.
  • The wallet holds the funding sources; the agent holds temporary scoped credentials only.

Contrast with sibling agent-trust shapes

  • Agent- provisioning uses a payment token backed by the orchestrator's payment method, but the credential is scoped to a provider + period (e.g. Cloudflare, one month). The wallet-over-credential-issuance shape is scoped to a merchant + amount + single transaction — much finer-grained because the transaction cadence is much higher.
  • Machine payments bypass the wallet altogether and let the agent pay from its own budget via x402 / stablecoin rails. The wallet shape is about the user's money; machine payments are about the agent's operational budget.

Canonical instances

  • systems/stripe-link-wallet-for-agents — launch-time canonical instance (2026-04-29) of the wallet-over- credential-issuance architecture. Abstracts cards + SPTs
  • future stablecoins behind a single wallet API.

Prior art at other altitudes that shares the wallet shape but not the full substrate:

  • Apple Pay / Google Pay / Samsung Pay — wallet abstractions for human buyers; credential shape is tokenised card (DPAN). Agent-usable surfaces are not standardised.
  • PayPal / Venmo — wallet abstractions for human buyers; credential is account-balance-backed charge. Agent- usable surfaces exist but without per-spend scope enforcement.

The 2026-04-29 Link product is the first wiki instance of the wallet shape specifically designed around agent as the credential-requesting client with per-spend scope.

What's not disclosed

  • Wallet-schema standardisation. Is Link's wallet for agents the only wallet, or does Stripe anticipate a W3C-style wallet spec? Launch framing is product- centric, not standards-centric.
  • Multi-wallet-per-agent composition. Can an agent hold OAuth grants to multiple wallets (e.g. Link + Apple Pay + corporate wallet) and choose dynamically? The 2026-04-29 post is single-wallet-per-agent in framing.
  • Wallet-to-wallet portability. Can a consumer move their connected-agents list + spending-history from Link to a competitor wallet?

Seen in

Last updated · 446 distilled / 1,275 read