Agentic commerce protocols expose the identity layer underneath checkout

At a glance

What this is: This guide maps the emerging agentic commerce protocol stack and shows that identity, delegation, and scoped authorization are the real prerequisites behind agent-driven checkout and machine payments.

Why it matters: It matters because IAM, NHI, and autonomy governance teams will need to secure agent authentication, delegated authority, and payment-scoped credentials before these flows can be trusted in production.

By the numbers:

• OpenAI’s Instant Checkout is in production serving ChatGPT’s 900 million weekly active users.
• Even prior to x402’s standardization in September 2025, sites on Cloudflare sent over 1 billion HTTP 402 responses daily.

👉 Read Descope's guide to the agentic commerce protocol stack and identity layer

Context

Agentic commerce is the use of AI agents to discover products, assemble carts, and complete purchases on behalf of a person. The immediate governance issue is not the payment rail itself, but the identity chain that has to prove who the agent is, what it is allowed to buy, and how long that delegation remains valid.

This article is really about the authentication and authorization layer underneath agentic commerce. Once agents can browse, negotiate, and initiate payment flows, existing IAM models have to account for delegated credentials, scoped consent, and machine-to-machine trust across MCP, commerce orchestration, and payment protocols.

Key questions

Q: How should security teams govern agentic checkout without losing control of payment authority?

A: Security teams should govern agentic checkout as a delegated identity problem, not just a payment problem. The controls that matter are explicit scope, short duration, merchant binding, and revocation. If the agent can discover products, build carts, and complete payment, then identity policy must follow the full path from authentication to checkout completion.

Q: Why do agentic commerce protocols create new IAM risks?

A: They create new IAM risks because the transaction is no longer initiated only by a person. An agent can hold scoped authority, act across multiple systems, and complete steps faster than human review cycles can react. That makes delegation governance, consent binding, and lifecycle control more important than transaction convenience.

Q: What breaks when delegated checkout authority is too broad?

A: When delegated checkout authority is too broad, the agent can buy outside the user’s intent, merchant restrictions, or budget expectations. The failure is not just overspending. It is loss of control over who can act, what they can purchase, and whether the authorization should still exist at the moment of payment.

Q: Which identity controls matter most for merchant-side agent integrations?

A: Merchant-side agent integrations need authentication, authorization, and revocation to work together. The merchant should know the agent’s identity, the user being represented, the accepted payment handler, and the current scope of permission. Without that chain, the commerce flow can be technically functional but governance-poor.

Technical breakdown

Shared Payment Tokens and scoped checkout authority

ACP’s Shared Payment Token is a bounded authorization credential, not a payment instrument. It scopes a charge to a specific merchant and amount, then lets the merchant complete the transaction without exposing raw card data to the agent. That pattern shifts risk away from payment secrecy and toward delegation control, because the token is only as safe as the rules that define its scope, duration, and reusability. In identity terms, it behaves like a narrow-purpose NHI credential for a single transaction path.

Practical implication: treat payment-scoped tokens as delegated identity assets and enforce explicit limits on amount, merchant, and expiry.

Why UCP depends on transport-agnostic identity and policy

UCP is built around typed request and response schemas that can move over REST or JSON-RPC, which makes it compatible with MCP and other agent interfaces. The protocol is not merely a checkout wrapper. It defines how the merchant advertises capabilities, how payment handlers are discovered, and how the checkout state is assembled. That means identity policy cannot live only inside the frontend experience. It must remain consistent across transport layers, handler selection, and merchant-owned processing.

Practical implication: align merchant identity policy and payment-handler trust rules before exposing UCP flows to agents.

AP2 and cryptographic proof of human consent

AP2 addresses a classic delegation problem: how to prove a person authorized a purchase when the human is absent at checkout. It does this with mandates, which are cryptographically signed and tamper-evident. Intent mandates support autonomous shopping within defined constraints, while cart mandates capture approval for a specific basket and price. The security value is evidentiary, not magical. AP2 creates non-repudiable proof, but it still depends on upstream identity binding, mandate integrity, and consistent interpretation by issuers and merchants.

Practical implication: use mandate-based controls where auditability and dispute evidence matter more than simple transaction approval.

NHI Mgmt Group analysis

Delegated commerce creates an identity stack, not just a payments stack. ACP, UCP, AP2, x402, and MPP each solve a piece of the transaction, but none of them remove the need to authenticate the agent, bind it to a user, and constrain what it can do. The real governance problem is that checkout has become a chain of delegation events, each with its own trust boundary. Practitioners should stop treating payment as the only control point and start governing the identity path end to end.

Shared Payment Tokens are a form of payment-scoped NHI, not a convenience feature. The token represents a bounded right to act, and that makes scope, expiry, and merchant binding the security properties that matter. If those controls are weak, the agent does not need to steal a card to cause damage. It only needs an overbroad delegated token. Practitioners should evaluate these tokens as part of NHI lifecycle governance, not as isolated checkout artifacts.

Mandates formalise evidence, but they do not remove the need for delegation governance. AP2 improves proof of consent by making user authorization cryptographically verifiable. That matters for chargebacks and dispute handling, but it also raises the bar for identity binding, mandate issuance, and revocation logic. The governance lesson is that stronger evidence does not replace lifecycle control. Practitioners should design for provable consent and provable expiration at the same time.

Delegated checkout drift: the biggest risk is not that agents can pay, but that the authorization context can outlive the user intent that created it. Commerce protocols assume the original permission remains valid through product discovery, cart assembly, checkout, and payment completion. In fast-moving agentic flows, that assumption is easy to break if the delegation scope is not continuously enforced. Practitioners should regard this as a governance boundary that must be monitored, not a one-time approval event.

MCP is becoming the front door for agentic commerce governance. Because the commerce protocols fit into MCP-connected ecosystems, authentication at the connector layer now determines what downstream commerce actions are even possible. That means IAM teams and platform teams can no longer separate connector governance from transaction governance. Practitioners should align agent authentication, delegated authorization, and merchant policy before these channels scale.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• To go deeper on lifecycle control, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows how rotation, offboarding, and review need to work together.

What this signals

Delegated commerce will force identity teams to treat payment credentials like governed non-human identities. Once an agent can hold a scoped right to spend, the control problem becomes lifecycle management, not checkout UX. The practical question is whether your programme can issue, bound, review, and revoke delegated authority with the same discipline you apply to other machine identities.

Agentic commerce also increases the value of a clear delegation ledger. When agents act across discovery, cart building, and payment completion, security teams need evidence that links the user, the agent, the merchant, and the authorizing mandate. That makes auditability a programme requirement, not an afterthought, especially where consent must be demonstrated later.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, per the Ultimate Guide to NHIs, the broader lesson is that governance often fails before the transaction even begins. Agentic commerce will inherit that same exposure unless identity and secret handling are designed together.

For practitioners

• Define delegation scopes for agent checkout Limit agent purchase authority by merchant, amount, time window, and allowed product categories so the delegation cannot expand during browsing or cart building.
• Classify payment tokens as lifecycle-managed credentials Track Shared Payment Tokens and similar artifacts as identity assets with issuance, expiry, revocation, and audit ownership instead of treating them as disposable session data.
• Bind agent authentication to merchant policy Require a clear identity link between the agent, the user it represents, and the payment handler the merchant accepts before allowing checkout execution.
• Separate consent evidence from transaction approval Use cryptographic mandates or equivalent evidence only where non-repudiation matters, and make sure consent records are still revocable when the user relationship changes.

Key takeaways

• Agentic commerce is an identity governance problem disguised as a payments problem.
• The evidence shows that scoped delegation, not raw transaction speed, is what determines whether agents can act safely at scale.
• Practitioners should govern agent checkout as a lifecycle-controlled credential flow with explicit scope, expiry, and revocation.

Key terms

• Shared Payment Token: A Shared Payment Token is a bounded authorization credential used in agentic commerce. It lets an agent initiate a specific charge without exposing raw payment details. The security value comes from scope, amount, and time limits, which turn the token into a controlled delegation artifact rather than a reusable payment secret.
• Intent Mandate: An Intent Mandate is a cryptographically signed authorization that lets an agent make purchases within defined limits when the user is absent. It records the identity being represented, the spending boundary, and the permitted merchant context, making consent provable and later reviewable.
• Merchant of Record: The Merchant of Record is the party legally and operationally responsible for the sale and payment completion. In agentic commerce, that role matters because identity controls, dispute handling, and payment processing all converge there, even when an AI agent handles discovery or cart assembly.
• Delegated Identity: Delegated identity is the pattern where one identity is authorized to act on behalf of another. In agentic commerce, it spans authentication, consent, scope, and revocation, so the delegation must be bound tightly enough that the acting agent cannot outlive the user intent behind it.

What's in the full article

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

• Protocol-by-protocol implementation detail for ACP, UCP, AP2, x402, and MPP across real agentic commerce flows.
• How the Shared Payment Token, mandates, and HTTP 402 mechanics work in practice across merchant and platform integrations.
• Examples of where MCP sits in the stack and how it connects agents to merchant infrastructure.
• Vendor-specific product positioning and ecosystem references that support implementation planning.

👉 Descope's full post covers ACP, UCP, AP2, x402, MPP, and MCP integration detail for practitioners

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.