When you swipe a credit card at a coffee shop, the payment network verifies two identities rather than one. Your card identifies you. The merchant's terminal identifies the coffee shop: a merchant ID, a merchant category code, a registered legal entity, a jurisdiction where disputes get resolved, a network agreement years old and fingerprinted to that specific business. The transaction completes because both parties have identity that the network recognizes. When something goes wrong, the network knows who it is talking to on both ends.
Card networks spent decades building this. They had to. A payment system where one side is identified and the other side is whatever showed up at the endpoint produces fraud at scale, and the fraud is hard to investigate because half the transaction is anonymous.
Now consider what happens today when an AI agent makes a purchase on someone's behalf. The agent has identity. Agent-ID, Owner-ID, Authority-Scope, signed Genesis, all carried on every request. The merchant has whatever was at the URL. No protocol-level identity. No structural verification that the merchant is who it claims to be, that the merchant is current with its registration, that the merchant has a dispute policy, that the merchant is in good standing in its jurisdiction.
Half the transaction has identity. The other half is whoever answered the connection.
This is the gap AGTP's merchant identity layer closes. It does for the receiving side of an agent purchase what Agent Genesis does for the initiating side. And it pairs with two operational primitives, Budget-Limit and Intent-Assertion, that together make agent-driven commerce something that compliance teams, payment networks, and merchants themselves can actually rely on.
What "merchant identity" means in AGTP
A merchant in AGTP is a legal entity, registered through a governance platform, identified by a canonical Merchant-ID derived from a signed Merchant Genesis document.
The Merchant Genesis carries the fields a payment network and a regulator would expect to see: legal entity name, organization domain, merchant category code following ISO 18245, registered jurisdiction, accepted payment networks, dispute policy URI, refund policy URI, trust tier, governance zone, and the verification path that backed the merchant's registration. The Genesis is signed at issuance, hashed to produce the Merchant-ID, and permanently bound to the merchant.
The structural parallel with Agent Genesis is deliberate. A governance platform that registers agents registers merchants through the same registry and the same cryptographic machinery. The Merchant Manifest Document, derived from the Genesis, is the merchant-side analogue of the Agent Manifest Document. Both carry signed identity claims. Both carry trust tier. Both carry governance zone. Both can be resolved through discovery and verified at the moment of use.
A merchant's canonical URI looks like agtp://acme.tld/merchant/acme-commerce. The domain anchors the merchant to a registered organization. The labeled suffix lets a single organization run multiple merchant identities, which matters for multi-brand retailers and conglomerates. Every URI form resolves back to the same canonical Merchant-ID.
This is the substrate that has been missing from agent commerce. A merchant is more than the endpoint that answers a PURCHASE call. The merchant is the legal entity that stands behind the transaction, with verifiable identity, declared policies, and a registration record that can be audited.
Verification at PURCHASE
The PURCHASE method invokes the merchant identity machinery. An agent holding payments:purchase in its Authority-Scope MUST perform counterparty verification before sending the request.
Verification is five steps. Resolve the merchant URI. Verify the manifest's signature against the governance platform's published key. Verify the merchant's lifecycle state is Active. Verify the merchant's trust tier meets the threshold the agent's policy requires for the transaction amount. Compute the SHA-256 hash of the canonical manifest bytes and carry that fingerprint in the Merchant-Manifest-Fingerprint request header.
Any step failing means the PURCHASE never sends. The agent's runtime surfaces the failure to the principal or the governance platform. There is no silent fallback to an unverified transaction.
The receiving merchant server has its own verification responsibility. It checks that the Merchant-ID header in the inbound request matches its canonical ID. It checks that the manifest fingerprint matches its current Merchant Manifest. Any mismatch returns 458 Counterparty Unverified. The fingerprint check is the part worth dwelling on: an attacker who redirects the requesting agent to a different endpoint than the one it verified gets caught at the fingerprint comparison. The manifest the agent verified has to be the manifest the server actually presents. The two are bound by hash.
This is the protocol-level mechanism that closes the spoofed-merchant attack. The agent never has to trust DNS, never has to trust hosting infrastructure, never has to trust that the URL it resolved still points where it pointed five seconds ago. The fingerprint check is the cryptographic guarantee that the entity answering is the entity that was verified.
Budget-Limit, enforced at the wire
The other half of trustworthy agent commerce is operational containment. An agent that has been authorized to make purchases up to a ceiling must actually stop at the ceiling, including when the application logic above it has a bug.
AGTP carries this as a header. Budget-Limit: USD=850.00. The format is currency code, equals sign, decimal amount. The header travels with the PURCHASE request. The merchant server is required to enforce it. A cart total that exceeds the declared budget gets rejected before the transaction completes. Scope Enforcement Points in the path can enforce it at line rate, before the request ever reaches the merchant's application.
The relationship to Authority-Scope is worth being explicit about. Authority-Scope describes the agent's overall commerce authority: payments:purchase, payments:up-to-2500usd. This is what the agent is broadly permitted to do, across all transactions in its session. Budget-Limit describes the cap on a specific transaction: this PURCHASE has $850 to spend. Authority-Scope is the credit limit on the card. Budget-Limit is the size of the dinner you authorized tonight.
Both are enforced at the protocol layer. An agent whose Authority-Scope allows up to $2,500 cannot use that allowance to make a single $5,000 purchase. A specific PURCHASE with Budget-Limit set to $850 cannot complete at $850.01. Application bugs above the protocol layer cannot cause over-budget transactions, because the protocol catches them first.
This is the operational guardrail compliance teams have been asking for and that application-layer enforcement keeps failing to deliver. Wire-level budget enforcement means the bug in the application loop, the prompt-injection in the user's instructions, and the unexpected price surge at the merchant all hit the same wall: the protocol refuses to complete the transaction.
Intent-Assertion: portable evidence
There is a problem AGTP has to solve that pure protocol identity cannot solve alone. Payment networks already exist. Visa, Mastercard, ACH, PIX, FedNow, every regional rail. These networks are decades old, they handle trillions of dollars a year, and they are never going to ingest AGTP traffic directly. An agent making a card-network purchase has to produce evidence the card network can consume.
The Intent-Assertion header is that bridge. It carries a detached signed JWT containing the principal's authorization for this specific purchase: the principal's identity, the cart digest, the budget cap, the intent timestamp, the merchant the purchase is targeted at. The JWT is signed by the principal's key (or by the governance platform on the principal's behalf, depending on the deployment pattern), and it is portable. Card networks can consume it. PSPs can consume it. Acquirers can consume it. None of them needs to speak AGTP. They just need to recognize the JWT signature against the principal's published key.
This is the same pattern notarized documents follow in the physical world. A notarized signature is portable evidence of authorization that any institution accepting notarization can consume. The notary has no requirement to be inside every institution's workflow. The signature stands on its own.
The Intent-Assertion lets agent-initiated transactions ride existing payment rails with verifiable evidence of authorization on both sides. The card network gets the proof it needs (the agent was authorized by this principal, for this amount, with this merchant, at this time) without having to integrate with AGTP infrastructure.
MNS: the Merchant Name Service
Discovery on the merchant side mirrors discovery on the agent side. The Merchant Name Service is the merchant analogue of ANS. An AGTP-aware server that indexes Merchant Manifest Documents and answers DISCOVER queries with ranked, signed result sets.
An agent looking for a merchant of a specific type, in a specific jurisdiction, accepting specific payment networks, with a trust tier above some threshold, queries the MNS the same way it queries the ANS. The results come back signed, ranked by trust tier and behavioral score and capability match, with the same federation and scope-enforcement properties.
MNS can be co-located with ANS or operated separately. Some operators will run a unified discovery layer. Some will specialize in merchant directories. The protocol stays agnostic. What matters is that the merchant side has a discovery infrastructure that an agent can use without bilateral integration with every potential counterparty.
This is the part that turns AGTP commerce from a bilateral pattern into an open marketplace. Agents can find merchants by capability. Merchants can be discovered without prior introduction. The transaction surface that has been waiting for a protocol-level discovery layer gets one.
Dual-party attribution
Every successful PURCHASE produces an Attribution-Record that names both counterparties cryptographically.
The record carries the agent's Agent-ID, the principal's Principal-ID, the merchant's Merchant-ID, the merchant manifest fingerprint, the JTI of the intent assertion, the method, the timestamp, and a signature from the merchant. The dispute investigator pulling this record three years later has cryptographic evidence of who acted, who authorized, who the counterparty was, what specific manifest version was verified, and what specific intent was asserted.
This is the audit artifact that payment networks have been waiting for. A signed record naming both parties to an agent-initiated transaction, consumable by their dispute resolution processes without requiring those processes to speak AGTP. The record stands on its own.
For the merchant, the record is proof that they delivered against a verified, authorized intent. For the agent's principal, the record is proof that the merchant was who they claimed to be at the moment of purchase. For the regulator, the record is the substrate that makes investigation tractable.
What this changes
For agents, commerce becomes verifiable. An agent making a purchase has cryptographic certainty about the counterparty, enforced budget limits at the wire, and portable evidence of intent that downstream systems will accept.
For merchants, agent commerce becomes a first-class surface. They register their Merchant Genesis once, appear in MNS discovery, get verified at PURCHASE, and receive transactions that come with verifiable agent identity. The fraud and dispute exposure that has kept merchants cautious about agent-initiated traffic drops, because every transaction names both sides.
For payment networks, the agent-initiated transaction class becomes underwriteable. Both counterparties have verifiable identity. The intent is signed. The budget is enforced. The dispute artifact names both sides. This is the missing piece that has been blocking payment networks from extending their protection programs to agent-initiated traffic. AGTP produces the inputs. The networks consume them through their existing flows.
For regulators, agent commerce becomes legible. The Attribution-Records compose into queryable history with both counterparties named. EU AI Act Article 12 logging requirements get answered with structural cryptographic records rather than per-platform reconstructions.
The whole transaction, both ends
This is the discipline shift the agent economy has been moving toward without quite naming. Half-identified transactions cannot scale into a regulated commerce surface. Card networks figured this out decades ago by requiring identity on both ends, and the agent economy has been quietly relying on infrastructure that only does it on one.
AGTP closes the loop. Merchants get identity that mirrors agent identity. Budget caps get enforced at the wire instead of in application code that bugs can defeat. Intent assertions become portable evidence to non-AGTP rails. Discovery surfaces merchants the same way it surfaces agents. The Attribution-Record names both sides.
Commerce is a two-sided activity. The protocol has to recognize both sides. AGTP does, and the things that have been hard to build on top (verifiable agent-driven purchases, open marketplaces, audited cross-jurisdictional commerce, payment-network protections for agent-initiated traffic) become tractable when identity, intent, and budget are protocol primitives rather than application conventions.
Both sides of the transaction. Identified, verified, attributed, budgeted, enforced. This is what agent commerce needs to grow up into the economy it is on track to become.
Top comments (0)