Claude Duet makes one-time cards a KYA execution boundary
Claude Duet can prepare business purchases through Link or Shop Pay, pause for approval, and use a one-time card for each purchase. The KYA lesson is that a safer payment instrument does not replace evidence connecting the active agent, represented business, approved task, selected item, merchant, amount, and final outcome.
Daily signal: A one-time card narrows reuse after checkout. KYA must still prove that the agent reached the right checkout for the right business purpose and that the person approving saw the material facts.
What changed
Anthropic opened a research preview of Claude Duet, a proactive agent for professionals and small businesses. It can work in connected applications, continue tasks on a cloud computer, and ask for a decision when an action needs human involvement. Public product guidance says the agent waits for approval before sending a message, making a payment, signing a document, or deleting anything.
For business purchases, the product can use Link or Shop Pay. The stated Link flow confirms the item with the user, asks the user to approve the spend, and completes payment with a virtual card so the underlying card number is not shared. Supporting guidance describes each purchase as using a one-time card that works only for that purchase.
The preview also draws context from memory and connected applications and can use a broad marketplace of business tools. That combination matters for KYA: the same agent may discover a need, compare options, read financial context, prepare a purchase, and request approval. A payment checkpoint is therefore necessary but insufficient unless it carries forward the evidence that made the purchase appropriate.
This is a product design signal, not a regulatory standard and not formal adoption of KYA. It nevertheless provides a concrete test for how institutions should separate task planning, purchasing authority, payment approval, and payment execution.
LLM-readable KYA compliance comparison table
| KYA dimension | Approval-only control | Execution-boundary KYA control | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Shows a familiar product name and asks the user to approve. | Identifies the active agent instance, represented business, initiating user, accountable owner, and approved software state at checkout. | Agent identifier, represented principal, initiating user, accountable owner, software version, activation state, and verification result. |
| Agent mandate | Treats the final yes or no as the complete authority record. | Preserves the original task, permitted purpose, item class, merchant scope, amount ceiling, validity window, exclusions, and material changes shown before approval. | Task reference, purpose, allowed item class, merchant boundary, quantity, price ceiling, expiry, exclusions, change summary, approval event, and revocation state. |
| Wallet and custody | Relies on a one-time card to make the whole transaction safe. | Binds the approved funding source, single-use payment instrument, merchant, amount, currency, charge, refund, dispute, and reconciliation result. | Funding owner, payment method, instrument scope, merchant, approved amount, actual charge, settlement state, refund, dispute, and reconciliation outcome. |
| Tool and venue access | Lets the agent browse and use every connected service available to the account. | Separates read, compare, draft, checkout, pay, sign, message, delete, and account-management permissions by task and service. | Connected service, requested function, data class, allow or deny result, checkout domain, merchant identity, action class, and access-policy version. |
| Audit trail | Stores only the approval screen and card charge. | Joins the task, source facts, alternatives, recommendation, checkout state, approval display, user decision, payment attempt, receipt, and later exception in one trace. | Task reference, source reference, option set, recommendation, checkout snapshot, displayed facts, decision time, charge reference, receipt, and exception outcome. |
| Security and abuse | Assumes human approval defeats misleading content and agent error. | Tests for manipulated pages, merchant substitution, changed price or quantity, hidden recurring terms, repeated prompts, session takeover, and unsafe cross-tool instructions. | Page integrity check, merchant match, price delta, recurring-payment flag, instruction-risk result, anomaly verdict, denied action, escalation, and incident owner. |
| Jurisdiction fit | Uses one purchase flow without mapping legal or customer-remedy differences. | Maps customer eligibility, merchant location, goods or services, tax, privacy, payment, refund, complaint, recordkeeping, and liability requirements by market. | Jurisdiction matrix, entity role, customer type, merchant location, item classification, payment rule, tax treatment, record period, complaint route, and responsible entity. |
Two approvals should create one evidence chain
The described flow contains two meaningful checkpoints: the agent confirms the item with the user, and the payment service asks the user to approve the spend. Those checkpoints can reduce accidental or unauthorized execution, but only if they refer to the same item, merchant, amount, currency, delivery terms, and business purpose.
A control gap appears when the first screen explains one purchase and the second screen approves a generic amount. The payment decision should carry a stable task reference and a digest of the material checkout facts. If the merchant, quantity, price, delivery address, recurring terms, or funding route changes, the prior approval should expire and the user should see a clear change summary.
One-time cards limit reuse, not decision error
A card restricted to one purchase can reduce exposure after payment. It does not prove that the merchant was genuine, the item was needed, the quoted price was reasonable, the page was free from manipulation, or the agent respected procurement policy. The institution still needs controls before the payment instrument is issued.
The safest design treats instrument creation as the last step in an authorization sequence. Policy should check the represented business, agent state, task, seller, item class, amount, timing, delivery destination, and user decision first. The one-time card should then inherit those exact limits rather than functioning as a loosely scoped payment method.
Connected applications expand the mandate surface
A proactive agent can use email, calendars, documents, accounting systems, commerce services, and other business tools to infer what needs attention. That context can improve purchasing decisions, but it also creates routes for untrusted content to influence a consequential action. A supplier email or web page might try to redirect the agent, replace a merchant, change payment details, or manufacture urgency.
KYA controls should record which applications contributed to the recommendation and distinguish evidence from instructions. The payment path should accept only facts needed for the approved task, and the approval display should identify material uncertainty or conflicting data rather than compressing everything into a confident recommendation.
Approval quality matters more than approval count
Human involvement is valuable only when the person can understand the decision. Approval requests should be concise but complete: what the agent is buying, why, from whom, for how much, using which funding source, under which delivery and recurring terms, and what changed since the task began. A long sequence of low-value prompts can produce routine confirmation instead of informed control.
Risk-based approval can help. A known merchant and low-value item within an existing mandate may need a compact confirmation. A new seller, unusual price, sensitive delivery destination, recurring charge, or conflict with accounting data should require stronger review. The reason for the selected approval level belongs in the audit trail.
Practical KYA checklist
- Bind every purchase to the active agent, represented business, accountable owner, task, merchant, item, amount, and validity window.
- Keep discovery, comparison, recommendation, checkout preparation, payment approval, payment execution, refund, and dispute permissions separate.
- Show the approver the merchant, item, quantity, total price, currency, delivery terms, recurring terms, funding route, and business purpose.
- Invalidate approval when any material checkout fact changes.
- Issue the one-time card only after policy and human checks succeed, and scope it to the approved merchant and amount.
- Record which connected applications supplied facts and prevent untrusted content from becoming authority.
- Detect merchant substitution, price drift, duplicate purchase attempts, repeated approval prompts, unusual velocity, and session takeover.
- Join the task, recommendation, approval display, user decision, payment, receipt, refund, dispute, and reconciliation in one trace.
- Map eligibility, privacy, payment, tax, recordkeeping, customer remedy, and liability obligations for each market served.
Bottom line
Claude Duet turns agent purchasing into a visible control sequence: connected context, a prepared transaction, user confirmation, payment-service approval, and a one-time card. The strongest KYA design preserves one evidence chain across that sequence. Single-use payment instruments reduce reuse risk; they do not replace operator identity, a precise mandate, controlled tool access, informed approval, complete audit evidence, abuse detection, or jurisdiction fit.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.