Why does agentic commerce increase identity risk for customer accounts?

Why agentic commerce changes the customer-account trust model

Agentic commerce shifts the trust boundary from a person acting directly to software acting with delegated intent. That matters because the customer’s authenticated session may no longer be the same as the actor making the purchase decision. The core risk is not just automation, it is the loss of a clean one-to-one relationship between customer, intent, and transaction.

When that relationship breaks down, the account stops behaving like a simple user session and starts behaving like a delegation container. The organisation now has to determine whether the agent was acting within the customer’s intent, whether the action was authorised at the right scope, and whether the resulting transaction can still be attributed back to a defensible trust decision.

That is why the question is really about identity governance inside commerce workflows, not just payment UX. The answer depends on whether the platform can represent who or what was allowed to act, what limits applied, and what evidence exists after the fact. Without that, the same authenticated customer account can be used for actions that are broader, faster, or less visible than the customer would normally initiate.

Where intent, scope, and attribution fail

Agentic commerce becomes risky when the system assumes customer login equals customer intent. An agent may browse, compare, add items, trigger checkout, or reuse stored payment methods without a fresh decision from the human. If the platform cannot separate these actions, it cannot enforce scope boundaries such as product limits, spending caps, merchant restrictions, or approval thresholds.

Scope failure often shows up as overbroad delegated authority. A session that is valid for account access is not automatically valid for every commercial action inside that account. The practical problem is that the platform may treat the whole session as trusted, even when only a narrow portion of the customer’s intent was actually expressed.

Attribution failure is equally important. If the transaction record only shows that the customer account was active, investigators cannot easily distinguish a deliberate purchase from agent-driven activity, a compromised workflow, or an action that exceeded the customer’s original instructions. That makes dispute handling, fraud review, and post-transaction accountability much harder.

What this means for customer identity controls in commerce

The main control challenge is to make delegated commerce explicit rather than implied. A customer-facing system should be able to represent who initiated the delegation, what the agent was allowed to do, how long that authority lasts, and which actions require human confirmation. If those rules are absent, the account becomes a shared capability rather than a controlled identity path.

This is also where commerce and identity security intersect with session design. The customer may have authenticated once, but the agent may need separate proof of authority for high-risk steps such as payment submission, address changes, loyalty redemption, or new beneficiary creation. The stronger the financial or reputational impact of the action, the less acceptable it is to rely on ambient login state alone.

For platforms building this capability, the practical standard is not “can an agent use the account” but “can the business prove what that agent was authorised to do.” That proof needs to survive across devices, vendors, retries, and automated steps, otherwise the trust model becomes too weak for meaningful customer protection.

Risk and Threat Considerations

Agentic commerce increases exposure because delegated tools, browser automation, or embedded assistants can operate inside a valid customer session while exceeding the customer’s real intent. That creates a path for unintended purchases, abuse of stored payment methods, and ambiguous accountability when fraud teams try to reconstruct what happened.

Failure mechanism: The account session is treated as a blanket trust boundary even though the agent is only authorised for a subset of actions, so the platform cannot reliably distinguish customer intent from agent execution or compromise.

Impact: Organisations face higher fraud, weaker dispute resolution, greater customer confusion, and a larger blast radius when a delegated workflow is misused or hijacked.

Practitioner Guidance

What to verify: Confirm that the commerce platform can distinguish authentication from delegated authorisation. If the account can place orders, change fulfilment details, or use stored instruments without a separate policy decision, the control model is too coarse for agentic commerce.

Decision rule: Treat any action with irreversible financial, reputational, or privacy impact as requiring explicit scope, expiry, and traceability. If you cannot express the allowed action set in a way that survives audit, do not treat the session as a safe delegation channel.

What good looks like: The customer can see what the agent was allowed to do, the platform can log the request and decision path, and high-risk steps still require a fresh confirmation signal. That is the minimum standard for preserving trust when software acts on behalf of a person.

Practitioner takeaway: Agentic commerce is risky when the session authenticates the customer but fails to constrain the agent; the control objective is to keep delegated actions narrow, explicit, and attributable.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?
• Why do AI agents create new risk in non-human identity management?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?