Who should be accountable for AI agent shopping risk?

Why This Matters for Security Teams

AI agent shopping risk sits at the intersection of delegated authority, payment exposure, fraud detection, and customer trust. The accountability question is not academic: if an agent can browse, compare, buy, cancel, or request refunds, then it can also exceed intent, bypass approval logic, or be manipulated by prompt injection and social engineering. Governance needs to define who owns policy, who monitors abuse, and who accepts residual risk.

That ownership should be explicit because agentic commerce often reuses existing identity and transaction controls without adapting them for autonomous action. Current guidance suggests mapping the problem to both AI governance and access governance, using the principles in the NIST AI Risk Management Framework and the attack patterns in the MITRE ATLAS adversarial AI threat matrix. NHIMG research on agentic applications shows why this matters in practice, especially where tool access and credentials are reused across workflows; see OWASP Agentic Applications Top 10.

In practice, many security teams encounter uncontrolled shopping or payment behaviour only after a disputed transaction, a refund abuse case, or an access review finds that no single owner can explain the decision path.

How It Works in Practice

The accountable party is usually the business owner of the shopping experience, not only the security team. That owner should define permitted actions, transaction limits, escalation thresholds, approved vendors, and customer-impact rules. Security, fraud, legal, and product teams then implement shared controls, but they do not all share equal accountability. One named owner must be able to approve policy changes and accept the residual risk when the agent acts within delegated bounds.

Operationally, the model works best when agent behaviour is constrained by identity-aware policy. The agent should authenticate as a distinct non-human identity, operate with least privilege, and use scoped credentials or tokens for each step of the workflow. Shopping systems should log intent, merchant selection, price comparisons, cart changes, approval prompts, and final purchase actions so that fraud analysts can reconstruct the full chain of events. For agentic controls, the guidance in OWASP Agentic AI Top 10 is especially relevant, because it highlights tool abuse, prompt injection, and over-permissioned agents.

NHIMG analysis of agentic risk patterns reinforces that weak delegation design is a common failure mode; the OWASP NHI Top 10 and the Gemini AI Breach -- Google Calendar Prompt Injection case study both show how hidden instructions can alter downstream action when execution authority is not tightly bounded.

• Policy owner: accountable for allowed use, merchant rules, and escalation thresholds.
• Fraud owner: accountable for anomaly detection, dispute handling, and abuse response.
• Security owner: accountable for identity, logging, secrets, and revocation controls.
• Commerce or product owner: accountable for customer experience and refund or cancellation policy.

These controls tend to break down when the agent is embedded in consumer checkout flows that are optimised for speed, because teams then treat autonomous purchase actions like ordinary user clicks rather than governed machine execution.

Common Variations and Edge Cases

Tighter control often increases checkout friction and operational overhead, so organisations must balance customer convenience against fraud loss and mispurchase risk. There is no universal standard for this yet, and current guidance suggests using different accountability models for low-value, high-frequency purchases versus high-value or regulated transactions.

For example, a consumer retail assistant may allow automated cart building but require human approval at final payment, while a corporate procurement agent may need separate approval for vendor onboarding, budget checks, and contract acceptance. In regulated or high-loss environments, accountability should extend beyond the product team to finance, legal, and incident response. That is especially true where the agent can access stored payment methods or corporate cards, because the identity control plane and payment control plane become one risk surface. The broader governance pattern aligns with NIST Cybersecurity Framework 2.0 and with incident handling discipline from NIST AI Risk Management Framework.

One practical edge case is delegated family shopping, where account sharing, age verification, or customer authorisation can blur who approved the action. Another is marketplace automation, where the agent may act on behalf of merchants, buyers, or support staff at different times. In both cases, the safe answer is not to assign accountability to “the AI” but to define who owns delegation policy, who can revoke authority, and who decides when a transaction is reversible. Best practice is evolving, but clear human accountability remains non-negotiable.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why does shift-left security not fully solve AI agent risk?
• When should organisations treat an AI agent as a high-risk identity?