Your privacy, protected by design

1. Minimal customer data

The relationship with your customers is yours. Trusteed is designed to store the minimum data needed to operate your MCP store: account and store configuration. We do not store payment card data. In checkout flows we may temporarily process and store buyer and shipping data tied to an order or session in order to complete the flow and allow its audit.

2. Credential security

Your Shopify, WooCommerce, PrestaShop, Odoo and Magento API keys and OAuth tokens are encrypted at rest with AES-256. When AI agents access your store they use temporary, scope-limited credentials that prevent unauthorized access to your core infrastructure.

3. Transparency toward you

You can see exactly which tools and endpoints you're exposing to external agents. Every read and write request is logged, so you know how each agent is interacting with your store.

4. Explicit confirmation

Sensitive actions - closing a checkout, buying an item - require explicit human confirmation when the merchant's policy requires it. The agent prepares the cart; the final click is what provides security and traceability.

5. Automated processing disclosure

Our MCP tools process product data to generate suggestions. Those suggestions are automated and non-binding: the final purchase decision is always the person's.

6. International transfers

When we rely on AI providers located outside the EEA, the level of protection for personal data is ensured through the EU-U.S. Data Privacy Framework or standard contractual clauses.

7. Commercial communications

We do not send commercial communications without your prior express consent, except where a prior contractual relationship exists and the products are similar to those originally contracted. You can unsubscribe at any time.

8. Security breach notification

Our obligation depends on our role over the affected data, and it is not the same in both cases. We separate them because the previous wording — “we notify you and the competent authority within 72 hours” — assumed an obligation that in most cases is not ours, and could lead you to believe yours was covered.

• Data we control — your account, your store configuration, billing: we notify the Spanish Data Protection Agency within a maximum of 72 hours from becoming aware of the incident (Art. 33.1 GDPR), and we inform you without undue delay where the risk is high (Art. 34).
• Buyer data processed on your behalf — where we act as your processor (Art. 28 GDPR, clause 9 of the Terms): we notify you without undue delay, with the information required by Art. 33.3, so that you can meet your own notification duty. In that case you are the one who notifies the authority, in your capacity as controller.

9. California privacy rights

If you reside in California, you have additional rights under the CCPA and the CPRA: the right to know which categories and specific data we collect; the right to deletion, subject to applicable legal exceptions; the right to correction; the right to opt out of sale or sharing - we do not sell or share personal data for cross-context behavioral advertising - ; and the right to limit the use of sensitive personal information, which we do not use or disclose beyond permitted purposes. To exercise them, write to privacy@trusteed.xyz. We respond within 45 days.

10. Automated decisions and Trust Score

We compute a Trust Score for every store registered on the platform. It's a numeric value reflecting the store's operational quality that AI agents use to decide whether to start a transaction with it. The system applies exclusively to registered merchants, not to end buyers or their personal data.

The calculation is deterministic and fixed-weight: it doesn't use machine learning to infer patterns. Every recalculation applies the same formulas to the same input data and produces the same result. There's no inferred profile or predictive model, only objective operational metrics.

Factors and weights

What this table explains, and what it does not. These twelve components are the operational signals we collect from your store, and they are the breakdown the API publishes. Today they are not, on their own, the formula behind the number: the published overall score is computed by the v4.1 engine, while the per-component breakdown is still the v2 one. The public response declares this itself in its engines field, and we say it here rather than let the table look like an explanation of the figure. It is a transitional state we are closing; while it lasts, the individualised Art. 22 explanation is provided on request, with the detail of the calculation actually applied to you.

Effects on your store's status

The score is recalculated periodically and automatically determines the store's operational status:

The transition to SUSPENDED happens automatically, without prior human intervention. We state this expressly because a significant share of the platform's merchants are natural persons - sole traders and micro-businesses - for whom this decision falls within the scope of Art. 22 GDPR.

What scale this is. The thresholds above are on a 0-1 scale. The methodology used to compute the score - v4.1, four pillars - is documented at Trust Score, which publishes it on a 0-100 scale: the 0.30 threshold on this page is 30 on that one. The 12-factor table in this section is the v2 engine's operational breakdown, not an input to the v4.1 calculation published today as the overall figure; that page documents the v4.1 methodology in force, which is what actually produces the number.

Your rights (Art. 22 GDPR)

• Obtain a detailed explanation of how your Trust Score was calculated and which factors had the greatest impact.
• Challenge the decision if you believe the score doesn't reflect your store or that the data used is incorrect.
• Request human review of the score by the Trusteed team.
• Request correction of erroneous operational data that is affecting your score.

How to exercise these rights

Write to privacy@trusteed.xyz with the subject "Trust Score review" and your store's identifier or domain, or use the platform's contact form. Response time: one month from receipt of the request, extendable by up to two further months where the request is complex. If we need that extension we will tell you, with reasons, within the first month, as required by Art. 12.3 GDPR.

11. Platform integrations: data we access

When you connect an e-commerce platform we access only the data needed to operate your MCP store.

• Shopify (Admin REST API, scopes read_products, read_inventory, write_checkouts): store metadata, product catalog, and product count. We do not access end-customer data.
• WooCommerce (REST API v3): system status and product catalog. We do not store end-buyer data.
• PrestaShop (native WebService API): store name, product listing, and version for technical compatibility. We do not access buyers' personal data.
• Odoo (JSON-RPC): company name, product catalog, and version. We do not access buyers' personal data.
• Magento (REST API v1): store metadata and product catalog. We do not access buyers' personal data.

Across all platforms, connection credentials are encrypted with AES-256-GCM and permanently deleted if you disconnect your store.

12. Payment providers

When you accept payments through Trusteed, transactions are processed by third parties. Stripe (Stripe, Inc.) processes card payments and acts as a data processor on our behalf; their privacy policy is available at stripe.com/privacy. PayPal (PayPal Holdings, Inc.) processes PayPal payments and acts as an independent data controller with respect to the buyer's transaction data; their privacy policy is available at paypal.com/privacy.

We do not store card numbers, CVV codes, or any sensitive authentication data within the meaning of PCI DSS. Payment tokens used in agent-initiated transactions are processed through Stripe Connect Direct Charges on the merchant's connected account: funds go directly to the merchant and never pass through Trusteed.

What is deployed and what is in use. The two paragraphs above describe how we handle payment data when a payment happens, and that is their purpose: to settle the allocation of responsibilities under the GDPR before there is any traffic. Today there is none. No merchant on the platform has a payment processor configured, so neither the Stripe path nor the PayPal one has settled anything; PayPal is additionally dormant and has no production credentials. We say so here because the rest of the site already does — the signed capability registry publishes the state of every rail — and this page cannot be the only one describing, in the present tense, a flow of funds that does not exist. Per-rail state, verifiable: /.well-known/trusteed-capabilities.json.

12 bis. WebMCP bridge telemetry

If you install the optional WebMCP bridge snippet on your storefront, that snippet sends anonymous operational diagnostics to POST /api/v1/webmcp/telemetry. It is bridge diagnostics, not analytics: it tells us whether the browser is using the standard's native path or the polyfill, and where tool calls fail.

What is sent: the bridge mode (native or polyfill), the polyfill version, the event type, the invoked tool name — checked against a closed allowlist —, an error code and a latency in milliseconds. Your merchant identifier travels in a header and is turned into an HMAC hash on our server before storage; the plain identifier is not persisted. The user agent is truncated to browser and major version before being stored.

What is NOT sent: cookies or browser storage contents, shopper identifiers of any kind, tool argument values, cart contents, prices or product identifiers, or any personal data. Retention: 7 days for raw events, 90 days for daily aggregates, purged by scheduled jobs.

About IP addresses: any HTTP request delivers them to the server, and this one is no exception — saying they are 'not sent' would not be accurate. They are used transiently as part of the key that rate-limits how often the snippet can post (together with your hashed merchant identifier) and are not stored alongside the event or anywhere else.

The snippet suppresses itself entirely when the browser sends Do Not Track or Global Privacy Control. And it is optional: every server-side capability works without it. The machine-readable declaration, field by field, is at /.well-known/agent-policy.json → dataPrivacy.webmcpBridgeTelemetry. This section was added on 1 September 2026: an external audit found the call by reading the shipped snippet itself, because no surface declared it. The design was already the one described above; what was missing was saying so.

13. Your rights and how to exercise them

Under Arts. 15 to 22 GDPR you have the right to access, delete, correct, export, or object to the processing of your personal data. If you're a customer of a store that runs on Trusteed, you can submit a rights request at any time by writing to privacy@trusteed.xyz. We respond within one month of receipt, extendable by up to two further months for complex requests, telling you so with reasons within the first month (Art. 12.3 GDPR).

Withdrawing consent

Where the legal basis for a processing activity is your consent — web analytics and commercial communications — you may withdraw it at any time, and withdrawing is as easy as granting. Analytics is managed from the "Manage cookies" button in the footer of every page and from the Cookie Policy. Commercial communications, from the unsubscribe link in every message. Withdrawal does not affect the lawfulness of processing carried out before it (Art. 7.3 GDPR).

Data Protection Officer

We have not appointed a Data Protection Officer, and that is not an oversight: there is a formal, documented assessment against the three grounds in Art. 37.1 GDPR and Art. 34 LOPDGDD, and none of them is met — we are not a public authority, our operations do not require large-scale regular and systematic monitoring, and none of the active processing activities involves special categories under Art. 9. If that changes, we will appoint one and publish it here. For any data protection matter, the channel is privacy@trusteed.xyz.

Lodging a complaint with the supervisory authority

If you believe the processing of your data does not comply with the law, or you are unhappy with our response, you have the right to lodge a complaint with the Spanish Data Protection Agency (AEPD, C/ Jorge Juan 6, 28001 Madrid — www.aepd.es), the competent supervisory authority given our establishment in Spain. You do not need to contact us first, though it is usually faster.

14. Processing activities, legal bases, and retention

A summary of what we process data for, under what legal basis, and for how long. Where a fixed period cannot be set, we state the criteria that determine it, as Art. 13.2.a GDPR allows.

Account and store configuration

• Purpose: registering you, authenticating you, and running the MCP store you contract.
• Legal basis: performance of the contract (Art. 6.1.b GDPR).
• Categories: contact identifiers, access credentials, configuration, and encrypted platform credentials.
• Retention: while the account is active. After closure, only what is needed to handle liabilities arising from the contract, until the corresponding limitation periods expire. Platform credentials are permanently deleted when you disconnect the store.
• Recipients: our infrastructure providers and, for the data detailed in the next block, anyone — person or agent — who queries the public directory.

Public merchant directory

• Purpose: so that AI agents and people can find your store. It is the point of the service: a store that does not appear in the directory is not discoverable by an agent.
• What is published: the store's identifier and name, its verification level, its Trust Score, and its MCP endpoint. It is served signed (JWS in the response's X-JWS-Signature/X-JWS-Kid headers, not inside the JSON body) at /.well-known/merchant-index.json and on the directory page, without authentication: the recipient is the public at large.
• Legal basis: performance of the contract (Art. 6.1.b GDPR). Listing happens when a production store is registered and is inherent to the service contracted; it is not an optional processing activity we could separate from the rest.
• Why this is personal data: a significant share of merchants are natural persons — sole traders and micro-businesses — and the Trust Score reflects the operational quality of their activity. We declare it as a processing activity of its own rather than treating it as a technical detail of the product.
• Retention and removal: while the store is active. Publication stops when it is deactivated or the account is closed. If you have questions about your presence in the directory, write to privacy@trusteed.xyz.

Buyer data in checkout flows

• Purpose: completing the order and leaving an auditable record of the transaction.
• Legal basis: here we act as the merchant's processor (Art. 28 GDPR); the legal basis is determined by the merchant, who is the controller.
• Categories: contact and shipping data tied to an order or session. We do not process card numbers, CVV, or sensitive authentication data.
• Retention: buyer data is kept as long as needed to complete the flow and, beyond that, for the period the merchant sets as controller: that is not our decision to make. Separately we keep the transaction evidence (trust receipt), which contains no personal data in the clear: the buyer's email and address travel in it as HMACs, so the evidence proves the transaction happened without retaining the underlying data. That is pseudonymization, not anonymization — as long as the key used to generate the HMAC exists, the data is in principle reversible by comparison, and remains subject to GDPR, including the storage-limitation rule of Art. 5.1.e. The key is generated and held by a managed HSM (AWS KMS); it never leaves it in the clear and we cannot extract it. To that evidence we apply an internal floor of 10 years to cover the strictest commercial and accounting retention period in the EU — not an obligation imposed on us by any rule — and a hard ceiling of 12 years from the key's last rotation, after which a monthly scheduled job destroys the key inside the HSM. From that point reversal is no longer possible even for us, and the evidence becomes anonymous in the proper sense.
• Recipients: the merchant and any payment providers involved (see section 12).

Payments

• Purpose: processing payment for the transaction.
• Legal basis: performance of the contract (Art. 6.1.b) and accounting and tax legal obligations (Art. 6.1.c).
• Recipients: Stripe, Inc. as our processor and PayPal Holdings, Inc. as an independent controller. Details in section 12.
• Retention: the applicable accounting and tax limitation periods.

Audit and security logs

• Purpose: investigating incidents, preventing fraud, and being able to evidence what each agent did to your store.
• Legal basis: legitimate interest in platform security (Art. 6.1.f). You may object on grounds relating to your particular situation; we then assess whether our compelling grounds override it.
• Retention: webhook events are purged after 90 days. Logs tied to transaction evidence follow the period in the row above.

WebMCP bridge telemetry

• Purpose: diagnosing the optional WebMCP bridge snippet a merchant can install on its storefront — whether the browser is using the standard's native path or the polyfill, and where tool calls fail.
• Legal basis: legitimate interest in keeping the integration working and diagnosing compatibility failures (Art. 6.1.f GDPR). It is an optional capability the merchant chooses to install, and the shopper's browser can disable it by sending Do Not Track or Global Privacy Control.
• Categories: technical bridge diagnostics (mode, version, event type, tool name, error code, latency), a merchant identifier hashed with HMAC on our server, and, transiently, your IP address as part of the rate-limiting key (not stored alongside the event). No shopper data. Full detail in section 12 bis.
• Retention: 7 days for raw events, 90 days for daily aggregates, purged by scheduled jobs — the same period as section 12 bis.

Website analytics

• Purpose: measuring site usage to detect errors and improve the interface.
• Legal basis: your consent (Art. 6.1.a GDPR and Art. 22.2 LSSI-CE). Without consent it does not run.
• Recipients and transfers: Google Ireland Ltd., with possible transfer to Google LLC in the United States under the EU–US Data Privacy Framework and standard contractual clauses.
• Retention: 2 years for GA4 cookies; 24 months for the record of your consent choice. Details in the Cookie Policy.

Public audit report

• Purpose: keeping a contact tied to the audit you run at /audit so we can answer your questions about it. The report opens on the page itself as soon as you ask for it: we do not email it to you.
• Legal basis: steps taken at your request prior to entering into a contract (Art. 6.1.b GDPR). You leave us your email inside a request you opened yourself, so we can follow it up with you. It is not consent, so it is not withdrawn as such: what you can do at any time is ask us to delete it (Art. 17).
• Categories: your email, which is the only required field, and — if you fill it in — your name. The form asks for nothing else. We do not store your IP address or your browser alongside that data.
• Marketing is a separate box: there is a second checkbox, unticked and on its own, for product news. The report is shown whether or not you tick it, and ticking the first does not tick the second. If you do tick it, we also record the date and the exact version of the wording you accepted, so we can evidence what you said yes to.
• Retention: 12 months from the moment you request the report. Your email is tied to the analysis it unlocks, so it is deleted along with it.
• Recipients: no one beyond our infrastructure providers (section 15).

Sites the audit analyses

• Purpose: running the analysis requested for a web address, and being able to compare it with earlier analyses of the same domain.
• What we store: the address analysed, the domain, the platform detected, the score, and the technical signals read from the site's public pages. None of it is asked of anyone: it comes from reading what the site already publishes without authentication.
• Legal basis: our legitimate interest in providing the tool we are asked for and in measuring the quality of the engine behind it (Art. 6.1.f). You may object on grounds relating to your particular situation.
• Why this can be personal data: anyone can analyse someone else's site — we do not check that whoever types the address owns it — and on the domain of a sole trader or a micro-business the result speaks to the quality of a natural person's activity. It is the same reasoning we apply to the public directory, and we declare it the same way rather than treating it as a technical detail.
• Who can see the report: it is not published or indexed anywhere, but whoever holds the audit identifier can read it without identifying themselves. If your site was analysed and you want the analysis deleted, write to privacy@trusteed.xyz.
• Retention: we keep analyses for no more than 12 months. If you unlocked the report by leaving your email, that email is tied to the analysis and is deleted along with it.

Contact forms

• Purpose: answering what you write to us and following up the conversation you start.
• Legal basis: steps taken at your request prior to entering into a contract (Art. 6.1.b GDPR).
• Categories: name, company, email, and the message you write; if you fill them in, role, technical stack, and website, plus the form answers (platform, volume, problem, channel). We also store the language and which page you wrote from.
• They are not used for marketing: the form does not ask for that permission, so we do not have it. If we ever ask, it will be in a box of its own, like the one on the audit.
• Retention: we keep this data for no more than 24 months from the moment you write to us.
• Recipients: no one beyond our infrastructure providers (section 15).

Commercial communications

• Legal basis: your consent, or the legitimate interest under Art. 21.2 LSSI-CE where a prior contractual relationship exists and the products are similar.
• Where the addresses come from: two places and no others. The product-news checkbox on the audit report, ticked separately from the one that unlocks the report; and existing customers, for products similar to the ones they have. We do not buy lists or obtain them from third parties.
• Retention: until you unsubscribe or withdraw consent and, in any case, no more than 12 months from the moment you left us your email on the audit, even if you never unsubscribe: that email is deleted together with the analysis it is tied to.

Whether providing data is mandatory

Account and configuration data are necessary to provide the service: without them we cannot register you or run your store. The email for the audit report is voluntary and, as things stand, conditions nothing: the full report is shown in full without us asking for your email. The tool does support a mode in which the full report sits behind the email; if we ever turn it on, the audit page itself will say so before asking you for it, and that would be the whole consequence of withholding it: you keep the partial report, and never lose access to any other part of the service. Analytics and commercial communications are entirely voluntary, and declining has no effect on the service.

15. Sub-processors and international transfers

Until now this list was emailed to whoever asked for it. Here it is, and it is exhaustive as of this revision: if we engage a new sub-processor, it appears in this section before it processes any data. Every entry was checked against the actual infrastructure on August 31, 2026 — not against an internal register.

Infrastructure

• Arsys (Spain, EU) — hosting for the public site, the merchant panel, and a SECOND deployment of the API with its own production database. That database is independent from the Railway one, not a replica: it holds accounts, store configuration, and the transaction evidence of the merchants homed on that deployment. Until September 3, 2026 this entry described only the site hosting; that omission is what this correction fixes. As the provider is in the EU there is no international transfer.
• Railway Corp (entity in the United States) — the platform running one deployment of the API with ONE of the two production databases (the other sits on Arsys infrastructure, above). It is the sub-processor with the broadest access: that database holds accounts, store configuration, buyer data from checkout flows, and transaction evidence. All of it is stored and processed in the Netherlands (EU): the database, the cache, and the services that query them all sit in the same European region, checked service by service on September 1, 2026. The transfer that remains is not one of location but of access — the provider is a US entity with the technical ability to reach what it hosts — and it relies on standard contractual clauses (Decision 2021/914, Module 2).
• Amazon Web Services (United States, us-east-1 region) — key management service (KMS) that cryptographically signs trust receipts. It receives the receipt content to be signed, in which the buyer's email and address travel as HMACs and not in the clear. It has no access to the database or to any other processing activity. The transfer relies on standard contractual clauses (Decision 2021/914, Module 2).

Payments and analytics

• Stripe, Inc. — card payment processing, as a processor on our behalf. Details in section 12.
• PayPal Holdings, Inc. — not a sub-processor of ours: it acts as an independent controller for the buyer's transaction data. Listed here so the list does not mislead by omission. Details in section 12.
• Google Ireland Ltd. — website analytics, only with your consent, with a possible transfer to Google LLC in the United States under the EU–US Data Privacy Framework and standard contractual clauses. Details in section 14 and in the Cookie Policy.

On what we do NOT use, because a sub-processor list is also read for what is missing: there is no session-recording tool, no third-party product analytics, and no external help-desk provider — the ticketing system runs on our own infrastructure. And although the conversational assistant is deployed on third-party models, no provider key is configured in production today, so no data is sent to them (see section 5).