Agentic traffic on e-commerce sites is surging, driven by a new wave of personal AI agents that browse proactively and shop on the user’s behalf. Meta’s Muse is one of the latest to join in. Amazon moved quickly to block it, while Shopify went the other way, announcing official integrations that bring millions of its merchants into the agentic shopping ecosystem.
But what does this integration actually look like? What has to come together for agentic shopping to be efficient, reliable, and fully autonomous, while still being traceable and keeping the humans behind the agents accountable? A flurry of protocols is being developed to answer that, covering everything from a unified cart interface to payment authorization to the payment rail itself. As in any emerging category, competing standards will multiply before they converge, and legislation is usually what forces the issue.
In this article, we describe the essential puzzle pieces, what they provide, and how KYA-OS's new Payments Profile bridges the identity gap and completes them for a fully accountable agentic commerce stack.
What is the Personal Agent Protocol (PAP)?
Meta's Muse launched with a built-in visual browser and a secure credential store, which allowed it to browse with the user's credentials, including their passwords. For the many platforms that did not support it through an official OAuth connector, the agent could simply handle the user's credentials and impersonate them, and the platform would believe an actual human was on the other side. Sites that distrusted or blocked bots couldn’t tell agent traffic from human traffic, so they had to block both the legitimate and the malicious, with no way to tell them apart.
In an attempt to standardize agentic browsing practices, Meta, working with Sierra, recently announced the Personal Agent Protocol (dubbed "Poppy" for short). It allows websites to advertise support for agents through an endpoint, ./well-known/poppy.json, and allows agents to authorize and take actions on behalf of users with OAuth, acting transparently instead of covertly. It is agnostic to the actual interface itself, supporting everything from OpenAPI and MCP to plain web browsing as a means of navigation.
PAP is not a commerce-specific protocol, and is meant to solve the dilemma of sites giving access to agents on behalf of users without forcing them to rely on impersonation.
What it doesn't provide: a shopping interface, payments, identity, cross-organization or agent-to-agent delegation.
What is x402?
x402 introduces a payment rail that allows agents to make payments to websites using stablecoins on-chain. By reviving the previously inactive HTTP 402 Payment Required status code, x402 provides a direct way to make micropayments to websites without requiring a human in the loop.
What it doesn't provide: authorization, identity (which party made the payment?), shopping flows
What is UCP?
Normally, every e-commerce website has its own shopping interface on its website for navigating collections, products, variants and adding them to cart. While agents like Muse will happily spin up a web browser and click through pages to do your shopping, browsing this way can be inefficient if the agent knows what it's looking for. The Universal Commerce Protocol allows it to talk through a standardized interface with the server, and offers methods for product discovery and managing a cart.
What it doesn't provide: payments, authorization, checkout flows, identity (who is shopping?)
What is AP2?
Agent Payment Protocol is a payment authorization protocol created by Google that makes sure that agents making payments hold valid authority to do so. A guiding principle is to require clear, verifiable intent from the user to prevent AI hallucinations from driving online transactions. AP2 uses digitally signed, portable, and revocable statements called mandates, which describe what spending authorization is being given to the agent.
What it doesn't provide: payment rail, shopping flows, identity, agent-to-agent delegation and cross-organizational delegation.
Are these alternatives, or are they meant to be used together?
The protocols above are intentionally scoped to address problems in their domain, without extending too far. PAP provides interfaces for agents to transparently use platforms with user authorization, without impersonating them.
-
If all you want is the ability to make micropayments to websites, x402 closes that gap without any fuss about identity or authorization.
-
UCP tries to unify shopping interfaces on the web by providing a common language for agents to browse products and assemble a cart, leaving checkout details to individual merchants.
-
And AP2 provides evidence that a payment was authorized by a user, without addressing the agent’s environment or organization.
Used together, these standards let agents efficiently browse products on a platform, check out, prove they have payment authorization and verifiable intent, and use rails that don’t require a human in the loop, which is impressive!
The protocols above are sufficient for use cases such as:
- A person buying something directly.
- An agent operating entirely inside one provider’s controlled wallet ecosystem.
- A vertically integrated platform that builds its own delegation, policy, and audit controls.
What is missing?
As you may have noticed, one aspect is missing from all the protocols above - and it is essential for payments with accountable parties and reliable cross-organization commerce: identity.
Without it, we aren't able to unlock more involved use cases where:
- The agent and the merchant belong to different organizations: how does the merchant verify that the agent is actually acting on behalf of a particular organization?
- Authority passes through multiple agents: how can we preserve the payment authority delegation through multiple hops, making sure each hop has narrower capabilities than the last, while keeping the root party responsible?
- An organization wants to issue credentials with finer revocation controls: AP2 does not have a revocation infrastructure and thus suggests making the mandates short-lived for security. This is not ideal for autonomous agents that need to possess payment authority over longer periods of time.
What is KYA-OS Payments Profile, and how does it help?
KYA-OS is a standard under the Decentralized Identity Foundation that provides Know-Your-Agent (KYA) capabilities based on open technologies like W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). This provides open infrastructure for interoperable identity across multiple providers and reputation backed by open registries.
We're excited to share that we have been working on a Payments Profile that brings the identity and delegation capabilities of KYA-OS to enrich and secure agent payments on the web. This enables easy cross-organization and multi-hop payments, while carrying cryptographic bindings along all hops.
The protocol is based on KYA-OS's Delegation Credentials, which are VCs that hold cryptographically signed information about what permissions are delegated to an agent from a responsible party. We extend them to hold payment constraints, which in turn lets us use them as authorization evidence for e-commerce. The main pieces that let us do this are:
PaymentIntent: A Payment Intent describes the exact payment the agent is trying to make. It includes information such as the accountable payer, intended payee, amount and currency, expiration, etc. This is turned into a cryptographic fingerprint called the intentDigest.
PaymentAuthorization: This is a deterministic record of what the verifier established. It records facts such as the acting agent, the accountable responsible party, the complete delegation chain, and any verified approval evidence.
PaymentOutcome: After execution, the Executor produces a normalized PaymentOutcome. The outcome records whether the attempt is one of the following: Authorized, Submitted, Settlement Pending, Settled, or Failed.
With the Payments Profile, we can support cross-organizational agent payments, such as an organization's manager delegating spending authorization to a travel agent, who in turn uses an AI to find and complete a booking:
In some respects, it meaningfully overlaps with protocols like AP2. Delegation credentials with payment constraints resemble open mandates, and both feature cryptographic signatures to bind authorized spending amounts.
What does it look like in code?
While there are many moving pieces to enable the protocol to come together and function, the surface for implementers is simple, and our current reference implementation requires adding only a few lines of code for both the agent and the merchant.
Here is what the merchant implements:
And here is what the agent implements:
The code above succinctly generates the payment intent, bundles it with information about identity, delegation chains, and the payment rail, and enables the merchant to verify the intent. The payment authorization is generated, and the outcome is checked during settlement.
Proof of Control
The protocols we’ve described so far either unlock new capabilities for agents to browse and shop (UCP and x402), or let them do so with proper identity and authorization (PAP, AP2 and KYA-OS).
But what does the complete picture for a reliable and trustworthy agentic commerce ecosystem look like? Are there gaps we might have missed that prevent us from trusting an organization’s agents with payment authorization? What do merchants, payment processors, agent platforms and organizations need to integrate before they can start taking full advantage of agents in business operations?
Proof-Of-Control is an open standard that describes the verifiability gap in AI and measures for closing it. This is relevant for security leaders trying to bound the actions of agents in their org, regulators trying to curb the high risk of free-running agents, and insurers trying to underwrite agentic systems. It aims to answer two questions: “Can I deploy this agent and still account for what it does? How do I know the controls held?” It does this by outlining tiers of open verification that use cryptographic evidence of agent operations to ensure that the system is transparent and auditable.
KYA-OS provides evidence of delegation and identity of the parties involved, which is crucial to audit logging in systems that interact with agents outside their environment. Runtime security, though, is not addressed by the commerce stack described here. A merchant or agent platform adopting this stack would state the measures adopted in a Proof-of-Control Self-Declared Conformance Statement to meet the transparency requirements.
What's next?
We plan to release spec details, a reference implementation and more in the coming weeks! There is also exciting work to be done on developing the protocol further to enable use cases such as delegations with budgets that can keep a running balance across payments in an interoperable way, similar to AP2's budget and recurrences features that are outlined but left to implementations.
Want to learn more? Join us and our peers at Decentralized Identity Foundation to contribute your ideas to the KYA-OS Payment Profile and spec.