Identity linking is the missing control for agentic commerce

At a glance

What this is: This is a developer-focused analysis of Universal Commerce Protocol and identity linking for agentic commerce, showing that checkout flows need a verified user identity to support personalization, order history, and auditable transactions.

Why it matters: IAM and identity architects need to treat agent-to-store sessions as governed user sessions, because anonymous agent activity creates gaps in authorisation, traceability, and downstream account linkage across commerce workflows.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Descope's guide to building an ecommerce UCP server with identity linking

Context

Identity linking is the control that lets an agent act on behalf of a known user instead of starting every session anonymously. In agentic commerce, that difference determines whether checkout can be personalised, whether orders can be tied back to a customer, and whether the transaction leaves a usable audit trail.

The governance gap is not the shopping workflow itself, but the absence of a reliable user binding step between an agent session and merchant systems. Once that link exists, IAM, consent, scope enforcement, and downstream account lifecycle controls can operate on the session instead of on guesswork.

This is an agentic identity problem, not just a commerce integration problem. The article's core point is that agent sessions need the same identity continuity that human users already expect across web and mobile touchpoints.

Key questions

Q: How should security teams handle agent checkout flows that start without a verified user identity?

A: They should allow anonymous browsing but require identity linking before any checkout, order lookup, or other user-specific action. That keeps the agent useful without letting it create financial commitments or customer records without accountability. The control point is the transition from exploration to commitment, where consent and scope must both be present.

Q: Why do agent-driven shopping flows need user identity continuity?

A: Because the commercial value of the session depends on recognising the customer across tasks and channels. Without continuity, loyalty pricing, saved addresses, order history, and receipt routing all fail, and the merchant cannot prove who approved the action. Identity continuity turns the agent from an anonymous requester into a governed delegate.

Q: Where does agent authorisation fail if scope is checked only at login?

A: It fails the moment the agent tries to switch from a low-risk browse action to a sensitive operation like checkout or order retrieval. Login-time approval does not distinguish between tool types, so the agent can overreach within the same session. Tool-level scope checks are what preserve least privilege in practice.

Q: What should teams do with consent and identity records for agent purchases?

A: They should retain the consent artefact, token scope set, and user binding so support, fraud, and audit teams can reconstruct the transaction later. That evidence is what converts delegated commerce from a black box into a reviewable identity event. If the record cannot be recovered, the governance model has failed.

Technical breakdown

How UCP discovery exposes identity and capability metadata

Universal Commerce Protocol uses discovery metadata so an agent can learn what a store supports before making requests. The /.well-known/ucp document advertises the MCP endpoint, available capabilities, OAuth scopes, and payment handlers. That matters because the agent no longer needs store-specific logic to know whether it can browse catalog data, create a checkout, or read order history. The protocol separates discovery from authorisation, which keeps capability awareness and token validation distinct. In practice, this turns agent onboarding into a standard protocol exchange instead of a custom integration exercise.

Practical implication: Treat discovery documents as part of the trust boundary and validate which scopes each capability can actually invoke.

How OAuth 2.0 identity linking binds an agent to a user

UCP identity linking uses OAuth 2.0 Authorization Code flow with PKCE so the agent can obtain a token with user identity claims and approved scopes. The merchant sees sub, email, and name only after the user consents, which means the agent is acting with a verified identity rather than an anonymous token. This is the critical distinction between a tool call and an authorised user action. The server then uses those claims to attach checkout activity, receipts, and order history to the correct account. In identity terms, this is delegated access with traceable consent, not free-floating automation.

Practical implication: Require linked identity before any action that creates financial commitment or writes customer records.

Why scope enforcement must sit at the tool boundary

The example implementation checks required scopes per tool call rather than only at login. That design matters because an agent may be allowed to browse catalog data while still being blocked from checkout management or order retrieval. By inspecting the JSON-RPC request and matching tool names to scope requirements, the middleware can return either 401 identity_required or 403 insufficient_scope. This is a practical model for least privilege in agentic commerce: the token alone is not enough, and every sensitive operation needs its own authorisation decision.

Practical implication: Enforce tool-level scope checks so browsing, purchasing, and order access do not inherit the same privilege.

NHI Mgmt Group analysis

Identity linking is the control that prevents agentic commerce from collapsing into anonymous transaction handling. Without a verified user binding, an agent can move through browse and checkout states without any durable answer to who authorised the action. That breaks receipt routing, order history, loyalty attribution, and dispute handling in one stroke. Practitioners should treat identity linking as the prerequisite for governed agent commerce, not as an optional convenience.

Anonymous agent sessions create a governance gap that classic ecommerce patterns were not built to absorb. Guest checkout was designed for humans who still present a stable browser session, payment context, and account recovery path. An agent without a linked identity is not the same thing. The merchant may have a valid token, but still lacks the accountable subject needed for access review, customer support, and transaction traceability.

Scope is the real unit of control in agentic commerce, not the session itself. A browse-only agent and a checkout-capable agent should not carry the same privileges, even if both use the same MCP connection. This is where UCP's separation of discovery, consent, and tool authorisation matters. Practitioners should see the session as a container and the scope as the governable boundary.

Identity continuity is now a lifecycle issue, not just an authentication issue. Once an agent can place orders, retrieve purchase history, and trigger downstream fulfilment, the merchant is managing a persistent delegated relationship. That relationship needs provisioning, revocation, and audit like any other non-human identity. The implication is clear: agentic commerce must sit inside IAM and lifecycle governance, not beside them.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• For related analysis, OWASP Agentic AI Top 10 helps teams map agent behaviour to control failures.

What this signals

Agentic commerce will force IAM teams to think in terms of delegated customer identity, not just service authentication. If the agent can buy, reorder, and retrieve history, then the merchant is operating a customer session with non-human execution. That means consent, claim propagation, and revocation need to behave like lifecycle controls, not like one-off API authorisations.

With 80% of organisations already reporting AI agents acting beyond intended scope, the operational risk is that commerce teams will confuse usability with governance. The more the buyer experience depends on automation, the more important it becomes to keep account binding, scope isolation, and audit records intact across the full transaction path.

For practitioners

• Require linked identity before purchase completion Block checkout completion until the agent has a verified user binding, and reserve anonymous sessions for catalog browsing only.
• Separate browse scopes from transaction scopes Map catalog access, checkout management, and order retrieval to distinct scopes so the agent cannot inherit payment or customer data privileges from browsing.
• Make consent claims auditable end to end Preserve the user consent record, token scopes, and session identifiers so finance, fraud, and support teams can reconstruct who authorised the action and when.
• Tie downstream systems to verified identity claims Use the linked sub, email, and name claims to drive receipts, CRM updates, returns, and loyalty workflows instead of relying on whatever the agent typed in chat.

Key takeaways

• Agentic commerce fails when the session cannot be bound to a verified user, because the merchant loses accountability, personalisation, and traceability at once.
• Scope-based authorisation at the tool level is what keeps browse, checkout, and order access separated in practice, rather than in theory.
• Identity continuity has become a lifecycle requirement for AI-driven commerce, so provisioning and revocation must cover delegated agent sessions as well as human accounts.

Key terms

• Identity Linking: The process of mapping multiple login methods to one governed user record. It lets a single person authenticate through different providers without creating duplicate accounts, which is essential for lifecycle control, audit consistency, and access decisions.
• Agentic Commerce: Agentic commerce is a buying and transaction model where software agents act on behalf of a person. The identity challenge is not just proving who owns the account, but constraining what the agent may do, for how long, and under what revocation and audit rules.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.

What's in the full article

Descope's full article covers the operational detail this post intentionally leaves for the source:

• A complete FastMCP implementation showing how the UCP server, OAuth provider, and checkout tools fit together
• The exact discovery document fields used for capabilities, payment handlers, and identity linking scopes
• Sample middleware logic for enforcing tool-level scope checks and returning structured UCP error envelopes
• End-to-end code for storing order history under the user's sub claim and reusing verified claims downstream

👉 Descope's full article shows the UCP server code, scope enforcement logic, and downstream identity handling details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.