Skip to content

PATTERN Cited by 1 source

Spend-request approval before credential issuance

Intent

Let an agent initiate a payment on a user's behalf without ever holding a reusable payment credential, by requiring the user to approve each proposed spend before any credential is released to the agent.

Context

Agent-initiated payments need two properties that naive architectures don't combine well:

  1. Agent-driven cadence — the agent needs to pay inside a task it's already executing, not after round-tripping to a human signup or card-entry flow.
  2. Hard bound on misuse — the agent is an untrusted credential-handler (prompt injection, log leakage, hallucinated spends, compromised runtimes); an agent holding a reusable card is a standing liability.

If the agent is given a raw card up front, cadence is good but misuse is unbounded. If every payment requires the human to enter card data, misuse is bounded but cadence collapses. This pattern threads the needle: the agent's cadence isn't broken (it can request-and-wait inside its loop), and the human's approval is the only thing standing between the request and the scoped credential — which is itself single-use and scoped.

Solution

Three-step protocol between agent, wallet / issuer, and user:

1. Agent creates a structured spend request

The agent calls the wallet's spend-request API with:

  • Machine-readable scope fields — merchant name, merchant URL, amount, currency (and optionally, a time-of-purchase or intent-window).
  • Human-readable context — a plain-language justification the user can read to decide whether to approve.
  • Payment-method pointer — which of the user's vaulted funding instruments should back the credential (if the wallet supports multiple).

The 2026-04-29 Link canonical instance:

link-cli spend-request create \
  --payment-method-id csmrpd_12345 \
  --merchant-name "Powdur" \
  --merchant-url "https://powdur.com" \
  --amount 3500 \
  --context "Purchasing the Powdur Glow Renewal
             Vitamin C Serum as a gift for $35." \
  --request-approval

2. Wallet surfaces the request for approval

The wallet pushes the request to the user through whatever channels it supports (web, mobile app, push notification, email). The approval surface shows the machine-readable fields (so the user knows exactly what the agent is asking for) plus the context string (so the user knows why).

The user approves or rejects.

3. Wallet mints a scoped credential only on approval

On approval:

  • Wallet mints a credential — single-use virtual card or SPT, depending on the merchant and the wallet's credential-type heuristic (see concepts/agent-wallet-over-raw-credential-issuance).
  • Scope fields from the request are bound into the credential — merchant, amount, currency. The credential will reject at authorisation time outside that scope.
  • The credential is returned to the agent, which can then charge it.

On rejection (or timeout):

  • No credential is issued. The agent's task fails or retries per its own logic.

Structural properties

  • Hard gate, not observability. Non-approval → no credential → no charge. The credential literally does not exist pre-approval.
  • Two-layer enforcement. Approval is the first layer; credential scope is the second. Even an approved credential cannot be misused outside its scope (see concepts/single-use-virtual-card-for-agents).
  • Structured context. The context field is the human-readable rationale; machine fields are authoritative for scope enforcement. The UI's job is to surface both so the human can make an informed decision.
  • Asynchronous approval. The user doesn't need to be watching the agent session; approvals can arrive later via separate surfaces. The agent blocks or retries.
  • Per-transaction, not per-session. Each spend is a separate decision. (The roadmap is auto-approval below a user-set cap — see concepts/agent-payment-budget-cap — but the default at launch is per-spend.)

When it fits

  • Consumer-facing agentic commerce. Transactions are relatively high-value per event; approval latency is tolerable within the user's attention cycle; the human is in scope to approve.
  • Regulatory environments requiring strong customer authentication. Matches existing SCA / 3DS patterns where each card-not-present charge is cardholder- confirmed.
  • Untrusted-agent environments. Prompt-injection- prone agents, third-party / aggregator agents, new / unaudited agents.

When it doesn't

  • Machine-payment altitudes (concepts/machine-payment) — per-call, high-cadence, low-value payments. Human-in-the-loop per-call is structurally incompatible; the agent must be able to pay inside the HTTP round-trip.
  • Agent-provisioning altitudes (patterns/agent-provisioning-protocol) — subscription-style recurring charges. Per-provisioning approval is the right granularity, not per-charge-cycle approval.
  • Trusted first-party agents — a business's own internal-automation agent working within tight bounds may justify lighter consent than per-transaction approval.

Composes with

Failure modes

  • Approval fatigue. High-frequency low-value transactions produce notification overload. Mitigation: cap-based auto-approval (roadmap).
  • Approval UI spoofing. An agent can craft a misleading context string or merchant URL. Wallet operators must validate URLs + sanitize context rendering.
  • Approval latency deadlock. If the agent's task has a tight deadline and the user doesn't respond, the agent cold-starts repeatedly. Mitigation: TTL on approvals + agent-side timeout + graceful failure.
  • Split-brain approval. Multi-device users may double-approve or see races. Mitigation: server-side deduplication of approvals per spend-request-id.
  • context-field LLM injection. The context string is agent-supplied; a compromised agent can embed social-engineering content targeting the human reviewer. Mitigation: structural rendering distinction between agent-supplied text and wallet-authoritative fields.
  • Shared-account conflicts. On a joint / family / corporate wallet, the approval authority is ambiguous. Mitigation: explicit approver designation per-wallet.

Canonical instance (2026-04-29)

Link's wallet for agents as the consumer-facing instance; each approved spend produces a single-use virtual card or SPT scoped to the approved transaction. The link-cli spend-request create --request-approval command is the launch-time wire-shape of step 1.

Distinction from sibling patterns

  • vs patterns/orchestrator-provider-agent-trust-triangle — the orchestrator-provider-agent triangle assumes a standing payment token from the orchestrator to the provider with a period-scoped cap. This pattern adds a per-transaction human approval on top of (or instead of) a standing token; complementary, not alternative.
  • vs patterns/human-in-the-loop-quality-sampling — quality sampling reviews a random fraction of outputs. This pattern reviews every spend decision. Different intent (safety gate vs sample quality), different coverage (100% vs sampled).

Seen in

Last updated · 446 distilled / 1,275 read