The Trust Gap in Agent Commerce

In the next twenty-four months your favorite assistant is going to start paying for things. Not subscriptions you set up. Not in-app purchases you tap to authorize. Real, autonomous payments: the agent reads a price, decides the price is fair, sends the money, gets the resource. A research agent buying access to an academic paper. A coding agent renting a sandbox to run a build. A travel agent booking a hotel that fits a constraint you described once.

Most of the payment infrastructure for this is already shipping. Coinbase x402 turned HTTP 402 Payment Required into a real wire protocol. Stripe published the Machine Payments Protocol. AP2 is moving. Skyfire built a bank-grade KYC overlay. Every major rail has decided that machine-initiated transactions are a real product surface, and they have built the rails to handle them.

The rails are not the problem. The problem is the question you have to answer before you put money on the rails: should you trust this merchant?

Right now, no one is built to answer that question for an agent.

What an agent actually needs

A human shopping for a sweater on a website they have never visited has a hundred small affordances they don’t even notice they are using. The browser address bar shows the domain. The favicon either matches the brand they were searching for or it doesn’t. There is a privacy policy, an “About Us,” a Trustpilot widget, friends who have shopped there, a phone number that goes to a real human, photos taken by an actual photographer, a return policy in a corporate font, customer reviews from years ago. The shopper takes maybe three seconds to evaluate all of this and decides whether to type their card number.

An agent has none of that.

An agent has a domain name, a 402 challenge, and a price. Maybe an HTML body if it scraped the page. The agent does not have a hundred social signals to triangulate. It has to make a one-shot decision in fifty milliseconds, and if it is wrong, money moves to a thief and never comes back.

So the agent needs a structured, machine-readable trust signal at the point of payment. Something that says: this domain is the real entity. The reputation file is clean. The site has been around long enough to have built a track record. The SSL is valid and the cert is not three days old. Or, conversely: this domain looks like a phishing kit assembled last Tuesday and the agent should not, under any circumstances, send it $0.10 for a “research credit.”

The signal has to be three things at once. Cryptographically verifiable, so an attacker cannot forge a green light. Compositional, so a payment protocol can carry it without inventing trust as a side feature. And published by an entity with no skin in the payment, so the answer doesn’t bend to the incentives of whoever processes the transaction.

That last constraint is the one that breaks every existing player.

Why no payment company can credibly own this

Stripe could publish a “Stripe Trust Score.” Coinbase could publish a “Coinbase Verified.” On paper, both have the data: they see merchants, they see chargebacks, they see fraud. In practice, neither can be the authoritative trust layer for autonomous agent commerce, and the reason is structural.

A payment company makes money when payments happen. A payment company that scores its own merchants has, on every score, a small but unavoidable conflict: the score that maximizes revenue is the score that lets the most merchants through. The score that maximizes safety is the score that turns the most away. There is no value of “Stripe Trust Score” that doesn’t sit somewhere on this spectrum, and once the spectrum exists, agent developers cannot trust that the dial isn’t being slowly tuned in the direction the company’s quarterly numbers prefer.

This is not a hypothetical. Credit card networks faced exactly this conflict in the 90s and 2000s, and the resolution was a parallel ecosystem of independent fraud-scoring vendors (FICO, LexisNexis Risk, Sift, Forter) whose product is precisely “we tell you who not to trust, and our customer is not the merchant.”

The same logic applies to agent commerce, and more sharply, because agents will execute orders of magnitude more transactions per dollar of revenue than human shoppers do. A small bias in the trust score, multiplied over millions of agent decisions per day, becomes a real loss to the side of the market that wasn’t aware the dial was tilted.

The right primitive is the same one that emerged in the credit-card era: an independent attestation layer, owned by a party that does not handle the money.

Why no platform can credibly own this either

The other obvious candidate is the agent platform itself. OpenAI could ship “OpenAI-verified merchants.” Anthropic could publish a list. Google’s Vertex Agent Builder could maintain a registry.

These would be useful but they are not the same product. A platform-managed list is a curated allow-list, with all the brittleness curation implies: humans have to decide what’s on it, the threshold is hard to articulate, the criteria are not public, and the list is only as good as the platform’s incentive to maintain it. A merchant who is on OpenAI’s list but not on Google’s now exists in two trust universes at once.

What agent commerce needs is a protocol, not a curated list. A way for any agent on any platform to ask the same question and get the same answer, signed in a way every other agent can independently verify. That is what AttestSeal is building.

What the trust layer looks like

The shape we have settled on, after a year of work and a million domains scored, has four properties.

It is signal-driven, not curation-driven. Every score we publish is computed from observable evidence: domain age via WHOIS, SSL chain validity and length, DNS record completeness, content signals (privacy policy, terms of service, contact info), reputation file (Spamhaus, SURBL, URLhaus, Google Safe Browsing), and identity (cross-referenced WHOIS organization, SSL certificate organization, schema.org markup, Tranco rank). No human looks at a domain and decides “this one is good.” The model is versioned (attestseal-v1.5.1-weights today) and the weights are published. When a merchant disagrees with a score, they can point at the signal that’s missing and we can show them what to fix.

It is cryptographically delivered. Every score is signed with Ed25519 against did:web:attestseal.com. The signature covers the domain, the score, the recommendation, the basis, and the timestamps. An agent that has cached our DID document can verify a score in two milliseconds without calling our API at all. An attacker who wants to fake a green light has to forge an Ed25519 signature on the canonical signing input — which, by construction, they cannot.

It is layered, not binary. Trust is not a single bit. A top-100 Tranco brand with five years of clean reputation and a valid SSL cert is a different shape of “PROCEED” than a small business that completed our registration flow last week. Both are PROCEED, but the basis (well_known_tranco_anchor versus registered_proceed) tells the agent which one to apply transaction limits to. Higher tiers (KYC-verified) unlock higher limits because the operator did more verification work to earn them. The taxonomy is a ladder, not a coin flip.

It is composed into the payment, not bolted on. When x402 ships a 402 challenge to an agent, the response carries X-AttestSeal-* headers in the same packet. The agent verifies the signature against its cached DID and decides whether to pay, with no extra round-trip and no separate trust-API dependency. AttestSeal becomes infrastructure that disappears into the protocol, the way TLS disappeared into HTTPS once Let’s Encrypt removed the certificate cost.

The window

Right now, the field is small. Maybe a thousand teams worldwide are building agents that handle real money. The protocols are weeks old. The patterns aren’t set. The space where trust normally calcifies has not had time to calcify.

This is the window. In twelve months one of three things will be true: a trust layer will exist as a neutral protocol that every agent runtime relies on, a payment company will have rolled their own and the ecosystem will quietly accept the conflict, or there will be no layer at all and the first wave of agent fraud will be the news story that drags everyone back to the drawing board.

The bet AttestSeal is making is that the first outcome is the one the ecosystem actually wants. We are publishing the dataset, the spec, the SDKs, the CDN-edge templates, and the verification logic in the open. We don’t handle anyone’s money. We sign every score and let any agent verify it without trusting us. We name our basis for every recommendation so agents can apply policy correctly. And we are doing this now, while the cement is still wet, because the second outcome compounds in ways the first one does not.

If you are building an agent that handles money, look at the spec. Tell us where it’s wrong. The protocol gets better with adversarial review, and we would much rather hear “this header is misnamed” from a hostile reviewer in May than from an angry merchant in October.

The trust gap is closing. We’re trying to make sure it closes the right way.

AttestSeal is an independent trust attestation layer for AI agent commerce. The dataset, the spec, and the SDKs are open at github.com/AttestSeal. For partnership inquiries, [email protected].