Implement Non-Human-in-the-Loop (Autonomous) Checkout Flow

[TheBlackBit]

Add support for fully autonomous agent transactions without per-purchase user confirmation. Requires validating a Verifiable Intent or AP2 Mandate chain in the Checkout MCP before execution — verifying amount ceiling, merchant allowlist, credential scope, and expiry. Includes pre-authorized credential handling, autonomous flow risk controls, and audit logging of all autonomous transactions.

[evidai]

This is exactly the failure mode we built around in LemonCake (https://lemoncake.xyz) — sharing the design in case it's useful for the discussion.

The core safety property: an agent that gets prompt-injected (or just confused) must not be able to exceed the human's intended spending budget. Our take:

• Buyer Key (bk_…) — long-lived, hashed at rest. Scoped to one seller (cannot be used elsewhere). Carries hard caps: per_mint_max, daily_max, monthly_max.
• Pay Token (JWT, pt_…) — short-lived single-use wallet. Issued by the gateway only after a charge commits.
• Caps enforced server-side via lc_agent_charges table with a unique charge_ref (idempotency + cap-window aggregation). The agent literally cannot blow the budget — even with a malicious prompt, the gateway will refuse to mint past the cap.
• Settlement happens before token issue: the agent only ever holds an already-paid JWT. No "decide settlement at request time" race.
• Custody-free: virtual balance = sum of unused Pay Tokens. No pool. FSA-cleared design.

For the issue here, the relevant pattern is: never give the agent a credential that itself can move money — give it a credential that can request the gateway to move money, where the gateway is the one enforcing the caps.

Production verified: $1 off-session card charge through the full loop on 2026-06-02.
30-second demo (no signup): https://lemoncake.xyz/demo

(Disclosure: I'm working on LemonCake — sharing as a reference, not pitching.)