ChatGPT Wallet makes per-purchase approval a KYA boundary
A wallet can hide card details from an AI agent and still leave a harder governance question: exactly when does research authority become payment authority, and what evidence must survive that transition?
Daily signal: Public product materials released within the latest review window describe an agent-payment wallet that requires the user to review the items, total, and selected card, then approve every purchase with a device security check. The initial rollout is limited to eligible adult subscribers and cards in the United States. This is product infrastructure, not regulation or evidence that any institution has formally adopted KYA.
What changed
The announced flow separates shopping assistance from final payment approval. A user adds a card once, the agent can prepare a purchase, and the user must review the transaction and pass a device security check before payment proceeds. The business and agent do not receive the user's actual card details. Existing business responsibilities for pricing, fulfilment, returns, and customer service remain in place.
That design turns the final review into a KYA execution boundary. The evidence should show what the agent was asked to do, what it selected, what changed during checkout, what the user saw, what the user approved, which business accepted the purchase, and how payment, delivery, return, and dispute outcomes were resolved.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak evidence | Per-purchase boundary control | Expected evidence |
|---|---|---|---|
| Operator identity | A purchase is linked only to a customer account. | Bind the represented user, active agent, operating service, current version, and accountable provider to the purchase task. | User binding, agent identifier, operator record, active version, lifecycle state, and accountable owner. |
| Agent mandate | A broad shopping request is treated as authority to buy any item on any terms. | Record the requested product, quantity, price boundary, substitutions, timing, merchant conditions, approval point, expiry, and cancellation rule. | Task reference, mandate version, selected offer, matched limits, exceptions, user decision, expiry, and revocation state. |
| Wallet and custody | Card enrollment is treated as standing authority for the agent to spend. | Keep card details outside the agent, bind each payment to the reviewed purchase, and separate future pre-approved authority from today's per-purchase flow. | Instrument owner, amount, currency, business, user approval, payment result, refund destination, and dispute record. |
| Tool and venue access | Website access implies that the business accepts agent-led checkout and every connected action. | Verify signed agent requests, grant only required shopping functions, preserve business acceptance, and keep pricing, fulfilment, and returns under business control. | Access decision, granted function, disclosed fields, business policy version, checkout acceptance, denial reason, and cutoff state. |
| Audit trail | The final charge exists without the user's reviewed cart or the agent's prior actions. | Link request, search, selection, cart, presented terms, device security check, approval, payment, fulfilment, return, and dispute under one reference. | Event sequence, presented items and total, selected card reference, approval time, payment outcome, delivery, return, and closure. |
| Security and abuse | A valid approval can be replayed after the cart, amount, business, or delivery terms change. | Bind approval to exact terms, expire stale requests, reject replay, detect substitutions, cap repeated attempts, and require fresh approval after material change. | Integrity result, freshness result, changed-term decision, blocked attempt, alert, containment action, and safe restoration. |
| Jurisdiction fit | Limited US availability is assumed to establish readiness for other markets. | Reassess age, consent, payment authentication, privacy, disclosure, returns, disputes, recordkeeping, and liability before each market expansion. | Market assessment, eligibility rule, required disclosure, legal basis, record period, dispute owner, and customer remedy. |
Enrollment is not spending authority
Adding a card should establish an available payment method, not an unlimited mandate. The active authority arises only when the user reviews the exact items, total, and selected card and completes the required security step. The resulting record should be transaction-specific, short-lived, and unusable after a material term changes.
This distinction matters because an agent may legitimately research, compare, and prepare a cart without having authority to commit funds. KYA should preserve those stages separately so an operator can prove that recommendation rights did not silently become execution rights.
Card-detail isolation solves only one risk
Keeping actual card details away from the agent reduces exposure, but it does not prove that the chosen product matched the user's request, that the business accepted agent-led activity, or that fulfilment and dispute handling worked. The payment record must remain connected to the commercial task and the business that owes delivery or remedy.
Risk systems also need enough context to recognize legitimate agent-led purchases without weakening fraud controls. A receiving business should verify the agent request, preserve the current access decision, and distinguish research, cart management, checkout preparation, payment, return, and customer-service rights.
Future delegation needs a different control file
The product materials describe possible future purchases pre-approved within parameters such as spending limits, categories, or time periods. That model would move authority from a single user-reviewed purchase to a standing but bounded mandate. It should not inherit approval merely because the user previously enrolled a card or completed an unrelated purchase.
A future delegated mode would need explicit activation, purpose and category limits, business restrictions, per-purchase and cumulative caps, validity dates, notification rules, exception handling, immediate pause and revocation, and periodic review. The system should identify the execution mode on every transaction so businesses, banks, and reviewers can distinguish direct approval from pre-approved agent action.
Practical KYA checklist
- Bind each purchase to the represented user, active agent, operator, task, and current software version.
- Keep card enrollment separate from transaction authority.
- Record the exact items, total, business, selected card reference, and terms shown before approval.
- Invalidate approval when price, quantity, business, delivery, return, or payment terms materially change.
- Preserve receiving-side agent recognition and the business's permitted-function decision.
- Link payment to fulfilment, return, refund, dispute, and final remedy.
- Label direct user approval and any future pre-approved execution as separate modes.
- Reassess eligibility, consent, privacy, authentication, and customer remedy before market expansion.
Bottom line
Per-purchase review creates a clear KYA boundary only when the evidence binds the user's mandate to the exact commercial terms and the resulting payment. Card-detail isolation is valuable, but complete assurance also requires receiving-side acceptance, fulfilment evidence, dispute continuity, and a hard separation between today's direct approval and any future standing delegation.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.