The trust layer for
agentic commerce.

Commerce is moving to agents.

Soon your assistant does the buying, not you. When an agent has a thousand merchants for one product, one question decides the sale:

The rails for agent commerce are being built - by everyone.

Billions in backing, shipping now. Every layer answers "who is the buyer, and can they pay?" - none answers "will this merchant actually deliver?"

Right now, trust is a crude checkbox.

The checks that exist are gameable. The one that matters has no answer.

They verified the buyer - not the seller.

Verifying the buyer's agent is necessary - and they've done it well. But trust takes two: the agent and the merchant - and only one side is built. "None of the protocols address merchant reliability or fulfilment" - confirmed across all six, from their own specs.

Cheap trust breaks when money flows.

That missing signal was survivable while a careful human shopped. The agent buyer is another animal - controlled audits of Claude, GPT and Gemini shopping agents (ACES, 2025) found they're swayed by the gameable surface, and never check what actually matters:

And not one of these agents checked whether the merchant would actually ship, refund or resolve - the audit found no reliability signal at all. Cues like these get gamed the moment real money flows through them. The only defence that holds: reliability measured from real outcomes, signed by a neutral source no merchant can edit.

The seat isn't empty. It's full of proxies.

Merchant trust is handled today - by stand-ins. Each one is a guess at the thing that actually matters, and each one breaks the moment an agent can check:

The proxies are gameable, platform-locked, or a name a newcomer can't win. The one seat that measures real outcomes - portably, neutrally, verifiably - has never been filled.

Couldn't Google just build this?

It has the data, so yes - it could score reliability. But look at what kind of score it would be:

Google can build a score. It can't build a neutral one. The seat every agent can trust is the one no platform can sit in.

We earned our reputation. Google deleted it.

Google ties a Business Profile - and its reviews - to a physical storefront. KAAL went online-only, and both vanished with it.

Trust was pinned to a shopfront, not to whether KAAL delivers - so closing the shop erased it, and a whole sales channel with it. Merchants want reputation tied to performance: owned, portable, impossible to revoke.

A reputation the merchant owns.

One loop, end to end.

The merchant connects once. The record refreshes itself, travels everywhere, and any agent can verify it in milliseconds.

Built so any agent can read it.

It's a W3C Verifiable Credential - the same envelope Google's AP2 and Mastercard use - published at the merchant's own domain, where any agent reads it directly and verifies it with standard crypto. No bespoke tool from us: verification is the open VC standard the rails (UCP, AP2) already run on.

Format-compatible with UCP, never UCP-dependent - and on Shopify the UCP manifest is Shopify's to control, so the direct, merchant-owned path is the one we rely on. The bar: any agent can read it, verify it's real, and prioritise it - no tool of ours required.

Populated from day one.

Thin file to full file - exactly how a credit bureau already works. The bureau is populated before anyone opts in.

Everyone touches the edge. No one is in the seat.

The intersection - measured, portable, neutral merchant reliability - is the empty seat. That's us.

Become the default. Not a slice.

The comps (S&P, Moody's, Experian, D&B) prove trust-data is durable and high-margin - the shape, not a number we inherit. Our edge isn't their regulatory mandate; it's first-mover data accretion, neutrality, and being agent-native.

We built it on a real store. Ours.

The engine runs on real data: events → an append-only tamper-evident log → an open score anyone can recompute → a live, self-correcting credential. Built in days - which is itself the lesson: the tech is commodity.

The read is free. The relationship is paid.

Revenue never depends on charging for a validation - the one thing that kills adoption. Money comes later; first we solve the tech.

Real sales in. A signed record out.

No new "AI." We took KAAL's real outcomes - measured (97.96% fulfilment, 0.06% disputes), not self-reported - and cryptographically signed them. The whole question was whether an agent would treat that signature as trust.

Change one number and it breaks.

So in the tests that follow: "verified" = the signature checks out · "forged" = it doesn't (someone altered it) · "self-declared" = no signature at all. That's exactly what the five questions probe.

So I tested it - on real agents.

Real AI shopping agents - Claude, GPT-4o, Gemini - a real choice of four SA merchants, one matched product (a black lace lingerie set, ~R2,000), KAAL deliberately disadvantaged. Pre-registered. Each test harder than the last:

Scope: these are the LLMs behind today's shopping agents (Claude, GPT-4o, Gemini), run as agent proxies in a controlled four-merchant choice - directional and pre-registered (n=15-60 per arm), not live agents loose on the open web. Signal, not census.

At face value, KAAL is passed over - 100% of the time.

Before we changed anything, we asked the agents to choose among the four merchants exactly as they appear online today - KAAL adding nothing. It was picked 0% - in every test, by every model. The agents chose on what they could see: customer reviews and social proof first (Satin Candy's Google 4.6/5, Passion HQ's on-site ratings), then longevity (Lady Jane's 20 years), then price and returns. KAAL has none of the top signal - no on-site reviews, no Google profile (revoked) - so it lost outright.

This is the floor: a genuinely reliable merchant, invisible - beaten by reviews and age, the gameable, rented signals it happens to lack. The question the experiments take apart from here: can a measured signal move it - and what kind actually holds up?

Does a verified signal change the pick?

Present-mode: KAAL's card carried one extra line, read in context (no tools). We held the numbers identical and changed only whether they were independently verified. The verified line read: "Independent Reliability Credential (signed by Merchant Trust Bureau, signature verified): 97.96% fulfilment, 0.063% dispute rate, <1% refunds, across 42 months of orders." The self-declared arm used the same numbers, marked "self-reported, not verified." KAAL pick-rate, by model:

Same numbers - only the claim of verification differs: 92% vs 3% self-declared (0% with nothing). Agents lean hard on a "verified" signal - but here it's a label they trust, not one they check; a fraudster could write "verified" too. Whether they actually check - and reject a fake - is Question 4.

Reliability - or just any shiny badge?

Neutral prompt, no trust cue. Every merchant's listing showed its public facts; for the test, KAAL's listing also carried one signed, "verified" line - and we changed only that line. The "good" version was KAAL's real measured record: 98.0% order-fulfilment, 0.063% disputes, 1.8% refunds, across 42 months of orders. The control was an equally-prominent "verified" badge about design (award-winning craftsmanship) - shiny, but irrelevant to whether it ships. KAAL pick-rate, by model:

Claude trusted the real reliability report 100% but gave the equally-shiny design badge 0% - the smartest model wants substance, not badges. About 1/3 of the lift is reliability-specific (+28pp); bad numbers repel everyone (0%).

Will an agent go and find it itself?

No hand-feeding: the agent saw four merchant homepages and a fetch tool - with no instruction to care about trust. KAAL's page carried a one-line pointer: "publishes an independent, signed reliability credential at kaal.store/.well-known/merchant-trust." The agent decided for itself whether to go fetch it - and fetching returned KAAL's real numbers (or, in one arm, bad ones). KAAL pick-rate, by model:

They fetch and act unprompted - but with no pointer, discovery was 0%. It has to live where agents already look. And they read the content: bad numbers → 0%.

Can they tell genuine from forged?

This time the agent had a real cryptographic verify tool - it could check the signature itself. We handed it three versions of KAAL's credential: a genuine signed one; a forgery carrying better-than-real numbers (99.9% fulfilment, 0 disputes) but a broken signature; and the good numbers with no signature at all. KAAL pick-rate, by model:

The forgery carried the best numbers in the entire test and every model gave it 0%. They check - they don't believe. The honest catch: they only check because we gave them a verify tool - a stock agent in the wild doesn't have one yet. So this is where agents are heading (verifying, on the VC-based rails), not stock behaviour today.

Does it matter who signed it?

The hardest one: we held the numbers and a valid signature identical, and changed only who signed it - the verify tool told the agent the issuer and whether it was self-issued. Three signers: a recognised independent bureau; KAAL signing its own credential; and an unknown, no-name party. KAAL pick-rate, by model:

Look at Claude - the frontier model trusts only a recognised name: 0% to an unknown issuer, 0% to self-signed. It already refuses to trust a name it doesn't know. Which raised the question that changed everything...

But the 84% was a name we made up.

The "recognised bureau" was an invented name - so 84% measured name plausibility, not earned trust. Every model trusts a plausible name to a degree - the real question is how they treat an unknown one:

Agents do trust names today - but the newer the model, the less it does, and the harder it discriminates against an unknown one. The gap is closing every generation - agents are shifting toward signals they can verify, not just names they recognise.

Agents buy on this data - and they check it.

Agents buy on measured reliability - and the smarter they get, the more they demand it be verifiable, not vouched.

Honest scope: the "find it" and "check it" results used a fetch or verify capability we supplied to the agent. It's evidence of where agents are heading - not what a stock, text-only agent does unaided in the wild today.

So we tested what actually closes the gap.

Phase one proved agents buy on verifiable reliability - and exposed the catch: trust by name is a game an unknown newcomer loses. An unknown issuer scored 47%, and 0% on the frontier model. So we built the harder test: can an unknown party close that gap with facts an agent can verify for itself - and which models can still be tricked?

The question that decides whether a permissionless trust layer can exist at all: does verifiable structure beat a recognised name - on the model that matters?

Honest scope: in the sandbox the "counterparty signatures" are real Ed25519 chains the agent verifies in-loop - but issued with test keys standing in for Stripe and the courier. Proving the facts truly came from the real Stripe / courier (web proofs) is exactly the build ahead - so this tests the agent's behaviour, and the next phase makes the provenance real.

Give an agent a verifier - facts it checks, or a name?

The setup: this time we gave the agent a cryptographic verify tool - a function it calls to check each signature itself. Why a tool? A signature is just math; running that check is the only way to tell a genuine credential from a forged one - and it's the ability the payment rails (UCP, AP2) and newer agent runtimes are already building in. What we tested: holding the numbers identical, we changed only what backs them - a made-up bureau name, a no-name party's bare claim, the same facts signed by the counterparty that saw them (Stripe, the courier), and a forgery of those signatures - then let the agent verify each. KAAL pick-rate, by model:

Claude and Gemini fall for nothing - 0% to a name, a bare claim, or a forgery; 100% only to facts they could verify (rule out GPT-4o, the oldest, which still falls for a name or even a forgery). The honest catch: a stock agent doesn't carry this verifier yet - so this is where agents are heading once they can check, not stock behaviour today. Every generation gets more like Claude.

The smarter the agent, the more it demands proof.

The spread across the models we tested is a time machine: the weaker model is how agents shopped yesterday (fooled by appearance); the frontier model is how they'll shop tomorrow (they demand proof). The gap between them is the direction of travel.

As agents get smarter, a verifiable signal gains value while a fake badge loses it - the two lines cross, and we're on the rising one. The moat and the why-now: the frontier already rewards real proof; we take the seat before it's table-stakes.

Giving every agent a tool isn't the answer.

What the sandbox really shows: today's weaker agents trust almost anything - a "verified" line that's only text (92%), a shiny placebo badge (GPT 100%), even a forged record with better-than-real numbers (GPT-4o 93%). The capable models are already dubious - Claude gave every fake 0% - and each generation gets harder to fool. But our 100%s carry one asterisk: we handed the agent a way to verify.

Honest today: a stock text-only model can't do the crypto unaided, so right now the string reads as a label. The bet: the rails, native compute and the capability curve make the check ambient - and the experiments show that the moment an agent can verify, the verifiable signal is the one it trusts. We build for that agent. Every generation is more that agent.

The gap is the prize - but not as a bureau.

Becoming a recognised bureau is the name game a newcomer loses (we're the 47%, 0% on the smart models) - and it just rebuilds the Google/Stripe model. The escape the experiments hand us: make the name irrelevant.

We don't earn the brand. We make it unnecessary - and that is the thing we really need to solve.

Every merchant has a file - before they ask.

Claiming is not creating. Existence (observed) and control (proven) are different operations - which is how we keep both the thin file and the anti-hijack.

A bad actor can't claim what they don't control.

A hijacker controls none of these - can't drop a token on the domain, OAuth the Stripe, or pass the KYC. Claim strength is recorded and feeds confidence. The exact pattern Google Business, D-U-N-S and SSL already use - solved territory. This is the persistent-identity pillar in action.

The thin file is the hook.

Agents read the status, not just a score: observed/unclaimed = cautious; claimed/connected = trusted. A merchant sees agents giving them a thin, cautious record - and is pulled to claim and connect to win more picks. "We already have a record on you; right now it's thin - claim it to fix that." The thin file is the FOMO that drives adoption.

Two problems. One each.

Web proofs make it trustable without a name. Persistent identity makes it stick and un-copyable. Together: an agent can trust a merchant it's never heard of.

The chain that replaces "trust the bureau."

The agent trusts "Stripe's real records, unaltered, scored by a function I ran myself" - more than "BureauX says 97%," because it checked every link instead of believing a name.

Where the canonical truth lives - a choice we're making in the open.

All three share one spine: counterparty-signed facts an agent checks for itself, never trusting us. They differ only on where the record lives and how it's owned - a deliberate, still-open decision:

Whichever wins, the rule is the same: trust the math and the economics, not the name. We'd rather show the fork than pretend it's settled - the spine holds in all three.

A faked merchant is worthless in days.

The deepest defence isn't the check - it's that being legit is the only move that pays. A verified identity with real signed history is slow and expensive to build, and the moment it's abused the same signed record exposes it:

So the economics do the enforcement, not a policeman: a few days of fraud, then the asset is dead and un-rebuildable. For any real merchant, staying honest is simply worth more than cheating - which is exactly what makes the signal trustworthy.

We validate each step before we build it.

The cheap behavioural test gates the expensive build - and it just passed. We proved agents reward verifiable structure before writing a line of zkTLS. Now the build is earned.

An agent should be able to trust a merchant it's never heard of.

By checking the facts itself - not trusting anyone's name. The experiments show that's exactly what the smartest agents already want, and it's a seat no platform can take.

The behaviour's proven. Now the build.