They often treat every automated interaction as malicious and miss the difference between authorised delegation and hostile automation. In agentic commerce, some bot activity is legitimate, so the real control challenge is separating approved agent behaviour from takeover, impersonation and abuse.
Why retailers misread bot traffic in agentic commerce
Retail teams often collapse all automated traffic into one bucket, then apply fraud logic to every bot, every time. That is too crude for agentic commerce. The relevant question is not whether automation exists, but whether the request is a delegated, approved action or an unapproved one operating under stolen or misrepresented authority.
What separates legitimate agent activity from hostile automation
In agentic commerce, the same surface signals can describe very different behaviour. A shopping agent may be acting on behalf of a customer with limited scope, while a malicious actor may be trying to replay sessions, impersonate a principal, or abuse an exposed workflow. Retailers need to judge the authority behind the request, not just the speed or repetition of the traffic.
That means looking for evidence of delegation, transaction scope, and policy enforcement around the action itself. A legitimate agent should usually be tied to a specific principal, a bounded purpose, and a constrained set of operations. Hostile automation tends to break those assumptions by reusing credentials, bypassing consent, or pushing beyond the expected action path.
What good control design looks like for retailers
Useful control design starts by treating agent behaviour as a separate policy problem, not as a generic bot-blocking problem. Retailers should distinguish approved agent interactions from anonymous scraping, credential abuse, and takeover attempts, then apply different controls to each path. The control objective is to verify the actor, the delegation, and the request before allowing meaningful commerce actions.
This is where Agentic Commerce Identity Guide is most useful, because commerce-grade delegation only works when the agent can be tied to a real authority model. For enforcement, AI Agent Authorisation Guide helps separate task-scoped approval from broad, standing access. For operational oversight, AI Agent Observability, Audit and Incident Response Guide shows how to attribute actions and spot when an agent has gone off-rails.
Risk and Threat Considerations
Retailers that treat all bot traffic as hostile can miss the more serious failure mode, impersonation of a legitimate agent or abuse of a delegated session. The risk is not only false positives, it is also false trust, where an attacker blends into approved automation and inherits the access path meant for a customer or assistant.
Failure mechanism: The environment accepts automation without checking whether the request is bound to an approved principal, scope, and purpose, so a stolen token, replayed session, or overbroad delegation can look like normal commerce traffic.
Impact: Attackers can place orders, extract account value, abuse payment or checkout flows, and undermine trust in the whole agent channel, while defenders lose the ability to distinguish routine delegation from compromise.
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 |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic commerce failures often involve impersonation or overbroad delegated access. |
| Recommendation — Enforce per-action authorization and verify the acting principal before allowing commerce steps. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Retail agent traffic depends on authenticating non-human services and workloads correctly. |
| AC-6 — Least Privilege | Legitimate agent behavior must be narrowly scoped to avoid abuse of delegated access. | |
| Recommendation — Require strong service authentication for approved agent channels and reject unauthenticated automation. Limit agent permissions to the minimum actions needed for each commerce task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question hinges on verifying requests and removing implicit trust from automated traffic. |
| Recommendation — Continuously verify each agent request instead of trusting automation based on channel or origin. | ||
Practitioner Guidance
What to prioritise: Start with the commerce actions that move money, change account state, or create fulfilment risk. Those are the points where delegated automation and hostile automation most often diverge in consequence, even if they look similar in telemetry.
What to verify: Confirm that every approved agent flow has an explicit principal, a bounded purpose, and an action-level decision point. If you cannot explain who the agent is acting for, what it is allowed to do, and why this request is in scope, treat the interaction as untrusted until proven otherwise.
Practitioner takeaway: The winning model is not “block bots”, it is “prove authority before commerce”, because in agentic retail the difference between assistance and abuse is the decision context attached to the action.