They need explicit consent, narrow permission scope and a clear distinction between the customer, the delegate and the transaction. The retailer should not assume the human’s approval extends to every action the agent might take. Governance has to bind authority to a specific purpose, not to a broad account state.
Why retailer governance has to treat the agent as a delegated actor
A shopping agent is not just a faster checkout shortcut. It is a delegated actor that can search, compare, add items, redeem offers, and sometimes complete purchases on the customer’s behalf. That means the retailer has to govern the authority the agent receives, the purpose it is allowed to serve, and the point at which a human is still required to confirm the transaction.
The practical distinction is between the customer as principal, the agent as delegate, and the transaction as the thing being authorised. If a retailer treats those as one and the same, it can accidentally widen consent beyond the intended purpose. That is why on-behalf-of flows are commonly grounded in explicit delegation models such as RFC 8693: OAuth 2.0 Token Exchange, which separates the original actor from the delegated credential used downstream.
Retail governance should also account for the identity relationship between humans and machine actors. The same purchase journey can involve a person, a shopping assistant, a browser session, a wallet, and a retailer API, so the control problem is really about who may act, for what purpose, and with what scope. NHIMG’s Human vs Non-Human Identity is a useful reference for that boundary because it clarifies where delegated access starts to behave differently from ordinary customer login.
What narrow permission scope should look like in practice
Good governance keeps the agent’s authority task-specific. A shopping agent may need permission to query inventory, compare prices, place items in a cart, or apply a narrow coupon, but it should not inherit a blanket right to manage the whole customer account. The more the agent can do, the more important it becomes to bind permissions to a single purchase purpose, a bounded time window, and a specific interaction context.
This is where per-action authorisation matters more than a one-time login event. If the agent is allowed to move from discovery to checkout, the retailer should still re-evaluate the high-impact step, especially when it changes address, payment method, quantity, or merchant terms. NHIMG’s AI Agent Authorisation Guide and Zero Trust for AI Agents both reinforce the same practitioner idea: authority should be continuously bounded, not assumed from the initial consent event.
Retailers should also be careful with shared sessions and embedded browser flows. If the agent can act using the customer’s active session, the retailer needs controls that prevent the agent from silently expanding from shopping into account administration. That separation is important because a valid customer session does not automatically mean every downstream action is equally intended.
How retailers should distinguish approval, delegation and transaction confirmation
The safest operating model is to treat approval at three different levels. First, the customer can allow the agent to represent intent. Second, the retailer can accept that delegation for limited actions. Third, the final transaction can still require a fresh confirmation when the impact crosses a threshold, such as a high-value order, recurring commitment, age-restricted goods, or a change to delivery or payment details.
That distinction prevents a common failure mode: organisations assume the customer’s original approval covers everything the agent later decides to do. It does not. The retailer should know whether the agent is browsing, negotiating, placing an order, or executing the final commitment, because each step carries a different trust requirement. The harder the transaction boundary, the more important it is to show the customer exactly what the agent is about to bind them to.
For commerce-specific use cases, NHIMG’s Agentic Commerce Identity Guide is directly relevant because it focuses on the mandate-like relationship behind AI-assisted purchases. The governance lesson is simple: purpose, scope and confirmation must travel together, or the retailer risks turning a narrow delegation into open-ended authority.
Risk and Threat Considerations
When retailers blur the line between customer intent and agent action, the exposure is not just policy confusion, it is abuse of delegated trust. A poorly governed shopping agent can overspend, bypass human judgement on product substitutions, or be manipulated into actions the customer never meant to approve. It also creates a clear attack path for consent abuse, session abuse, and unauthorized purchase activity.
Failure mechanism: The retailer accepts a broad delegated credential or session state, then applies it to actions that should have required separate confirmation or narrower authority. That makes it easier for malicious prompts, compromised agent logic, or an over-permissive integration to turn a limited shopping helper into a purchasing proxy.
Impact: Customers can be bound to unwanted transactions, retailers can absorb fraud and dispute overhead, and the organisation can lose trust in its consent model. At scale, weak delegation controls also make it harder to prove which actions were genuinely customer-directed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses 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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Shopping agents use delegated machine-like credentials and scoped authentication. |
| AC-6 — Least Privilege | Retailer governance needs narrow, task-specific agent permissions and action limits. | |
| IA-5 — Authenticator Management | Delegated shopping access depends on controlling tokens, secrets and their lifecycle. | |
| Recommendation — Apply IA-9 to bind agent authentication to a specific delegated service identity. Enforce AC-6 so agent access is limited to the minimum needed for the purchase task. Manage delegated credentials with IA-5 and revoke or rotate them when scope changes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about verifying each delegated action instead of trusting prior approval. |
| Recommendation — Verify each action and remove standing trust from the shopping flow. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Shopping agents can overstep delegated authority or inherit excessive privilege. |
| ASI09 — Human-Agent Trust Exploitation | Retail consent can be abused when humans over-trust an agent’s delegated actions. | |
| Recommendation — Apply ASI03 to constrain agent privilege to the intended shopping purpose. Use ASI09 controls to keep human approval separate from agent execution. | ||
Practitioner Guidance
What to verify: Require that the agent’s authority is explicit, time-bounded and purpose-bounded, and confirm that checkout, payment and account changes are separately controlled when the action materially changes customer obligation.
Common mistake: Do not treat “the customer is signed in” as a substitute for delegated intent. A valid session proves presence, not blanket authority for every agent action.
What good looks like: The retailer can show a clear consent record, a narrow scope, and a distinct confirmation step for the final purchase, with a traceable link between the human principal, the delegated agent and the transaction.
Practitioner takeaway: Govern shopping agents as delegated actors with bounded purpose, not as upgraded customers, because the security line is not whether the agent can act, but whether it can act only within the intent that was actually granted.