Agentic Commerce 101: The Infrastructure Stack Behind AI Agents That Pay

TL;DR

• Identity and authorization link an agent to a human or organization and confirm its authority to act.

• Protocols and rails move value. AP2 uses signed mandates, while x402 embeds stablecoin payment requests in HTTP exchanges.

• Spend controls encode budgets, approved counterparties, payment methods, and session limits.

• Verification and compliance tools detect bots, fraud, and restricted transactions, often during or after execution.

• Current infrastructure rarely proves that an agent followed its mandate without revealing sensitive transaction data.

Pre-execution enforcement can block noncompliant actions, while zero-knowledge receipts can provide independent proof without exposing private details.

Why agentic commerce needs its own stack

Agentic commerce separates authorization from the purchase itself. A person may approve a broad instruction such as booking a hotel under $300, while an agent chooses the property, timing, and payment method later. Payment systems built around a person reviewing one checkout page cannot represent those delegated choices on their own.

Authenticity becomes harder when software initiates the request. A merchant needs to identify the agent, connect it to a real user or organization, and verify that its credentials remain valid. Standard account logins and payment tokens may authenticate an account without proving that the agent may make the specific purchase.

Accountability requires evidence that the agent stayed within its mandate. A successful authorization proves that a payment credential worked, while an audit log records what the agent attempted. Neither record necessarily proves that the purchase satisfied private limits on amount, merchant, timing, or purpose.

The market has responded with a fragmented infrastructure stack. By early 2026, more than 50 companies were building across seven layers, and roughly $50 million in disclosed Series A and B funding had concentrated in payments and identity alone. Identity services, payment protocols, card issuers, checkout tools, and security vendors each address part of the transaction. You still need to determine where one layer’s assurance ends and another layer must begin.

What to look for in each layer

Problem solved. Identify the specific failure each layer prevents. Identity confirms who authorized an agent, while payment rails move value and mandates constrain spending.

Named participants. Check which protocols and vendors provide the capability. AP2 and x402 handle different payment models, while Skyfire, Visa TAP, Lithic, and Stripe Issuing cover adjacent identity or payment functions.

Coverage boundary. Determine where each provider’s responsibility ends. A signed identity can authenticate an agent without proving that its purchase complied with the user’s instructions.

Enforcement point. Ask whether a layer blocks prohibited activity before execution or flags it after settlement. Most identity, payment, and fraud systems stop at authorization, settlement, or retrospective monitoring.

Evidence produced. Examine whether another party can independently verify mandate compliance without receiving private transaction data. Most current layers do not produce that evidence, which leaves a verification gap above the payment rail.

Layer 1: Identity and authorization

Identity and authorization establish which agent sent a payment request and whose authority it claims. An identity provider verifies the user or organization behind the agent, then issues a credential that the agent can present during checkout. The merchant or payment provider checks that credential before accepting a payment instruction.

Visa Trusted Agent Protocol uses signed HTTP request headers for this check. An agent signs identifying information into each request, and the merchant verifies it against Visa’s directory. Participating merchants can distinguish a registered commerce agent from an ordinary bot or an unsigned automated request. Visa TAP addresses authenticity at the network boundary, but the signature alone does not prove that the user approved a specific purchase.

Several startups cover adjacent parts of the identity chain. Nekuda provides agent identity and KYC services, while Prava offers identity and KYC primitives. Skyfire connects agent payment methods across cards, bank transfers, and stablecoins, which lets a verified agent present a usable payment method through one interface. These companies sit within a payments and identity category that also includes token vaults and credential providers, according to a 2026 agentic commerce stack analysis.

Authorization requires a separate, scoped instruction from the user or organization. A valid instruction may limit the agent to a merchant, purchase category, amount, or time window. Identity systems can verify who registered the agent and whether its credential remains valid, but they generally do not prove that a completed transaction stayed within those limits. Later layers must encode the limits and enforce them at payment time.

Layer 2: Payment rails and protocols — AP2 and x402

Payment protocols turn an agent’s authority into a transfer of value. AP2 applies signed mandates to established payment methods, while x402 embeds stablecoin payment requests into ordinary web traffic.

AP2 secures agent transactions across the existing payments ecosystem. Its initial release supports pull payments through credit and debit cards. The roadmap includes real-time bank transfers, wallets, and digital currencies. AP2 coordinates the parties around a payment rather than replacing issuers, networks, or payment processors.

AP2 represents authority through tamper-evident, signed mandates. For an autonomous purchase, a user approves an open mandate that defines constraints such as budget, payment instrument, and purchasing scope. The agent later signs a closed mandate for a finalized purchase within those constraints. A closed Checkout Mandate records the agreed items and terms, while a closed Payment Mandate authorizes a specific amount and binds that authorization to the checkout.

AP2’s signed receipts connect each decision into an accountable transaction record. The Shopping Agent stores the open mandate, closed mandate, and receipt tuple. It then reduces the authority remaining under the open mandate and must prevent overlapping presentations that could reuse the same spending authority. The Credential Provider evaluates the payment mandate and shares relevant authorization evidence with payment participants. Under compliant conditions, each verifier receives enough context to check deterministic constraints and reconstruct its part of the transaction.

x402 takes a crypto-native approach by reviving the HTTP 402 Payment Required response. A server returns structured payment requirements when an agent requests a paid resource. The agent signs a stablecoin payment authorization, and the server releases the resource after verifying payment.

A facilitator handles the blockchain work so the server does not need its own chain infrastructure. The facilitator validates the signature, submits or verifies settlement, and returns confirmation. The common path uses EIP-3009, which lets a facilitator execute a gasless transfer authorized by the payer. Native compatibility remains limited because USDC on Base supports this authorization model, while USDT does not. Solana implementations use a different mechanism.

Discovery and checkout protocols sit beside these payment mechanisms. UCP covers product discovery, checkout, and post-purchase handoff, while ACP uses merchant-scoped, amount-bounded payment credentials during checkout. AP2 can secure the resulting authorization, and x402 can settle supported flows in stablecoins.

Layer 3: Spend limits and mandate definition

An organization can encode an agent’s authority as a signed mandate that payment participants can inspect and enforce. AP2 represents mandates as tamper-evident digital credentials. An Open Mandate records constraints before the agent finalizes a purchase, such as a maximum budget, permitted payment instruments, or acceptable merchants.

A Closed Mandate binds that authority to a specific checkout and payment. The Checkout Mandate records the agreed purchase details, while the Payment Mandate authorizes a specific amount against a selected instrument. Chaining those objects connects the user’s original limits with the transaction the agent submits.

Card controls provide another enforcement point for purchases that use existing card rails. Lithic, Stripe Issuing, and Marqeta can issue chargeable credentials with spending rules and merchant restrictions. You can give an agent a credential for one session, cap its total spend, and restrict where the issuer will approve charges. The issuer can then decline an authorization that exceeds the controls it can observe.

Mandates and card controls cover different parts of the same policy. AP2 can express purchase intent and connect it to payment authorization. Issuer controls can enforce payment-level restrictions during authorization. Neither mechanism independently proves that every relevant rule was evaluated correctly, especially when a mandate includes private context or constraints outside the issuer’s view. The verification layer must supply that evidence without exposing the transaction data itself.

Layer 4: Verification and compliance

Today’s verification layer focuses on traffic authenticity and transaction fraud. Vendors such as HUMAN Security, DataDome, and Kasada distinguish agents from malicious bots or scrapers, while Riskified, Forter, and Signifyd assess fraud signals. Cloudflare and Akamai apply similar controls at the network edge. These tools can block suspicious requests, but the current trust and security category does not evaluate whether an agent followed its mandate.

Identity governance establishes who deployed an agent and who approved its access. Runtime authorization asks whether a specific purchase complies with the agent’s budget, counterparty restrictions, and current operating context. A practitioner analysis reports that only 28% of enterprises can trace agent actions to a human sponsor, which suggests that most organizations lack even basic attribution across autonomous actions.

Audit logs and fraud alerts usually document events after execution. They may identify the approving user, the acting agent, and the settled payment, but they do not establish that every mandate condition held when the agent acted. Existing controls also lack a privacy-preserving way for an auditor or relying party to verify compliance without receiving the underlying transaction details. The missing capability is an independently verifiable receipt that proves a transaction honored its mandate while keeping sensitive inputs private.

The missing layer: proving mandate compliance without exposing the transaction

Agentic commerce needs policy enforcement inside the transaction path. Monitoring tools can flag a mandate violation after settlement, but they cannot prevent an irreversible payment. Pre-execution enforcement evaluates each proposed action before value moves. A zero-knowledge receipt can then prove that the action satisfied its mandate without revealing private amounts, limits, or transaction details.

AP2 already provides meaningful controls when every verifier receives sufficient context and understands each constraint. Ordinary receipt trust runs out when evidence or policy logic spans multiple parties. First, two providers might each approve $300 against the same $500 cumulative budget because neither sees the other approval. Second, an AP2 verifier correctly fails closed when it encounters an unknown constraint type, but every relevant verifier must implement new policy schemas before agents can use them. Third, a downstream issuer or auditor may verify who signed a receipt but remain unable to replay the private evaluation or assess how the signer reached its decision.

Inherence proposes a Mandate Assurance Layer to address those conditions. Its working pilot architecture carries a Compliance Proof Envelope alongside the signed AP2 receipt. A policy commitment identifies the approved policy without publishing it. A certified evaluator checks the transaction and creates a privacy-preserving proof. A downstream verifier uses a versioned verification manifest to confirm that the expected evaluator accepted the committed transaction under the expected policy and inputs.

The proposed envelope gives downstream parties one stable verification operation even as policies and verification components change. Trust still resides in the policy compiler, evaluator, certification process, and manifest governance. The architecture narrows and exposes that trust surface rather than claiming to eliminate it.

A valid proof establishes that a supplied state transition followed the committed policy. It does not establish that the supplied predecessor was the uniquely current state. Two providers could receive the same valid budget state and independently approve conflicting successors. Inherence’s whitepaper treats ordering and uniqueness as a separate design choice through five state-authority profiles. The profiles place authority with portable proofs, a protected agent sequencer, an atomic state relay, a payment provider’s ledger, or a federated registry. Each profile makes different assumptions about availability, coordination, privacy, and governance.

Comparison: what each layer covers and what it misses

Each layer answers a different transaction question. Only the mandate-proof layer combines private verification with enforcement before execution.

Layer	What it solves	Key players	Proves mandate compliance without exposing data
Identity and authorization	Connects an agent to a user and validates delegated authority	Visa TAP, Skyfire, Nekuda, Prava	❌ Identity does not prove compliant execution
Payment rails	Carries authorization and settles payment	AP2, x402	🟡 AP2 provides signed mandates, but neither rail proves a private policy decision
Spend limits and mandates	Defines budgets, instruments, merchants, and session restrictions	Lithic, Stripe Issuing, Marqeta	❌ Rules constrain credentials but do not produce private compliance proof
Verification and compliance	Detects bots, fraud, and suspicious traffic	HUMAN Security, Riskified, Forter, Cloudflare	❌ Monitoring does not prove mandate adherence
Mandate-proof layer	Blocks off-mandate actions and produces independently verifiable zero-knowledge receipts	Inherence	✅ Proves covered actions satisfied policy without revealing private inputs

Which layer to prioritize first

Engineers should start with the payment rail. Compare AP2’s mandate-based approach for established payment methods with x402’s stablecoin-native settlement model. Your choice depends on settlement speed, supported networks and stablecoins, wallet infrastructure, and merchant compatibility.

Product leads should start with identity, authorization, and mandate design. Define who controls the agent, what the agent may buy, which counterparties it may use, and how much it may spend before selecting supporting vendors.

Compliance teams should prioritize mandate verification regardless of the rail. Identity checks and signed authorizations establish who approved an action, but they do not prove that each transaction followed every constraint. Pre-execution enforcement can block violations before settlement, while privacy-preserving receipts can let counterparties verify compliance without seeing confidential transaction data.

The case for closing the verification gap now

As agent transaction volume grows, organizations will grant autonomy only when they can verify that each action followed its mandate. Human approvals and periodic audits cannot govern software that initiates payments continuously across counterparties and payment rails.

Pre-execution enforcement gives organizations stronger control than post-settlement monitoring. Inherence blocks actions that violate defined policies before value moves, then produces independently verifiable receipts for permitted actions. Counterparties can verify mandate compliance without receiving private amounts, limits, or strategy data.

Organizations building agent payment flows should evaluate verification alongside identity, authorization, and settlement. Evaluate Inherence as the policy-enforcement layer for autonomous payments.

FAQs

• How do AP2 and x402 differ in practice? AP2 uses signed mandates to connect user intent, checkout details, and payment authorization across payment methods. Inherence adds pre-execution policy checks without replacing AP2 or x402. x402 lets a server request stablecoin payment through HTTP and verify it through a facilitator.

• Does an agent need both AP2 and x402? An agent needs both only when an AP2 authorization flow uses x402 for settlement. Inherence can verify mandate compliance regardless of the selected payment rail. You can adopt AP2 with cards or use x402 without implementing the full AP2 model.

• What does a mandate legally mean today? A mandate records the authority and constraints a user gives an agent. Inherence can enforce those encoded constraints, but it does not determine their legal effect. Contracts, payment rules, and applicable law still decide whether a mandate creates valid consent or assigns liability.

• Why are audit logs insufficient proof of compliance? Audit logs record what a system reports after an action occurs. Inherence checks policy before execution and can produce a privacy-preserving cryptographic receipt. An independent verifier can then confirm compliance without trusting the agent’s log or viewing private transaction data.