Avoid opening your sales channel blind
Before exposing sensitive actions to an agent, understand who is acting, with what context, and under what mandate.
Less ambiguity before checkout.For merchants and marketplaces
Try AI-assisted shopping in your store, under your rules.
Choose one operation to test. Your team or integrator can review your platform with Trusteed to establish which actions it supports and where approval is needed before you agree on the pilot's scope. We'll review the work first.
Already working with an integrator? Include their details in your request so the teams involved can review the project together.
For online stores and marketplaces
Let assistants help shoppers without bypassing your rules.
Your catalog, checkout, and payment provider stay where they are. If an agent requests too many units or uses an old price, you can review the action before it continues. Coverage depends on your integration and the agreed pilot.
Protect your financial interests
Amounts, discounts, inventory, and retries need explicit limits that a verified identity alone doesn't solve.
Allow, review, or block decisions that are explainable to your own team.Keep evidence before a dispute appears
When an operation is questioned, the relevant data is usually scattered across the agent, your store, the payment provider, and fulfillment.
Verifiable individual receipts and visible gaps before the conflict.See it in action
This is what AI-agent checkout looks like
A scripted walkthrough using the figures we measured live on 2026-09-17; the checkout step shows how the server answers since 2026-09-21. It calls no backend and needs no key. For the real thing, open the playground.
Shopping assistant Demo Store · via MCP44.7/100 · RESTRICTED
Step 0 of 22
tools/call
Press Play to see the real tools/call requests.
How a pilot starts
From the operation that worries you to a metric you can show.
The entire platform isn't integrated. A case is scoped, measured, and then you decide whether to expand it.
01
You choose the operationThe delegated action that concerns you most today
discover02
You choose Control or EvidenceDepending on whether the cost is in the decision or appears later
design03
It integrates on top of your current systemsWithout migrating checkout, payment provider, or catalog
in pilot04
You measure the resultExplained decisions, correct reviews, or complete evidence
validateWhat your store gains
Decide when a purchase needs approval.
An assistant might prepare an order above your spending limit, giving your team a specific approval scenario to test before expanding the pilot. In a supported flow, the pilot can ask for confirmation before the purchase continues.
01in pilot
IF THE RISK IS OPERATIONALYou decide before it executes.
Control evaluates context, applies your rules, and requests human confirmation where you define it.
- Guided agent verification access, not a public API
- Your own policy and risk signals
- Explainable result per operation
02in pilot
IF THE RISK APPEARS LATERReview what was recorded without rebuilding every step by hand.
Evidence identifies which facts, hashes, and receipts exist before designing a useful export for the recipient.
- Readiness per operation
- Verifiable individual TrustReceipt
- Export co-designed with your payment provider
03audit available
IF YOU DON'T KNOW WHERE TO STARTYou find out what's missing before committing.
The free audit checks your store's public pages and identifies what to fix. Other capabilities keep their own availability status.
- Capability map by status
- Trust Score with provenance
- A roadmap, not a filed report
Proof that already exists
A signed receipt makes the record verifiable; it does not guarantee winning a dispute.
When a TrustReceipt is enabled for a pilot operation, it keeps a signed record of what was logged. It is an individual unit; we do not present it as a complete lifecycle history.
Open verifier ↗available
Individual record signing one operation.trust-receipt+jwt- input_hash
- sha256
- signature
- JWS · Ed25519
- scope
- supported surfaces
in pilot
The exact scope of surfaces is agreed on when designing your pilot.
Before and during the pilot
Decide which orders need review and keep the reason.
For example, if an order exceeds the agreed amount, the pilot can request approval before continuing. For supported actions, the rule applied is recorded.
Without TrusteedYou treat every agent like any other customer and discover the problem only after it has already caused a loss or a dispute.
With TrusteedYou define the condition beforehand and keep proof of what was decided and why.
Before evaluating your channel
What a merchant usually asks before the pilot.
Do I have to change my e-commerce platform or my payment provider?
No. Trusteed is designed as a layer on top of your existing systems. The exact scope is defined per surface and per pilot, not as a migration.
How much integration effort does it require?
A pilot is scoped to one sensitive operation, not the whole platform. The effort is sized together with you before committing to it.
What happens with agents that already buy from me today without going through Trusteed?
They keep operating the same way until you decide to expand the pilot's scope. There's no forced cutoff of existing traffic.
Do I need to choose between Control and Evidence, or can I have both?
A pilot starts with one of the two, depending on where the cost is today: in the decision or in the evidence. Expanding to the other is a later step, not an entry condition.
A next step, not a broad promise
Request an evaluation for your store
Tell us which operation concerns you. The conversation starts by scoping the case, the systems, and the metric, not with a promise to replace your online store or payment provider.
API endpoints available on your store
This is the architecture we are migrating every store to: three specialized MCP endpoints: one per required trust level. AI agents pick the right endpoint based on what they need: browse your catalog, manage a specific customer's orders, or complete a payment.
Rollout is progressive, store by store: until your store is migrated, it keeps being served by the single MCP endpoint below, with no action needed from you. The split is built-in to limit each bucket's blast radius and give you independent rate limits once it activates.
/{storeSlug}/mcp/discoveryDiscovery · 21 toolsAnonymous and cacheable. Search, trust score and policies so agents can discover your store.
/{storeSlug}/mcp/customerCustomer · 8 toolsOAuth 2.1 with resource indicator. Orders, returns, and the authenticated customer's profile.
/{storeSlug}/mcp/checkoutCheckout · 26 toolsAgenticTrust JWT + Idempotency-Key + signed mandate. Cart, shipping, payment: everything transactional.
/{storeSlug}/mcpCurrent endpointSingle monolithic MCP endpoint. It is what serves the large majority of active stores today. It will be phased out store by store as each one migrates to the three buckets above; existing partners keep working in the meantime with no change on your side.
The numbers above are what the catalogue declares, not what your store serves. Until you pick a list, we serve 14 of the 55: our default, not your decision. Change it under Settings → MCP tools, in the Trusteed dashboard or in the panel embedded in your platform. Saving the list makes it your decision: from then on, what is not there is not served.