VIII · Safety & ControlExperimental·

Session-Scoped Payment Authorization

also known as Pre-Authorized Spend Session, Prepaid Micropayment Session, Session Spend Cap

Bound an agent's autonomous spending by having it open a payment session with a pre-approved cap, stream many micropayments inside that session, and settle once on close, instead of seeking approval for every transaction.

This pattern helps complete certain larger patterns —

  • specialisesAgent-Initiated Payment★— Give an agent a bounded wallet so it can settle a payment mid-request to unlock a resource — answering a payment-required challenge with a verifiable proof — instead of routing every purchase through a human.

Context

An agent transacts with paid services on a user's behalf — calling metered APIs, buying compute, paying other agents for sub-results. Each individual charge is tiny and frequent, so a human approval per transaction is impossible, but unbounded autonomous spend is unacceptable. Emerging agent-payment protocols (x402, AP2, ACP) give agents the rails to pay; the open question is how to cap the risk.

Problem

Per-transaction human approval does not scale to an agent making hundreds of micropayments a minute, but handing the agent an open-ended wallet exposes the user to runaway or adversarial spend. The system needs a unit of authorization larger than one transaction yet bounded enough that a compromised or looping agent cannot drain funds.

Forces

  • Micropayments are too frequent for per-transaction human approval.
  • An open-ended wallet exposes the user to runaway or malicious spend.
  • A cap that is too tight stalls legitimate work mid-session; too loose and it is no protection.
  • Settlement and reconciliation want to happen once, not per micropayment.
  • The agent, the wallet, and the paid service are separate trust domains that must agree on the cap.

Example

A shopping agent is told to assemble a parts list under a $200 budget. It opens a payment session pre-authorized to $200, then streams small payments to a dozen catalog and pricing APIs as it researches, each debited against the cap. When it has spent $187 it stops querying paid sources and reports back; the session closes and settles once, and even if the agent had looped, it could never have spent past the $200 it was granted.

Diagram

Solution

Therefore:

Introduce a session as the authorization boundary for spend. When the agent begins a paid workflow, it opens a session and the wallet (or a governance layer) pre-authorizes a maximum amount and possibly a time-to-live. Inside the session the agent streams micropayments to services without further approval, each debited against the remaining cap; when the cap is reached the session blocks or escalates. On completion the session closes and settles once, reconciling the streamed payments. The cap, TTL, and per-recipient limits are the safety envelope; the agent's freedom exists only inside it. This is the session model emerging in machine-payment protocols layered over x402, AP2, and ACP.

What this pattern forbids. The agent must not initiate a payment that would take cumulative session spend over the pre-authorized cap, and must not transact outside an open, authorized session. When the cap is reached it must stop and escalate rather than seek funds elsewhere.

And the patterns that stand alongside it, or against it —

  • complementsStep Budget★★— Cap the number of tool calls or loop iterations the agent is allowed within a single request.
  • complementsCircuit Breaker★★— Stop calling a failing dependency for a cooldown period after error rates exceed a threshold.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance