TL;DR: Agentic commerce now spans ACP, UCP, AP2, x402, and MPP, but the real control plane is the identity layer that authenticates agents, binds delegation, and scopes payment authority, according to Descope. The governance problem is not checkout alone; it is proving who the agent is, what it may do, and when that authorization expires.
At a glance
What this is: This is a guide to agentic commerce protocols that argues the critical security problem sits underneath checkout: proving which agent is acting, on whose behalf, and within what scope.
Why it matters: It matters because identity teams now have to govern delegated agent access across commerce, payment, and MCP-connected workflows, not just traditional user sessions.
By the numbers:
- OpenAI's Instant Checkout is serving ChatGPT's 900 million weekly active users.
- OpenAI's Instant Checkout is in production serving ChatGPT's 900 million weekly active users.
Context
Agentic commerce is the use of AI agents to discover products, build carts, and complete purchases on behalf of a user. The governance problem is no longer limited to checkout UX or payment rails; it is whether the agent can be authenticated, delegated, and constrained before it reaches the transaction.
Descope frames the stack as a protocol layer problem, but the deeper issue is identity continuity across multiple systems. Once commerce moves from human sessions to agent-mediated execution, teams must account for scoped authority, expiry windows, and proof of consent across MCP, orchestration, and payment layers.
Key questions
Q: How should security teams govern delegated identity for agentic commerce?
A: Treat the agent as its own identity subject, not as an extension of the human user. Bind every delegated action to a specific purpose, merchant context, and expiry condition, then log the proof that links the agent's activity back to the authorising user.
Q: Why do agentic commerce systems still need strong identity verification?
A: Because a cryptographically valid delegation chain does not prove that the human or business at the root is genuine. Without strong identity verification, the agent can faithfully execute actions for a synthetic or fraudulently claimed identity, which turns the protocol into a laundering mechanism for bad actors.
Q: Where do delegated purchase flows fail in practice?
A: They fail when scope, seller binding, or expiry is too broad for the task. At that point, a valid credential can be reused beyond the intended purchase, which turns bounded authorisation into open-ended commerce authority.
Q: Should teams treat MCP authentication and checkout authorisation as separate controls?
A: Yes. MCP authentication establishes the trusted agent connection, while checkout authorisation governs what that agent can spend, buy, or submit. Collapsing those controls into one step makes later payment decisions harder to prove and harder to limit.
Technical breakdown
Delegated identity in agentic commerce
Agentic commerce creates a delegated identity chain, not just a purchase flow. The agent connects through MCP or a commerce API, then carries user authority into orchestration and payment steps. That means the security question is not simply whether a payment token is valid, but whether the agent that presents it was authenticated, whether its delegation was bound to a user, and whether the authority is still in scope when the transaction executes. In practice, this is an authorization problem spanning multiple protocols and trust boundaries.
Practical implication: model the agent as a distinct identity subject and govern its delegation separately from the user and merchant session.
Shared Payment Tokens and bounded payment authority
ACP's Shared Payment Token is a scoped, time-limited credential that represents permission to charge a specific amount to a specific seller. That matters because it replaces raw card exposure with constrained payment authority, but it does not eliminate the need to trust the upstream identity event that created the token. The token is only as reliable as the authentication and delegation decisions that preceded it. This is a classic bounded-credential pattern, where the control value comes from limiting amount, recipient, and lifetime rather than making the credential broadly reusable.
Practical implication: treat token scope, seller binding, and expiry as mandatory controls, not implementation details.
Mandates and proof of user consent
AP2 uses Verifiable Credentials as mandates to prove that a human authorised a payment when the human is not physically present at checkout. That gives issuers, merchants, and payment networks a cryptographic record of consent, which is important for non-repudiation and dispute handling. It also clarifies a key distinction: the system is not asking whether an agent can act, but whether the human's intent was explicitly captured, signed, and carried forward into the payment step. This is identity evidence, not just transaction metadata.
Practical implication: require proof-of-consent artifacts wherever autonomous or semi-autonomous purchase execution is allowed.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated identity becomes the real control plane in agentic commerce: The protocols in this space are solving transaction mechanics, but they all inherit a higher-order identity problem. If the agent's identity, user binding, and authorization window are not established upstream, the payment layer only formalises an already weak trust decision. Practitioners should treat the identity layer as the gating function for all commerce protocol adoption.
Bounded authorization is the right design pattern, but it shifts risk to issuance: Shared Payment Tokens, mandates, and wallet signatures reduce raw credential exposure by narrowing what an agent can do. That does not remove risk, because the real vulnerability moves to token creation, delegation proof, and scope expiry. The control question becomes whether every issuance step is tied to an explicit subject, purpose, and seller boundary.
Agentic commerce makes MCP an identity boundary, not just a connectivity layer: The article's most important implication is that MCP sits upstream of the commerce protocols and therefore shapes who the agent is before it ever reaches checkout. That means access, consent, and authentication decisions at the MCP layer now influence downstream commerce trust. Identity teams should stop treating protocol selection as a payments exercise and start treating it as delegated access architecture.
Identity evidence will matter more than payment evidence: As agent-mediated purchase flows spread, organisations will need stronger proof that the right subject authorised the right action at the right time. The industry is moving toward cryptographic evidence of consent, but governance still depends on how that evidence is issued, stored, and verified across systems. Practitioners should expect identity assurance to become the durable control, with payment rails simply carrying the decision forward.
Identity blast radius is the new commerce risk metric: Once an agent can browse, assemble, and transact, the practical question is how far its authority can extend before the session closes or the mandate expires. That blast radius is determined by delegation scope, merchant binding, and expiry discipline, not by the brand of protocol in use. Teams should measure how much purchasing authority a compromised or mis-scoped agent could exercise in one trust window.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Authorisation Guide
What this signals
Delegated identity is now a programme design issue, not a niche commerce feature: Once agents can discover products and complete purchases, traditional session-centric governance no longer captures the full risk. Identity teams should prepare for policies that distinguish between human intent, agent execution, and payment authorisation across separate trust boundaries.
Identity teams need to govern consent evidence as part of the control stack: Proof-of-consent artifacts such as mandates become operationally important when a purchase is completed without a human present. The more autonomous the transaction path, the more the programme must rely on signed delegation, strict scope, and verifiable expiry rather than interactive approval.
Agentic commerce creates a trust-window problem: Access review cadence is less useful when an agent can acquire and use authority inside a short execution window. The practical control question shifts to issuance time, where delegation scope, merchant binding, and expiry are defined before the agent can act.
For practitioners
- Define the agent as a distinct identity subject Map agent, user, and merchant as separate subjects in your commerce architecture so delegation is explicit and auditable.
- Bind authority to amount, seller, and expiry Require every commerce credential to carry strict limits on amount, merchant scope, and lifetime before it can be used downstream.
- Treat MCP as the upstream trust gate Enforce authentication and user-to-agent delegation at the MCP layer before any commerce protocol can initiate product discovery or checkout.
- Require proof-of-consent artefacts Preserve verifiable mandates or equivalent signed consent objects so the organisation can prove who authorised the action and under what constraints.
- Review autonomous purchase thresholds Set policy for when an agent may assemble carts, initiate payment, or complete checkout without a human present, and align approval rules to those thresholds.
Key takeaways
- Agentic commerce changes the control problem from checkout security to delegated identity governance across multiple protocols.
- The protocols described in the source all reduce transaction friction, but they still depend on upstream authentication, scope binding, and expiry.
- Identity teams should focus on the trust window around agent issuance, because that is where mis-scoped authority can create the largest blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic commerce depends on delegated agent authority and scoped execution. |
| Recommendation — Apply ASI03 to bind agent actions to explicit identity, delegation, and privilege scope. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The stack depends on authenticating non-human actors before they can transact. |
| NHI-05 — Overprivileged NHI | Agentic commerce fails when delegated authority is broader than the transaction requires. | |
| Recommendation — Harden NHI authentication for agents before allowing commerce or payment access. Restrict agent privileges to the minimum commerce scope, merchant, and amount required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Scoped tokens and mandates depend on lifecycle control of authenticators and credentials. |
| Recommendation — Manage credential issuance, lifetime, and revocation under IA-5 for delegated agents. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Agentic commerce requires explicit authorization boundaries across protocol layers. |
| Recommendation — Enforce PR.AA-05 so agent entitlements stay tied to purpose, scope, and expiry. | ||
Key terms
- 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.
- Shared Payment Token: A shared payment token is a transaction-scoped credential used to complete a purchase without exposing the underlying payment secret in the user interface. In AI-mediated commerce, it must be tightly bound to one request, one context, and one authorised path, or it becomes a reusable access artifact.
- Proof Of Consent: Proof of consent is the digital evidence that a person agreed to proceed with a verification or onboarding step. In identity journeys, it helps show that the individual knowingly participated in the process, often through a recorded action or confirmation event. It supports auditability, but it does not replace document or biometric verification.
- 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.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org