The implementation rule
The model prepares intent. Structured policy grants commitment authority.
Never let narration become permission.Implementation guide
How to add household purchase approval to an AI shopping agent
Let the agent compare products and prepare a cart, then require explicit, role-aware, cart-bound authority before it crosses checkout.
STRUCTURED INTENTHOUSEHOLD ROLESCART FINGERPRINTBOUND APPROVALCHECKOUT REVALIDATIONVERIFIED RECEIPTSTRUCTURED INTENTHOUSEHOLD ROLESCART FINGERPRINTBOUND APPROVALCHECKOUT REVALIDATIONVERIFIED RECEIPT
Start with an authority boundary, not a confirmation modal
The most important implementation decision is where the shopping agent stops being an adviser and starts becoming a purchaser.
Before that boundary, the agent can interpret a household request, compare merchants, rank products, reason about preferences, identify substitutions, and prepare a cart. These activities can use flexible model reasoning because they do not commit funds or create an external order.
At the boundary, convert the model’s work into structured purchase intent. Record requester identity, household role, merchant, products, quantities, substitutions, final amount, fees, renewal terms, delivery address, payment source class, and an intent fingerprint. Do not ask a policy engine to parse a conversational summary at the last second.
The policy engine decides whether the cart fits delegated authority. It can permit routine checkout, request approval from a named role, require two adults, or block the purchase. The approval request should present material facts and bind the response to one cart fingerprint, ceiling, merchant, address, and validity window.
Immediately before commitment, fetch the live cart again. If material terms differ, invalidate or narrow approval according to policy. After checkout, verify the external order before declaring success or replaying an uncertain attempt. The result is a lifecycle, not a button.
Keep preparation broad
The agent can search, compare, explain, and assemble options without holding open-ended financial authority.
Bind the cart
Approval covers exact material fields and an allowed change policy, not a vague request such as “buy groceries.”
Bind the person
The approval response resolves to an authorized household role through a linked, risk-appropriate identity method.
Bind the outcome
The receipt correlates requester, policy, approver, committed cart, payment evidence, and external order state.
Build an approval request
Generated decision and payload
Approval required
Route this cart to any household adult and bind consent to the current material terms.
Model household roles
Define capability separately from identity
Create durable roles for adults, guardians, teenagers, children, caregivers, and guests. For each role, define who can prepare a cart, request approval, approve, purchase automatically, change payment settings, or create recurring charges. Temporary roles should have explicit expiration.
Normalize purchase intent
Move critical facts out of prose
Represent merchant, line items, quantities, category, substitutions, subtotal, fees, tax, delivery address, payment source class, recurring terms, and requester. Store source observations and freshness so the product can distinguish current checkout data from cached research.
Fingerprint material state
Know when approval no longer applies
Canonicalize the fields the household considers material and hash the representation. Include policy version and allowed tolerances. A fingerprint should change when price, item, quantity, fee, merchant, address, payment, or renewal terms cross the configured boundary.
Evaluate policy
Produce a decision, reason, and route
Return automatic approval, named approver, dual approval, or block. Include the matched rule, current risk, expiration, maximum amount, required identity assurance, allowed cart changes, and whether a constrained payment credential is required.
Capture bound consent
Approve this cart through this channel
Present the material terms in a scannable message. Tie the response to a specific challenge and authorized role. Record identity method, timestamp, policy version, cart fingerprint, ceiling, merchant, address, validity, and revocation state.
Revalidate at checkout
Compare the live target with authorization
Reload the cart immediately before the side effect. Recalculate material state, apply allowed tolerances, and confirm the approval is current and unrevoked. If the cart differs, return to approval rather than asking the model whether the change seems harmless.
Verify the order
Treat lost confirmation as unknown
After commit, capture the order identifier and verify products, total, merchant, address, and status. If the browser disappears, inspect from a fresh read-only session before replaying. Preserve an honest unknown state when neither completion nor absence can be established.
Write the receipt
Connect authority to external outcome
Store requester, intent, policy, approver, approval identity, authorized cart, committed cart, payment event reference, external order, verification evidence, and later cancellation or refund. Give the household a searchable human-readable view.
Start with three plain-language policies
Routine essentials
Allow automatic checkout for known household basics at trusted merchants below a modest total.
- No new recurring charge
- Known delivery address
- Price within tolerance
- Exact or approved substitutions
Novel purchase
Require one household adult when the item, merchant, category, or address is new.
- Show comparison rationale
- Expose fees and return terms
- Bind consent to cart
- Expire after a short window
High-impact commitment
Require a named primary approver or two adults for high value, gift cards, subscriptions, travel, or regulated categories.
- Step-up authentication
- No silent substitutions
- Constrained payment method
- Manual review on ambiguity
Implementation details that deserve first-class controls
Approval identity
A message response is not automatically consent.
Resolve the sender to a household account, role, active challenge, and appropriate authentication level. Handle forwarded messages, recycled numbers, shared devices, and expired sessions explicitly.
Policy versioning
Know which rule granted authority.
Bind approvals to immutable policy versions. If limits, roles, merchants, or categories change while a request is pending, reevaluate rather than honoring stale authority silently.
Revocation
Permission can disappear before commitment.
Support canceling one approval, removing an approver, suspending the agent, lowering limits, revoking a device, or disabling a payment route. Recheck revocation immediately before checkout.
Evidence boundaries
Model reasoning may interpret evidence but should not mint permission.
Use structured checks for identity, policy, cart equality, and external order state. Store model explanations separately from the control decision and underlying observations.
Minimum data contracts
Purchase intent
Requester, household, role, merchant, items, quantities, substitutions, totals, fees, tax, delivery, payment class, recurrence, source observations, timestamps, and material-state fingerprint.
Policy decision
Decision, matched rule, policy version, reason codes, required approver roles, identity assurance, amount ceiling, expiration, allowed changes, payment constraints, and escalation route.
Approval record
Approver, resolved role, authentication method, challenge identity, approved fingerprint, merchant, ceiling, address, recurring terms, timestamp, expiration, and revocation status.
Outcome receipt
Attempt identity, final cart, checkout time, external order ID, payment event reference, evidence source, verification classification, replay decision, notifications, and later lifecycle events.
Failure drills to run before launch
Cart changes after approval
Increase a fee, substitute an item, alter quantity, add a recurring term, and change the address. Confirm that each configured material change expires authorization and returns a clear new approval request.
Confirmation disappears
Terminate the browser or network immediately after the final click. Start a fresh session and reconcile the external order. Ensure the system never converts a timeout directly into permission to repeat.
Approval channel is attacked
Reply from an unlinked identity, reuse an old challenge, forward a prompt, approve after revocation, and inject instructions through merchant content. Verify that none expands household authority.
Implementation checklist
Preparation and commitment are separate workflow states.
Every requester resolves to a durable household role.
Material cart fields are structured outside model prose.
The cart fingerprint is canonical and versioned.
Policy returns decision, reason, approver route, and expiration.
Recurring charges receive explicit treatment.
Approval identity is linked to one active challenge.
Authorization binds merchant, amount, address, and allowed changes.
Revocation is checked immediately before checkout.
The live cart is revalidated against authorization.
Merchant content cannot expand tool or payment authority.
Lost confirmation routes to observation before replay.
Receipts connect intent, policy, consent, payment, and order.
Failure drills cover changed carts, stale approvals, and unknown outcomes.
Frequently asked questions
Can the shopping agent approve low-value purchases automatically?
Yes, when an authorized household adult creates a policy for narrow categories, merchants, addresses, limits, and recurrence. Automatic approval should still produce a policy decision and receipt and should not apply to novel high-risk categories by default.
Should the model decide whether approval is required?
The model can classify a product or explain risk, but a structured policy engine should own the permission decision. Model output may become one input, not the authority to mint consent or bypass a rule.
What should invalidate an approval?
Changes to merchant, price beyond tolerance, item, quantity, fee, subscription terms, payment class, or delivery address should be evaluated explicitly. The safest default is to require new approval for any material change.
How long should approval remain valid?
Use short windows tied to risk and target volatility. Routine carts might remain valid for minutes, not days. High-impact purchases may require immediate revalidation and step-up authentication.
How do text-message approvals stay secure?
Link the sender to a household identity and role, bind the reply to a specific active challenge, expire the challenge, and use stronger authentication when risk demands it. Do not interpret a free-floating “yes” as purchase consent.
What happens if checkout may have succeeded?
Keep the result unknown, inspect the merchant for a correlated order, and block replay until completion or absence is sufficiently established. Route unresolved high-impact outcomes to review.
Primary references
NIST AI Risk Management FrameworkGovernance and risk management guidance for trustworthy AI systems.
OWASP Top 10 for LLM ApplicationsSecurity risks relevant to prompt injection, excessive agency, and unsafe tool use.
W3C Web AuthenticationPublic-key credentials and stronger authentication for approval identity.
RFC 9110: HTTP SemanticsSafe and idempotent method semantics relevant to checkout recovery and replay.
Let the agent prepare. Make commitment explicit.
Super connects messaging and computer-use workflows where household shopping can stay convenient without turning model confidence into financial authority.
Explore Super