What do organisations get wrong about identity verification for AI commerce?

Why This Matters for Security Teams

AI commerce changes the verification problem from “who logged in?” to “what is this identity allowed to do right now?” That distinction matters because buyers, sellers, agents, and delegated workflows can all act on behalf of another party after the original trust decision. Identity checks that stop at onboarding or session establishment miss consent drift, overbroad delegation, and tool abuse once an agent starts chaining actions across systems.

In practice, the biggest failure is assuming a verified identity stays equally trustworthy across every downstream transaction. Current guidance suggests treating commerce identity as an ongoing authorisation problem, not a one-time identity proofing event. That is especially important when credentials, tokens, or API keys are reused across order placement, fulfilment, refunds, and support. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the condition that turns a legitimate transaction path into a delegated misuse path.

Security teams also get caught by the pace of compromise. The same NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In AI commerce, that means a verified front-end user can still be routed through a compromised backend identity, a poisoned token, or an over-permissioned agent. In practice, many security teams encounter identity fraud only after an order, payout, or account takeover has already been executed, rather than through intentional transaction-level verification.

How It Works in Practice

identity verification for AI commerce works best when it is tied to each transaction step, not just the initial login. The practical model is layered: proof the party is who they claim to be, bind that identity to the specific purpose, and re-evaluate whether the requested action remains within policy before the action completes. That is closer to eIDAS 2.0 style assurance than a simple session cookie check, although there is no universal standard for AI commerce verification yet.

For autonomous or semi-autonomous commerce flows, static RBAC usually breaks down because the action sequence is not fixed. A shopping agent may search, compare, negotiate, authorize payment, request refunds, or open support cases in ways that were not predicted at onboarding. Better practice is evolving toward context-aware authorisation, where the system evaluates purpose, transaction amount, risk signals, device or workload posture, and delegation scope at request time. That means policy should not only ask “is this user verified?” but also “is this exact action still valid for this identity in this moment?”

• Use step-up verification for high-risk actions such as payment changes, shipping reroutes, or beneficiary updates.
• Prefer short-lived, purpose-bound tokens over long-lived credentials for agent and merchant workflows.
• Separate human identity proofing from workload identity so an AI agent can prove what it is and what it may do.
• Log the original consent, the current scope, and the transaction context for every delegated action.

NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the core point: excessive privilege and weak lifecycle control are what turn identity verification into a false sense of safety. These controls tend to break down in high-volume marketplaces and agent-mediated checkout flows because transaction speed pushes teams to over-trust the initial proofing event.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations have to balance fraud reduction against checkout abandonment, customer support load, and delegated-use convenience. That tradeoff is real, especially when the same account may be used by a consumer, a household, an assistant, or an automated agent. Best practice is evolving rather than settled, so the right answer depends on transaction value, reversibility, and downstream blast radius.

One common edge case is delegated commerce: a verified user grants an AI assistant limited authority to browse or purchase on their behalf, then later changes intent without revoking the delegation. Another is merchant-side automation, where order management agents, refund assistants, or customer service bots act with credentials that outlive the original policy decision. In these situations, verification must be paired with consent lifecycle controls, narrow scopes, and revocation paths.

Another overlooked issue is that identity proofing alone does not resolve account recovery or fraud disputes. If a compromised identity has already been approved for repeated actions, replayable tokens and stale entitlements can keep authorising transactions long after the original trust event. NHIMG’s LLMjacking research shows how quickly exposed credentials are abused in the wild, which is why verification must be linked to continuous permission checks, not just login certainty.

Related resources from NHI Mgmt Group

• What do organisations get wrong about identity verification during account recovery?
• What do organisations get wrong about storing identity verification evidence?
• What do organisations get wrong about identity verification orchestration?
• What do organisations get wrong about AI governance and identity controls?