It is both, but the identity question comes first. If merchants cannot determine whether an order was placed by an authorised agent, a benign automation flow or a malicious bot, then bot controls alone will be too blunt. The better model is to govern delegated commerce identity, then apply fraud controls on top.
Why agentic commerce is not just a bot detection problem
Merchants should start by asking who, or what, is actually authorised to act. A bot can be blocked by rate limits and CAPTCHA, but an authorised agent may need to place orders, negotiate, or complete checkout on a customer’s behalf. That means the security question is not only “is this automated?”, it is “what delegated authority, if any, is behind this action?”
The practical difference is that bot controls are designed to separate humans from automation, while commerce identity controls are designed to separate legitimate delegated actions from unauthorised ones. That matters because the same order flow can be benign, expected automation, or abuse. Merchants need a way to recognise the principal, the mandate, and the scope of permission before they decide which controls to apply.
That is why identity-first design fits agentic commerce better than a pure fraud or bot lens. If the platform can verify an agent identity and tie it to a customer-authorised intent, the merchant can preserve conversion for good automation while still reserving stronger checks for suspicious patterns, unusual spend, or high-risk fulfilment paths.
What identity adds that bot controls cannot
Identity turns a vague traffic signal into a governance model. It lets a merchant ask whether the requester is a customer-controlled agent, a partner integration, an internal automation, or an untrusted script. That distinction changes policy, logging, risk scoring, and dispute handling. It also creates room for delegated commerce patterns such as scoped credentials, transaction-specific approval, and revocation when the relationship ends.
Bot detection alone cannot express those differences cleanly. A bot classifier may spot headless browsing or high-volume retries, but it will not tell you whether a tool is acting within its mandate. For that, merchants need to govern agentic commerce identity, not just traffic patterns, and they need AI agent authorisation so the order action is bounded to the task, merchant, amount, and context.
That also changes how you think about credentials. In delegated commerce, the credential is not the goal, it is the proof that a specific agent may act for a specific principal under specific limits. If the credential or token is broad, long-lived, or reusable across contexts, the merchant has effectively converted a commerce flow into an open-ended access problem. The right control model is to use delegated agent identity with narrow scope and clear lifecycle rules.
How merchants should treat delegated commerce in practice
Merchants should classify agentic commerce by trust level, not by whether the channel looks automated. The first decision is whether the order is backed by a verifiable mandate from a known customer, a partner contract, or an internal workflow. The second is whether the request is constrained enough to allow the merchant to permit it without weakening fraud posture for everyone else.
A useful implementation pattern is to separate identity proofing from action authorisation. Verify the actor or agent once, then make per-order policy decisions on amount, product type, shipping destination, velocity, and change in risk. That is the point at which identity and fraud controls meet: identity tells you who may act, while fraud analytics tells you when that authorised action still looks abnormal.
Merchants also need to think about lifecycle, not only onboarding. An authorised agent should be easy to suspend, rotate, or retire when a customer changes tools, revokes consent, or the merchant detects misuse. The operational benefit of an identity model is that it gives you something concrete to revoke, not just a pattern of behaviour to suppress.
Risk and Threat Considerations
Agentic commerce creates two distinct exposure paths: false positives when benign automation is treated like hostile bot traffic, and false negatives when an unauthorised agent can buy, scrape, or manipulate commerce flows while appearing legitimate. The risk grows when merchants rely on bot signals alone, because those signals rarely capture delegated authority, scope, or revocation state.
Failure mechanism: The merchant applies a single bot-detection policy to all automated activity, so authorised agents are throttled or blocked while malicious automation adapts around the same controls. If the platform cannot distinguish a valid mandate from unauthorised automation, attackers can abuse that ambiguity to blend in with ordinary agent traffic.
Impact: Legitimate customers face checkout friction and failed orders, while merchants absorb fraud loss, dispute complexity, and weaker trust in their automation channels. Over time, the organisation either over-tightens controls and hurts conversion, or relaxes them and creates a broader abuse surface.
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 MITRE ATT&CK address the attack and risk surface, while NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agentic commerce depends on proving authorised agent identity. |
| NHI-05 — Overprivileged NHI | Merchant risk rises when agent credentials can act beyond a narrow mandate. | |
| NHI-07 — Long-Lived Secrets | Reusable agent tokens weaken revocation and increase commerce abuse exposure. | |
| Recommendation — Require verifiable authentication for delegated commerce agents before allowing checkout actions. Scope delegated commerce credentials to the minimum actions and merchants needed. Use short-lived credentials and rotate or revoke them when mandates change. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question centers on whether agent authority is legitimate or abused. |
| ASI09 — Human-Agent Trust Exploitation | Delegated commerce can be abused when users or merchants over-trust agents. | |
| Recommendation — Bind each commerce action to an approved principal and policy decision. Add confirmation and trust checks for high-impact agent purchases or changes. | ||
| NIST Zero Trust (SP 800-207) | None — Zero Trust Architecture | The answer requires continuous verification of principal and request, not network trust. |
| Recommendation — Verify every commerce action continuously and deny standing trust by default. | ||
| OWASP ASVS | V8 — Authorization | Commerce flows need action-level authorization beyond simple bot detection. |
| Recommendation — Enforce per-action authorization for checkout, refund and fulfilment changes. | ||
| MITRE ATT&CK | T1583 — Acquire Infrastructure | Bot-like abuse often begins with infrastructure used to automate commerce attacks. |
| Recommendation — Map abusive automation to attacker infrastructure and hunt for repeatable staging patterns. | ||
Practitioner Guidance
What to prioritise: Build a trust model that records the agent, the principal, the mandate, and the permitted action before you tune bot controls. If you cannot answer those four questions, any anti-bot decision will be too blunt for production use.
What to verify: Confirm that your checkout and API policies can distinguish customer-authorised delegation from generic automation, and that revocation is operationally fast enough to matter when a token, mandate, or partner relationship changes.
Decision rule: If the order can change customer spend, shipping, or fulfilment state, treat it as an authorisation problem first and a bot problem second. Use bot detection as an additional signal, not as the primary trust boundary.
Practitioner takeaway: In agentic commerce, the safest merchant posture is to verify delegated identity and scope first, then let fraud controls decide whether a permitted action still deserves scrutiny.
Related resources from NHI Mgmt Group
- When does a machine identity become a compliance problem?
- Why do agentic commerce flows change identity risk for merchants and IAM teams?
- Should organisations treat agentic AI as a workload identity problem or an AI problem?
- Should security teams treat agentic AI as a policy problem or an identity problem?
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 October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org