Building Trust in Agent Commerce: A Technical Deep Dive

Retraction of Layer 1, added 16 September 2026. This post opened with a

section headed "Cryptographic identity and verification". It described a key

pair generated at registration, a public key registered with a "Cresva

identity service", an X-ACP-Signature header on every API response, a five

minute replay window and a 24 hour key rotation overlap. None of that exists

and none of it was ever built. A reader who implemented signature

verification against it would have found no signature to verify.

What is true. A storefront response carries X-OSP-Version,

X-ACP-Version and the three X-RateLimit-* headers, and nothing else that

is protocol specific. There is no response signature and no identity service.

The one signature in OSP is on an outbound webhook: HMAC-SHA256 over the

raw request body with a shared secret, sent in X-Cresva-Signature with a

sha256= prefix. See Webhooks for the verification code.

The section is removed below. Layers 2 and 3 are corrected against the live

API rather than removed, and the corrections are marked where they occur.

Trust is the fundamental primitive of agent commerce. When an AI agent recommends a product, commits funds, or negotiates on a user's behalf, every party in the transaction needs verifiable assurance that the others are acting in good faith. This post covers the behavioral scoring and transparency mechanisms that make OSP transactions trustworthy. It originally opened with a cryptographic verification layer as well. That layer never existed, and it is retracted directly above and removed below.

The trust problem in agent commerce

In traditional e-commerce, trust is a human judgment. You visit a website, see a recognizable brand, read a few reviews, and decide whether to buy. The trust evaluation is implicit, subjective, and happens in your head.

Agent commerce removes the human from the loop. An AI agent cannot "feel" whether a storefront looks trustworthy. It cannot recognize a brand logo or be reassured by a polished design. It needs computable, structured trust signals that it can evaluate programmatically.

This creates a fundamental design challenge: how do you encode trust in a way that machines can reason about, while remaining meaningful to the humans who ultimately bear the risk of a bad transaction?

OSP's answer is a layered trust architecture: a computed score for how reliable a storefront has been, and an audit trail that says how the score was arrived at.

Layer 1: Behavioral trust scores

A trust score answers one question: how reliable has this storefront been, on evidence. It is the part of the model that is implemented.

Every storefront has a composite trust score from 0 to 100, computed from seven

components. These are the seven names the API returns, read from

GET /api/storefront/{brandId}/trust on 16 September 2026:

data_accuracy, fulfillment_speed, return_rate, negotiation_fairness,

response_reliability, dispute_record, customer_satisfaction.

Correction, 16 September 2026. This post listed seven components under

different names, four of which have never existed: "Pricing Transparency",

"Data Freshness", "Response Time" and "Dispute Resolution". It also gave a

weight for each one. The weights are not published by any endpoint, so the

figures here could not be checked by a reader and are removed rather than

restated. Two real components, return_rate and negotiation_fairness,

were missing from the list entirely.

The part worth understanding is not the list. It is that a component with no

evidence behind it is returned as null rather than as a plausible middle

number, and the response says which ones were measured:

"components": {
  "data_accuracy": 50,
  "fulfillment_speed": null,
  "return_rate": null,
  "negotiation_fairness": 50,
  "response_reliability": 50,
  "dispute_record": null,
  "customer_satisfaction": 50
},
"measured_weight": 0.55,
"provisional": true

That is the live response for Cresva's own storefront, captured 16 September

1. Three of the seven are null because nothing has happened yet that would

measure them. measured_weight says how much of the score rests on evidence,

and provisional is the flag that says the number should not be read as a

verdict.

The scoring algorithm

Correction, 16 September 2026. The text here described percentile

ranking across all OSP storefronts and a Bayesian prior calibrated to 100

data points. Both describe a population. The API reports

verified_transactions: 0 for the storefront above, so there is no

population to rank against and no sample for a prior to be swamped by. The

formula is a design and is documented as one in

the architecture post,

which carries its own status note. It is removed from here, where it read as

a description of something running.

Layer 2: Transparency and auditability

The final trust layer is transparency. Every trust-relevant event in OSP is logged to an append-only audit trail that both storefronts and agents can query.

The audit trail includes:

• Every trust score calculation with the input signals and weights used
• Every dispute and its resolution outcome
• Every certification result with individual test scores
• Every negotiation outcome (accepted, rejected, countered)
• Every transaction state transition with timestamps

This audit trail serves two purposes. First, it lets storefronts understand why their trust score changed and what to do about it. Second, it gives agents a historical record they can use to make nuanced trust decisions beyond the composite score.

For example, an agent might check whether a storefront's trust score has been trending up or down over the last 30 days. A storefront with a current score of 75 that has been climbing steadily from 60 is a different risk profile than one at 75 that has been declining from 90.

Trust in practice: a transaction walkthrough

Here is how all three trust layers work together in a real transaction:

1. An agent queries a storefront for running shoes. The response is a list of product cards. (Illustrative: the example below walks one transaction through the model, and the numbers in it are chosen to show the mechanism rather than read from any storefront.)
2. The agent filters on the trust score, and on fulfillment_speed in particular, because the user needs the shoes by Friday. If that component comes back null it has no basis to filter on and the honest move is to say so rather than to substitute a default.
3. The agent selects a storefront and initiates a negotiation.
4. The negotiation succeeds. The agent creates a transaction and the buyer pays the storefront directly, on the storefront's own rails.
5. The storefront confirms shipment and the shipping carrier confirms delivery.
6. The user receives the shoes and confirms receipt. A structured review request is sent to the user.
7. The review feeds back into the storefront's trust scores, closing the loop.

At every step the agent works from what was measured rather than from what was asserted. Trust scores filter for quality, and say how much of themselves rests on evidence. Audit trails provide accountability. Cresva is never in the payment path, so there is no platform-held balance for any of this to depend on.

Designing for adversarial conditions

We built OSP's trust system assuming adversarial conditions. Storefronts might try to game their trust scores. Agents might try to extract preferential pricing by spoofing user context. Bad actors might try to disrupt the ecosystem.

Our defenses include:

• Score manipulation detection. The trust engine monitors for suspicious patterns like sudden spikes in positive reviews or coordinated feedback from related accounts. Anomalous patterns trigger a manual review and temporary score freeze.
• Agent identity verification. Agents authenticate with API keys scoped to one brand. Rate limiting is enforced per caller: 10 requests a minute with no credential, 60 on a public key, 300 on a secret key, read from the live X-RateLimit-Limit header and from lib/api-facts.ts on 16 September 2026.
• Trust and certification as a forcing function. Cresva does not hold funds, so it cannot freeze a payment to deter fraud. Instead, a storefront with an elevated dispute rate is flagged for review, has its trust score reduced, and can be suspended from certification. That is a reputational and distribution consequence, not a financial one, and it is the honest lever available to a platform that never sits in the payment path.

What's next for trust

We are actively working on several trust enhancements:

• Cross-protocol trust portability. We are exploring how trust scores earned on OSP could be recognized by other commerce protocols, and vice versa. Interoperable trust reduces cold-start problems for new storefronts.
• User-controlled trust preferences. Letting users set personal trust thresholds that their agents enforce automatically. A risk-averse user might require Platinum certification; a bargain hunter might accept Bronze.
• Real-time trust streaming. Instead of periodic score recalculation, trust scores would update in real time as new signals arrive. This is technically challenging at scale but would make the trust system more responsive.

Trust is not a feature you ship once. It is a system that gets refined as the ecosystem evolves and as new attack vectors emerge. The part of it that is built today is the score and the record of what went into it; the rest of this post is a design, and it is marked as one.

---

Questions about OSP trust architecture? Reach out at developers@cresva.ai or join our GitHub discussions.