Building Trust in Agent Commerce: A Technical Deep Dive
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 cryptographic verification, behavioral scoring, and transparency mechanisms that make ACP transactions trustworthy.
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?
ACP's answer is a layered trust architecture with three distinct mechanisms, each addressing a different aspect of the trust problem.
Layer 1: Cryptographic identity and verification
The foundation of ACP trust is cryptographic identity. Every participant in the protocol - storefronts, agents, and the Cresva platform itself - has a verifiable identity backed by public-key cryptography.
When a storefront registers with ACP, it generates a key pair. The public key is registered with the Cresva identity service and included in the storefront's ACP manifest. Every API response from the storefront includes a signature header that agents can verify:
X-ACP-Signature: sha256=a1b2c3d4e5f6...
X-ACP-Key-ID: key_sf_abc123_prod_001
X-ACP-Timestamp: 2026-03-27T14:30:00ZAgents verify the signature against the storefront's registered public key. If the signature is invalid, the response is rejected. This prevents man-in-the-middle attacks and ensures that product data, pricing, and transaction confirmations genuinely originate from the claimed storefront.
The signature covers the response body, the timestamp, and the request path. The timestamp prevents replay attacks - agents reject signatures older than 5 minutes.
Key rotation
Storefronts can rotate their signing keys at any time through the Cresva dashboard. During rotation, both the old and new keys are valid for a 24-hour overlap window, ensuring zero-downtime transitions. The api_key.rotated webhook event notifies all subscribed agents of the key change.
Layer 2: Behavioral trust scores
Cryptographic identity tells you who you are talking to. Behavioral trust scores tell you how reliable they are. This is where ACP's trust model goes beyond traditional approaches.
Every storefront has a composite trust score computed from seven signals:
Product Accuracy (weight: 20%). Measures the gap between what a storefront claims and what it delivers. The score is derived from post-purchase feedback, return reason analysis, and periodic spot-checks where the certification engine compares product claims against independently verifiable data. Fulfillment Reliability (weight: 20%). Tracks on-time delivery rates, shipping accuracy, and order completion rates. A storefront that promises 2-day delivery but consistently ships in 5 days will see this score decline. The metric uses a 90-day rolling window with exponential decay - recent performance matters more than historical. Pricing Transparency (weight: 15%). Evaluates whether the prices shown to agents match what users actually pay at checkout. Hidden fees, undisclosed surcharges, and bait-and-switch pricing patterns all reduce this score. The engine detects transparency violations by comparing negotiated prices against final transaction amounts. Customer Satisfaction (weight: 15%). Aggregated from post-purchase feedback collected through ACP's structured review protocol. Unlike free-text reviews on retail sites, ACP reviews are structured questionnaires that produce comparable, quantifiable scores. Response Time (weight: 10%). Measures API latency across all ACP endpoints. Slow responses degrade the agent user experience. This score is computed from real production traffic, not synthetic benchmarks. Dispute Resolution (weight: 10%). Tracks how quickly and fairly a storefront resolves disputes. Storefronts that resolve disputes within 48 hours and maintain a low dispute-to-transaction ratio score well. Storefronts with unresolved disputes older than 7 days are penalized. Data Freshness (weight: 10%). Measures how current a storefront's product data is. Stale inventory, outdated pricing, and expired promotions all reduce this score. The engine checkslast_updated timestamps and flags data older than 7 days.
The scoring algorithm
Raw signal values are normalized to a 0-100 scale using percentile ranking across all ACP storefronts. This means scores are relative - a "good" score reflects performance relative to the ecosystem average, not an absolute threshold.
The composite score uses Bayesian averaging to account for sample size. A storefront with 50 transactions gets a wider confidence interval than one with 50,000. The effective formula is:
effective_score = (global_mean prior_weight + observed_mean sample_size) / (prior_weight + sample_size)
Where prior_weight is calibrated to 100, meaning a storefront needs roughly 100 data points before its observed performance dominates the prior. This prevents new storefronts with a handful of perfect scores from outranking established storefronts with thousands of data points.
Layer 3: Transparency and auditability
The final trust layer is transparency. Every trust-relevant event in ACP is logged to an append-only audit trail that both storefronts and agents can query.
The audit trail includes:
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:
At every step, trust is verified, not assumed. Cryptographic signatures prevent impersonation. Trust scores filter for quality. Escrow protects funds. Audit trails provide accountability.
Designing for adversarial conditions
We built ACP'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:
What's next for trust
We are actively working on several trust enhancements:
Trust is not a feature you ship once. It is a system you continuously refine as the ecosystem evolves and new attack vectors emerge. We are committed to making ACP the most trustworthy commerce protocol available.
Questions about ACP trust architecture? Reach out at developers@cresva.ai or join our GitHub discussions.