Kaliski Safe Agent Payments Framework

// When should you use the Kaliski Safe Agent Payments Framework?

Use this skill when architecting, auditing, or building systems where AI agents need to spend money, manage credentials, or complete purchases on behalf of humans — or when a business wants to safely accept payments from autonomous agents.

// What inputs do you need before designing an agent payment system?

• agent_rolerequired
  Is the agent acting as a buyer (spending money) or is the system a seller (receiving money from agents)?
• payment_methodsrequired
  What payment methods are in scope — cards, crypto, wallets, or multi-method?
• spend_controls_neededrequired
  What constraints must be enforced — amount limits, time windows, seller scoping, currency restrictions?
• transaction_typerequired
  Is this an API call purchase, e-commerce checkout, subscription, or recurring budget scenario?
• current_integration
  Does the seller currently expose only a web UI, or do they have programmatic APIs?

// What are the core principles behind safe AI agent payments?

// How do you apply the Kaliski Safe Agent Payments Framework step by step?

1. 1

   Classify the transaction layer

   Determine which of the four risk vectors apply: Wrong Place (unverified merchant/domain), Wrong Thing (incorrect product selected), Wrong Amount (price drift, currency mismatch, tax miscalculation), Wrong Credential (card number exposed or misrouted). Each vector requires a different mitigation.

2. 2

   Separate the non-deterministic planner from the deterministic transaction layer

   Allow LLM-driven discovery (search, recommendations, web crawling) to remain non-deterministic. Once the agent transitions to transacting, enforce a hard boundary: all credential, payment, and checkout actions must be API-driven and programmatic. Never let the robot 'stumble around a checkout page'.

3. 3

   Provision a Shared Payment Token

   Instead of passing a raw card number, the agent-side system provisions a Shared Payment Token — a credential that encodes a mandate (smart contract) with: a specific seller scope, a maximum spend amount, a currency restriction, and a time expiry window. This token is granted to the seller, not the underlying card. Stripe (or equivalent PSP) enforces the mandate server-side, so even if the seller attempts to charge more than mandated, the transaction is declined.

4. 4

   Expose card metadata to the seller for risk analysis

   When sharing a Shared Payment Token, always surface the card brand, last four digits, and credit type to the seller. Do not obscure this. The seller must be able to run their existing risk systems on this data — transparency is required for safe acceptance.

5. 5

   Implement the Machine Payments Protocol (402 flow) for API-based purchases

   For tool calls that require payment, use HTTP 402 status codes to signal that payment is required. The 402 response returns an encoded payload describing what is being purchased, who the recipient is, and the payment mechanism. The agent then approves payment and retries. This associates payment directly with the resource being requested, eliminating ambiguity about what is being purchased.

6. 6

   Implement the Agent-to-Commerce Protocol (ACP) for e-commerce checkout

   For product-based purchases, replace browser-based checkout with a structured, programmatic back-and-forth: the seller exposes a product catalog as JSON (with images, descriptions, pricing); the agent initiates a checkout with line items and quantity; the seller responds with the full cart state (line items, base prices, applicable taxes, fulfillment options). Every update (change payment method, change shipping) triggers another structured exchange. Payment is submitted via Shared Payment Token or equivalent. This eliminates the risk of the agent incorrectly relaying cart details, minimising disputes and chargebacks.

7. 7

   Handle recurring budgets and subscriptions with scoped token renewal

   For recurring or subscription-style spend (e.g., giving an agent $25/week with a specific seller), use a token renewal pattern analogous to OAuth access and refresh flows — the agent requests subsequent usage permissions on a periodic basis using the same underlying credential. For broader budget policies, create multiple seller-scoped tokens rather than one high-limit unscoped credential.

8. 8

   Audit and verify the full transaction trail

   Every Shared Payment Token must be auditable — creation timestamp, mandate parameters, usage, and expiry. For blockchain-based payment methods, transaction data lives on-chain and should be replicated into your system's product view. Audit trails are essential for dispute resolution and for verifying that the agent acted within its mandate.

// What are real-world examples of the Kaliski framework in action?

// What mistakes should you avoid when building agent payment systems?

• Passing raw card numbers to agents or sellers — this removes all spend controls and exposes the full credit limit as the blast radius.
• Letting an agent browse and interact with a checkout UI as a human would — this is slow, finicky, hard to observe, and introduces non-determinism into a layer that requires determinism.
• Trusting the agent's parsed price from a webpage as the authoritative amount — prices drift, taxes vary, currencies differ; always enforce limits at the credential layer, not at the parsing layer.
• Hiding payment token details from the seller — sellers need card brand, last four, and credit type to run their existing risk analysis. Opaque tokens may be rejected or create undetected fraud risk.
• Using a single high-limit unscoped credential for an agent — always scope to individual sellers. If broad budgets are needed, create multiple seller-scoped tokens rather than one unscoped one.
• Failing to separate discovery from transaction — allowing the non-deterministic planner to also handle credentials and checkout collapses the critical architectural boundary.
• Exposing only a web UI to agent buyers — this forces agents into non-deterministic browser automation, increasing error rates and risk surface. Build agent-friendly APIs.

// What are the key terms and definitions in agent payment infrastructure?

Shared Payment Token

A credential provisioned by the agent-side system that encodes a mandate (analogous to a smart contract) specifying: the permitted seller, maximum spend amount, allowed currency, and expiry window. It is granted to the seller instead of a raw card number, and the PSP enforces its constraints server-side.

Machine Payments Protocol

A protocol built on HTTP 402 status codes that allows API endpoints (tools) to signal that payment is required, return a structured payload describing what is being purchased and how to pay, and accept a credential in the retry request — associating payment directly with the resource being accessed.

Agent-to-Commerce Protocol (ACP)

A standard set of APIs and objects that enables structured, programmatic checkout between an agent, a seller, and their payment service provider. Covers product catalog expression (JSON), checkout initiation, cart state relay (line items, taxes, fulfillment options), and payment submission — replacing browser-based checkout entirely.

Discovery vs. Determinism Isolation

The architectural principle that discovery and exploration (finding products, recommendations, web crawling) should remain non-deterministic (LLM-driven), while credentials, payments, and checkout must be exclusively deterministic (API-driven, programmatic, enforced).

Blast Radius

The maximum possible financial damage if an agent is compromised, deceived, or makes an error. Minimised by scoping Shared Payment Tokens to specific sellers, amounts, and time windows.

Wrong Place / Wrong Thing / Wrong Amount / Wrong Credential

The four core risk vectors in agent-mediated payments: transacting with an unverified or spoofed merchant; purchasing the incorrect product; spending an incorrect amount due to price drift or parsing errors; and exposing or misrouting payment credentials.

402 Flow

The HTTP 402 'Payment Required' response pattern used in the Machine Payments Protocol to gate access to a tool or API endpoint behind a micropayment, returning a structured payload that specifies cost, recipient, and payment mechanism.

Mandate

The encoded set of spend constraints attached to a Shared Payment Token — covering seller scope, amount limit, currency, and time expiry. Enforced by the PSP, not by trust in the seller or agent.

// FREQUENTLY ASKED QUESTIONS