Shopping assistants should be allowed to complete a purchase only when the delegated scope covers that exact transaction, the basket matches the user’s policy, and the request passes a human approval step for price, merchant, or shipping exceptions. A common control is to require one-time confirmation or JIT approval before payment authorisation, while routine replenishment can be pre-authorised within strict limits.
When is a shopping assistant acting within approved buying authority?
A shopping assistant should only be treated as authorised when the purchase matches the user’s delegated scope exactly, including merchant category, spend ceiling, timing, and product constraints. If the assistant is outside those bounds, it is no longer executing a routine transaction, it is making a new discretionary decision that needs fresh approval.
That distinction matters because purchase authority is not just about whether the assistant can click “buy”, it is about whether the user has already accepted that exact buying decision in advance. Routine replenishment is the clearest fit for standing authority, while one-off or ambiguous purchases should be paused for confirmation.
What should be checked before letting the assistant pay?
The assistant should verify the basket against policy before payment is authorised. That means confirming the items, quantity, merchant, total cost, shipping method, and any exception conditions that the user cares about, such as expedited delivery or a different seller. If any of those elements drift, the assistant should stop and seek approval rather than infer permission.
A useful control is to compare the proposed checkout against the user’s pre-set purchase rules, not against the assistant’s own interpretation of “reasonable” shopping behaviour. This is especially important when the assistant can substitute products, bundle items, or accept default shipping options that may be acceptable technically but not financially or operationally.
For shoppers who want automation without losing control, AI Shopping Agents Safety Guide is the most practical companion for understanding capped payment methods, approval modes, and disputed orders.
How should approval work when the assistant reaches the checkout?
Approval should be explicit when the transaction changes in a way that matters to the user, especially for price, merchant, or shipping exceptions. A one-time confirmation step is usually the safest pattern for that boundary, while JIT approval works well when the assistant is allowed to prepare the cart but not finalise payment until a person authorises it.
That approach preserves convenience for routine purchases but creates a hard stop for anything that could widen the blast radius of a mistake or abuse. It also reduces the chance that the assistant turns a browsing task into a committed purchase because of a misleading prompt, a bad product substitution, or an unexpected checkout default.
Risk and Threat Considerations
Allowing a shopping assistant to purchase without tight scope and approval controls creates a straightforward exposure: the assistant may complete the wrong transaction, exceed the user’s intended spend, or buy from an unintended merchant. The same weakness can be abused if a prompt, page content, or linked workflow nudges the assistant toward a purchase the user never meant to approve.
Failure mechanism: delegated authority is broader than intended, or the checkout flow fails to force a human decision when the basket deviates from policy, so the assistant can authorise payment on an exception path.
Impact: unauthorised spend, poor merchant choice, delivery to the wrong address or timeline, and harder dispute handling because the transaction may appear to have been “approved” by the automation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Checkout authority must be bounded to avoid excess purchase power. |
| NHI-07 — Long-Lived Secrets | Stored payment tokens or delegated credentials can extend purchase authority too long. | |
| Recommendation — Limit delegated purchasing scope and spend ceilings to the minimum needed. Use short-lived payment grants and rotate or revoke them after use. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The assistant can abuse delegated buying authority if approval is too broad. |
| ASI09 — Human-Agent Trust Exploitation | Shopping flows can pressure users into trusting an unintended checkout decision. | |
| Recommendation — Constrain agent authority and require human approval for exception purchases. Design checkout prompts to resist deceptive or ambiguous approval requests. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Purchase permissions should be no broader than the specific buying task. |
| IA-5 — Authenticator Management | Any payment token or delegated credential used for buying needs controlled lifecycle handling. | |
| AU-2 — Event Logging | Purchase approval and checkout events need evidence for dispute and review. | |
| Recommendation — Grant only the minimum purchasing privileges needed for the task. Manage delegated payment credentials with rotation, revocation, and expiry controls. Log approval, basket, and payment events for traceability. | ||
| NIST Zero Trust (SP 800-207) | SC-1 — Zero Trust Architecture | Each purchase decision should be re-verified rather than assumed from prior trust. |
| Recommendation — Re-verify each checkout action before authorising payment. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A checkout API can expose payment functions beyond the assistant's intended rights. |
| Recommendation — Enforce function-level checks before any payment-authorising call. | ||
Practitioner Guidance
What to verify: Make the assistant prove that the final basket still matches the policy the user actually delegated. The key check is not whether the purchase is plausible, but whether every material field in the checkout still falls inside the allowed scope.
Decision rule: If the transaction is routine, repeatable, and within a defined limit, pre-authorisation can be acceptable. If the assistant must choose between merchants, accept a substitute, pay more than expected, or alter shipping, require a fresh human confirmation before payment is released.
Practitioner takeaway: The safest model is to let the assistant assemble and propose a purchase, but only let it complete the transaction when the exact buying decision has already been authorised or is explicitly re-approved at checkout.
Related resources from NHI Mgmt Group
- What breaks when autonomous shopping agents are allowed to act without strong governance?
- What breaks when AI assistants are allowed to act on behalf of users without policy checks?
- What breaks when hidden prompt injection is allowed in AI code assistants?
- What breaks when AI assistants are allowed shell access on unmanaged devices?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org