Agentic commerce is commerce in which AI agents act on behalf of people or organisations: searching for products, comparing options, assembling a basket, negotiating terms and completing payment, with varying degrees of human involvement. An AI shopping agent might book a flight within a budget its user set; a procurement agent might renew software subscriptions for a company. What makes it "agentic" is that the software is not just recommending, it is acting. And once software acts, every merchant on the other side of the transaction needs to know who or what is buying, and on whose authority.
This article defines agentic commerce, outlines the industry protocols emerging to support it, sets out the trust questions merchants face, and explains how Proof of Authority and explicit intent are designed to answer them. Proof of Actor is in development; API examples below are labelled Proposed API and are illustrative only.
What is agentic commerce?
In conventional ecommerce, a person browses, selects, enters payment details and confirms. Every step is performed by the account holder, or at least assumed to be.
In agentic commerce, some or all of those steps are delegated:
- Discovery. The agent searches catalogues, reads reviews and compares prices across merchants.
- Selection. The agent assembles a cart that meets the user's constraints: price, dates, brand, delivery window.
- Checkout. The agent submits the order and payment, either after the user confirms or within a pre-agreed mandate.
- After-sale. The agent may track delivery, handle returns or renew subscriptions.
The spectrum runs from human-present flows, where the agent prepares a purchase and the user approves it in the moment, to delegated flows, where the user sets rules in advance ("buy concert tickets if two seats together are available under $200") and the agent acts later without further confirmation.
Both ends of that spectrum are legitimate. Neither is the same as a human clicking "buy".
The protocols building the rails
The payments and AI industries have begun publishing open protocols for agent-initiated transactions. A brief, neutral overview:
- Agentic Commerce Protocol (ACP). An open standard co-developed by Stripe and OpenAI and announced in September 2025, alongside Instant Checkout in ChatGPT. It defines how buyers, AI agents and businesses complete purchases programmatically, with the merchant remaining the merchant of record. Stripe describes a Shared Payment Token that lets an agent application initiate payment without exposing the buyer's credentials, scoped to a specific merchant and amount. Stripe has said businesses can adopt ACP with other payment providers too.
- Agent Payments Protocol (AP2). An open protocol announced by Google in September 2025 for agent-led payments, designed to work alongside agent interoperability protocols such as A2A and MCP. AP2 introduces cryptographically signed mandates: an Intent Mandate capturing what the user asked for and its constraints, and a Cart Mandate capturing the specific items and price the user approved, together creating an auditable chain from request to payment. Payment networks and other industry participants were named among its initial collaborators.
- Card-network agent programmes. Visa (Visa Intelligent Commerce) and Mastercard (Mastercard Agent Pay) have each announced programmes to issue agent-specific, tokenised credentials, so that payments initiated by AI agents can be recognised and governed within card-network infrastructure.
These efforts address important problems: how an agent checks out, how payment credentials are protected, how a user's instructions are captured and how the payment system recognises agent-initiated transactions. They are building the transaction rails, and that work is essential.
The trust questions a merchant still faces
Rails move transactions. A merchant deciding whether to accept a specific order from a specific agent still faces a set of actor questions. These questions apply whatever protocol carries the transaction.
Which agent is this?
Agents are software, and software can be copied, modified or impersonated. A merchant needs a stable agent identity it can recognise and attribute behaviour to over time, distinct from the identity of the human or company it represents.
Which principal stands behind it?
An agent acting on behalf of "someone" is not enough. The merchant needs a verifiable link from the agent to an accountable principal: an individual, an organisation or another authorised service. Without a principal, nobody stands behind the order.
Is this purchase inside the mandate?
Authority is not all-or-nothing. A user who authorised an agent to buy groceries did not authorise it to buy a television. A company that authorised software purchases did not authorise its agent to sign a master services agreement. The merchant needs to know whether this specific order, at this amount, from this vendor, is inside what the principal granted.
Did a human approve this specific action?
For some purchases, standing authority is sufficient. For others (high value, unusual, irreversible) a merchant, issuer or regulator may want evidence that a person approved this action, at this time, under these conditions. That is a stronger claim than "the agent was authorised in general".
Who is accountable?
When something goes wrong, someone must be answerable. An agent transaction should make it possible to identify who ultimately stands behind it, which matters for disputes, chargebacks, fraud investigation and customer service.
Has the authority been revoked?
Delegation must be withdrawable. A user who cancels an agent's permissions on Monday should not discover on Tuesday that a merchant accepted an order based on a cached mandate. Revocation status must be current at the moment of the transaction.
How Proof of Authority is designed to answer them
Proof of Authority is the Proof of Actor primitive for agents. It is designed to establish, for a requested action:
| Merchant question | What Proof of Authority is designed to establish |
|---|---|
| Which agent? | A verified agent identity |
| Which principal? | A signed binding between agent and an individual or organisation |
| Inside the mandate? | The action checked against scope, limits, permitted counterparties and expiry |
| Human approval? | Explicit intent for this action, where the mandate or merchant requires it |
| Accountable party? | The principal who ultimately stands behind the action |
| Revoked? | Current mandate status at the time of the action |
The scope element is where most of the practical value sits. Here is how a procurement mandate might be expressed:
Agent: Procurement Agent #4812
Principal: Acme Corporation
Authority: Purchase SaaS subscriptions
Maximum transaction: $5,000
Allowed vendors: Approved vendor list
Legal agreements: Not authorised
Authority expires: 31 December 2026
A SaaS vendor on Acme's approved list receiving a $1,800 annual subscription order from this agent can see that the order sits inside the mandate. The same vendor receiving a request to accept custom contract terms can see that legal agreements are explicitly outside it, and can route that request to a human at Acme instead. A vendor not on the list can see that the agent is not authorised to buy from it at all. None of these outcomes requires the vendor to know anything about Acme beyond what the mandate discloses.
Checking a requested action
The interface we are designing for this check is simple. Proposed API, illustrative only. This describes the Developer Preview design direction, not an available service.
POST /v1/authority/verify
{
"agent_id": "agt_48291",
"requested_action": {
"type": "purchase",
"amount": 420,
"currency": "USD"
}
}
Conceptual response:
{
"agent": "verified",
"principal": "verified",
"mandate": "valid",
"action_authorised": true,
"maximum_amount": 500
}
The response does not tell the merchant who the principal's family members are, where they live or what else the agent has bought. It answers the question the merchant asked: is this agent, acting for a verified principal under a valid mandate, authorised to make this $420 purchase? Following the principle prove what matters without revealing what doesn't, a merchant needs to know the agent is authorised to spend up to $500; it does not need the principal's home address.
Requesting explicit intent
Where a mandate does not cover an action, or a merchant's own policy requires direct confirmation, the proposed flow includes a separate intent step:
POST /v1/intent
This is used for consequential actions that require a human to approve this specific action. The result becomes a distinct claim in the attestation, so the merchant can see not only that the agent was authorised, but that a person confirmed this particular purchase.
The receipt
The outcome of an agent transaction can be recorded as an Actor Trust Receipt:
ACTOR TRUST RECEIPT
Actor AI Agent
Agent identity Verified
Principal Verified organisation
Authority Verified
Requested action Inside delegated scope
Human approval Not required by mandate
Mandate status Valid
Receipts give merchants, principals and dispute handlers a shared, reviewable record of the basis on which an order was accepted. The format is described further on the Actor Attestations page.
Complementary, not competing
It is worth being precise about where a trust layer fits, because agentic commerce does not need yet another checkout protocol.
| Layer | Primary concern | Examples |
|---|---|---|
| Checkout and commerce protocols | How an agent and merchant exchange carts, orders and payment instructions | Agentic Commerce Protocol, AP2 |
| Payment credentials | How payment instruments are tokenised and governed for agent use | Card-network agent programmes, payment tokens |
| Actor trust | Who or what is acting, for whom, with what authority, and who is accountable | Proof of Authority, Actor Attestations |
Several of these protocols already capture user instructions and approvals in their own structures; AP2's mandates are an example. An actor trust layer is designed to complement such structures by providing portable, protocol-independent evidence about the agent, its principal and the scope of its authority, and by giving relying parties a consistent way to apply their own policy across whichever rails a transaction travels on.
The guiding principle is the same as everywhere in the Actor model: Proof of Actor supplies evidence; the merchant decides policy. One merchant may accept any authorised agent within mandate. Another may require explicit intent above a threshold. A third may welcome agents for repeat orders and require a human for first purchases. More on these patterns is on the agentic commerce use case page.
Beyond retail checkout
Agentic commerce is not only consumers buying shoes. The same actor questions appear in:
- B2B procurement, where agents renew subscriptions and order supplies under corporate policy;
- Travel, where agents book and change itineraries within fare rules and budgets;
- Financial services, where agents may move money, pay bills or rebalance accounts, and where explicit intent for consequential actions matters most;
- Marketplaces, where buyers and sellers may both be represented by agents and the platform needs to distinguish humans, AI-assisted humans and authorised agents.
In each case the underlying question is the one the Actor model is built around: who or what is acting, who authorised it, and who is accountable? The broader argument for agent authority is in The Missing Trust Layer for AI Agents, and the question of what agent verification must establish is covered in What Does "Know Your Agent" Actually Need to Prove?.
Frequently asked questions
What is agentic commerce in simple terms?
Agentic commerce is shopping and purchasing carried out by AI agents on behalf of people or businesses. The agent can find products, build a cart and complete payment, either with the user confirming each purchase or within rules the user set in advance.
What is the agentic commerce protocol?
The Agentic Commerce Protocol (ACP) is an open standard co-developed by Stripe and OpenAI, announced in September 2025, that defines how AI agents, buyers and businesses complete purchases programmatically while the business remains the merchant of record. "Agentic commerce protocol" is also used more generally for any protocol supporting agent-led transactions.
What is the Agent Payments Protocol (AP2)?
AP2 is an open protocol announced by Google in September 2025 for payments initiated by AI agents. It uses cryptographically signed mandates to record what a user asked for and what they approved, creating an auditable trail from intent to cart to payment.
How do merchants know an AI shopping agent is authorised?
A merchant needs evidence of the agent's identity, a verifiable link to its principal, the scope and limits of its mandate, current revocation status and, for consequential purchases, explicit human approval. Proof of Authority is designed to provide this evidence so the merchant can apply its own acceptance policy.
Does Proof of Actor process payments?
No. Proof of Actor is designed as a trust layer that attests to the actor behind a transaction. It is intended to complement payment and commerce protocols, not to move money or replace checkout infrastructure.
Build agent trust with us
Agentic commerce will work best when merchants can accept agent orders with the same confidence they place in a well-authenticated human checkout, and when principals can trust that their agents stay within the limits they set. We are building the authority layer for that, and we are looking for merchants, payment teams and agent builders who want to shape it. You can join the Developer Preview or become a design partner, or read more on the Developers page.
