# Trustvice: architecture and security whitepaper

Version of 8 November 2026. Published by Avonao, Inc., the operator of Trustvice.
Current copy: https://trustvice.com/trust/security-pack

## About this document

This whitepaper describes how Trustvice 360 (the API at `api.trustvice.com`, the MCP server at `mcp.trustvice.com`, the dashboard and the website) is built and protected today. It is written for security reviewers and procurement teams. It describes the service as it runs, not a roadmap, and where a protection is partial it says so.

Each statement carries a reference such as [E4]. Appendix A lists, for every reference, the public document that states it. Where this whitepaper and a legal document differ, the legal document governs: the [Terms of Service](https://trustvice.com/legal/terms-of-service), the [Data Processing Addendum](https://trustvice.com/legal/data-processing-addendum) (DPA), the [Privacy Policy](https://trustvice.com/legal/privacy-policy) and, for Enterprise plans with a signed order form, the [Enterprise SLA](https://trustvice.com/legal/enterprise-sla).

## 1. What the service does

Trustvice 360 is one product made of suites. Where a suite produces evidence, Trustvice issues, signs and stores the receipt itself: a JSON envelope signed with Ed25519 over its RFC 8785 (JCS) canonical form. Anyone holding a receipt and the published public key can verify it offline, without an account and without contacting Trustvice [E1].

Some suites sign facts the caller supplies, others what Trustvice observed; each suite's page says which. A valid signature proves who signed which bytes and that the bytes were not changed; it does not prove that a reported fact is true [E2]. The [trust center](https://trustvice.com/trust#receipts) sets out what a receipt proves and what you still trust us for.

## 2. Architecture and data flow

### 2.1 Components

| Component | What it does | Where it runs |
|---|---|---|
| Website and dashboard | Marketing site, documentation and the customer dashboard | Cloudflare Workers, served from the United States (US West) [E3] |
| Sign-in | Accounts and sign-in through Avonao ID; Trustvice holds no passwords, passkeys or authenticator secrets | Avonao ID, with Trustvice sessions held by Trustvice [E9] |
| API gateway (`api.trustvice.com`) | The front door: authenticates every credential, applies scopes, roles, IP allow-lists and rate limits, resolves the workspace and its data region, and forwards the call | Cloudflare Workers, US West [E4] |
| Regional services | Do the work a suite was asked for, issue and store receipts, meter quota | Cloudflare Workers in each of seven data regions, each with its own database [E4][E5] |
| MCP server (`mcp.trustvice.com`) | Model Context Protocol endpoint for AI agents and clients, with OAuth sign-in | Cloudflare Workers [E6] |
| Signing | Ed25519 signing keys, one per data region | AWS Key Management Service (AWS KMS), in an AWS region paired with the data region [E7] |
| Status | Public status page, incident history, subscriptions | Probes every five minutes [E8] |

### 2.2 The path of a request

1. **Connection.** The caller connects over HTTPS. Cloudflare accepts the connection at the network location nearest the caller [E3][E15].
2. **Authentication at the gateway.** The gateway resolves the credential (workspace API key, personal access token, OAuth access token or dashboard session) to exactly one workspace before any suite code runs. Secrets are stored and compared as SHA-256 hashes, in constant time [E9].
3. **Authorization.** The gateway applies the credential's scopes, the IP allow-list where the organization has set one, and the per-IP and per-account rate limits [E9][E10].
4. **Region resolution.** The gateway reads the workspace's data region and forwards the call to that region's service. If that service cannot be reached, the call fails with `503 workspace_region_unavailable`; an unknown region value fails with `503 workspace_region_unknown`. A call is never answered from another region [E4].
5. **Signed forward.** The workspace and its permissions travel to the regional service in headers signed by Trustvice's own services. Without a valid signature, the service refuses the request, so a request that bypasses the gateway cannot choose a workspace [E11].
6. **Work.** The regional service does the work the suite was asked for and records the facts the receipt will cover, reading and writing only its own region's database. Every query carries the workspace id [E11][E12].
7. **Signing.** The receipt envelope is canonicalised and its bytes are sent to AWS KMS, which returns an Ed25519 signature. The private key never leaves KMS. Until the signature exists, the artifact shows Receipt pending, never an unsigned receipt [E7].
8. **Storage and response.** The signed receipt is stored next to the artifact it belongs to, append-only, for the plan's retention window [E12].
9. **Verification.** Anyone can verify the receipt offline with the public key published at `https://trustvice.com/.well-known/receipt-keys.json` [E13].

### 2.3 MCP

The MCP server is at `https://mcp.trustvice.com/mcp`. Clients sign in with OAuth; the [AI and MCP docs](https://trustvice.com/docs/ai) describe how to connect [E6].

## 3. Signing key custody

- Receipts are signed with one of seven Ed25519 keys, one per data region (`ENAM`, `WNAM`, `WEUR-1`, `WEUR-2`, `NEUR`, `APAC`, `OC`), each held by Trustvice in AWS KMS in that region's paired AWS region [E7].
- AWS documents the KMS hardware security modules as validated to FIPS 140-3 Level 3 [E7].
- The regional service sends the canonical bytes to KMS and receives a signature. It holds a sign-only credential that cannot export a key. No API route returns private key material; the public routes return public fields only [E7].
- **Fail closed.** If KMS is unavailable, the receipt waits as Receipt pending and is retried. The service never falls back to another region's key or to a local key, and never shows an unsigned receipt [E7].
- **Key id.** A receipt holds its key id inside the signed bytes, so it cannot be re-pointed at another key without invalidating it [E1].
- **Publication.** The public key set is served without authentication from `https://trustvice.com/.well-known/receipt-keys.json` and from `https://api.trustvice.com/v1/receipts/keys`. Verifiers are advised to pin the key id and public value in their own records [E13].
- **Rotation** is a manual ceremony, not a schedule. A retired key stays published so existing receipts keep verifying [E13].
- **Write-once copy.** Every hour Trustvice writes the hashes of the closed hour's receipts to an Amazon S3 Object Lock bucket in COMPLIANCE mode, in the same region. It is Trustvice's own bucket and key: it narrows what Trustvice could do quietly, but it is not an independent witness [E12].
- **Stated limits.** There is no key revocation list and no key transparency log today. A compromise would be announced by notice and by a change to the published key set. HSM custody stops a key from being copied; it does not stop whoever can deploy the service from causing it to sign [E7].

The [Key management](https://trustvice.com/legal/key-management) statement gives the detail.

## 4. Data regions and residency

| Region | Code | Signing key in AWS KMS | Storage |
|---|---|---|---|
| US East | `enam` | `us-east-1` (N. Virginia) | Cloudflare location hint |
| US West | `wnam` | `us-west-2` (Oregon) | Cloudflare location hint |
| Europe Central | `weur-1` | `eu-central-1` (Frankfurt) | Cloudflare EU jurisdiction (enforced) |
| Europe West | `weur-2` | `eu-west-1` (Ireland) | Cloudflare EU jurisdiction (enforced) |
| Europe North | `neur` | `eu-north-1` (Stockholm) | Cloudflare EU jurisdiction (enforced) |
| Asia-Pacific | `apac` | `ap-southeast-1` (Singapore) | Cloudflare location hint |
| Oceania | `oc` | `ap-southeast-2` (Sydney) | Cloudflare location hint |

[E5]

- **What is regional.** Receipts and their stored bodies where retained, monthly quota counters, receipt signing and the write-once copy of receipt hashes, and the retention and redaction jobs for that data [E3].
- **What is not regional.** The dashboard, the website, sign-in, sessions and account details, billing, the credential checks at the front door, the control plane and the account audit log, and the public status page are served from the United States (US West) in every case [E3].
- **EU jurisdiction.** For the three European regions the databases are created under Cloudflare's EU jurisdiction, which Cloudflare enforces; Cloudflare chooses the datacenter within the EU, so no city is named for the data. For the other regions the database is created with a location hint, which is a placement request, not a guarantee [E3].
- **Fixed per workspace.** The region is chosen when the workspace is created and never changes. There is no migration between regions [E3].
- **Fail closed, never across regions.** A regional service reads only its own database, and the gateway never answers a call from another region [E4].
- **What crosses regions.** The metadata the gateway needs to authenticate and meter goes to the US; the canonical bytes to be signed go to AWS KMS in the region's paired AWS region, and the hourly receipt hashes to that region's Object Lock bucket. Nothing moves from one data region to another [E3].

## 5. Sub-processors

The current list, with purpose, location, data and transfer safeguards, is published at [https://trustvice.com/legal/subprocessors](https://trustvice.com/legal/subprocessors). It includes, among others, Cloudflare (hosting, databases, CDN, DNS, DDoS protection, email and Turnstile bot protection on forms), Stripe (payments, invoices and tax), Amazon Web Services (AWS KMS receipt signing and the Object Lock copy) and Anthropic (the language model behind Number One, the assistant on the website and in the dashboard) [E19].

New sub-processors are announced at least 30 days ahead, with a right to object and to terminate with a refund [E19]. The published list is authoritative.

## 6. Encryption

- **In transit.** Connections between customers and the service use TLS (HTTPS) [E15]. Traffic between Cloudflare Workers and D1 uses TLS according to Cloudflare's D1 documentation [E20].
- **At rest, provider level.** Customer data is stored in Cloudflare D1. Cloudflare documents that all objects stored in D1 are encrypted at rest with AES-256 [E20]. Trustvice does not manage those storage keys.
- **At rest, application level.** Credentials Trustvice receives (API keys, personal access tokens, session tokens) are stored as SHA-256 hashes, never in clear [E9]. Receipt rows are not encrypted by Trustvice beyond the provider's at-rest encryption.
- **Integrity.** Receipts are signed, so any change to stored evidence is detectable by anyone who verifies it [E1].
- **Passwords.** Trustvice has no passwords or sign-in forms of its own; sign-in is through Avonao ID [E9].

## 7. Access control

### 7.1 Customer access

| Control | As built |
|---|---|
| API keys and tokens | Stored as SHA-256 hashes, shown once and compared in constant time. Keys expire after 30 days, 90 days, a year or never, and rotate with a grace period of 0 to 60 minutes [E9] |
| OAuth (MCP) | OAuth sign-in for the MCP server [E6] |
| Dashboard sign-in | Only through Avonao ID, where users manage passkeys, two-factor codes and recovery codes [E9] |
| Sessions | `HttpOnly`, `Secure`, `SameSite=Lax` cookie, 12-hour lifetime, 30-minute idle timeout [E9] |
| Scopes and roles | Read, write and manage scopes, optionally narrowed to named suites; organization and workspace roles. Checks fail closed [E9] |
| IP allow-lists | Optional per organization. If the allow-list cannot be read the request is allowed (fails open), deliberately, so a database fault cannot lock customers out [E9] |
| Rate limits | 600 requests per minute per IP and 1,200 per minute per account at the gateway [E10] |
| Directory sync (SCIM) | Planned for Enterprise; not available yet |

### 7.2 Tenancy

The gateway, not the caller, decides the workspace. Every read and write carries the workspace id, and a request body naming a different workspace is refused. Separation is logical, in a regional database; there is no separate database per customer [E11].

### 7.3 Trustvice personnel

- Access to production systems and secrets is limited to the personnel who deploy and operate the service, who are bound by confidentiality [E23].
- The signing keys can be used only through the sign-only credential held by the regional services; no person or route can export them [E7].

## 8. Logging and audit

- **Security audit log.** Security-relevant events (sign-ins, key and role changes, denied access) are written to an append-only audit log with the source IP address and user agent [E25].
- **Customer access.** Workspace admins read the workspace audit log in the dashboard [E25].
- **Retention.** The audit log is kept for the life of the workspace and after it, with a person's identifier replaced where erasure is required. Operational logs and rate-limit counters are kept 30 days at most [E26].
- **Receipt changes.** Receipts are append-only; only audited routes (the customer's own deletion, redaction and the plan retention job) can remove or redact one, and each writes an audit event [E12].

## 9. Availability and incident response

- **Status page.** `https://trustvice.com/status` probes the API gateway in each of the seven data regions, the MCP server, OAuth discovery and receipt verification every five minutes. A check that fails or takes over 8 seconds is down; over 3 seconds is degraded; a stale monitor shows no recent data, never green. The page is not signed and is not a service-level agreement [E8].
- **Incidents.** Incidents are posted with updates; customers follow them by email subscription, Atom feed or JSON [E8].
- **Personal data breaches.** The account owner is notified by email without undue delay and in any case within 72 hours of Trustvice becoming aware of a breach affecting customer personal data, with what is known and supplemented as more is learned [E27].
- **Service levels.** Self-serve plans carry no uptime commitment, service credits or support response time. Enterprise plans with a signed order form have the [Enterprise SLA](https://trustvice.com/legal/enterprise-sla): 99.9% monthly uptime for the REST API, the MCP server and receipt issuance, service credits of 10%, 25% or 50%, and support staffed during business hours that acknowledges every Enterprise request within 1 business hour [E28].
- **Independence.** Verifying a receipt needs only the receipt and a public key, so it keeps working when the service does not [E1].
- **Code rollback.** Each service is deployed as a versioned Cloudflare Worker and can be returned to an earlier version; a code rollback does not touch data.

## 10. Vulnerability disclosure

- Report through the form at `https://trustvice.com/security/report` (with contact details or anonymously) or to `security@trustvice.com`. A `security.txt` is published at `https://trustvice.com/.well-known/security.txt` [E30].
- Targets: acknowledgement within 3 business days, initial assessment within 10 business days, updates at least every 14 days, a fix for critical and high severity aimed at 30 days and for lower severity at 90 days. These are targets, not guarantees [E30].
- Good-faith research under the policy is authorised, with safe harbor. A 90-day disclosure window is asked for. There is no monetary bug bounty; researchers are credited on request [E30].

## 11. Backup and recovery

- **Point-in-time recovery.** Receipts and the rest of each workspace's data are stored in Cloudflare's databases in the workspace's region. Cloudflare's point-in-time recovery (D1 Time Travel) lets Trustvice restore those databases to any minute of the last 30 days [E31].
- **No separate copies.** Time Travel is the database recovery mechanism; no other backup copy of the databases is kept [E31].
- **Signing keys.** The signing keys live in AWS KMS and are not exported or backed up by Trustvice. Published public keys keep existing receipts verifiable [E7].
- **Customer copies.** Customers can export their data at no charge. A receipt already handed to someone stays verifiable whatever happens to the service [E33].
- **Commitments.** Trustvice publishes no recovery point or recovery time objective. The [Continuity](https://trustvice.com/legal/continuity) statement describes what stays verifiable if Trustvice stops operating.

## 12. Retention and deletion

- Receipts are kept for the plan window (Free 7 days, Starter 90, Pro 90, Pro+ 90, Team 180, Scale 365, Enterprise custom), then deleted. The write-once copy of the hash stays locked 12 hours longer; a plan with no automatic deletion is locked 7 years [E26].
- Account deletion takes effect after a 30-day grace period; database recovery copies held by the storage provider roll off within a further 30 days [E26].
- Billing records are kept as tax law requires, up to 7 years [E26].

## 13. What is not claimed

- No recovery point or recovery time objective is published.
- No database backup beyond Cloudflare D1 Time Travel is claimed.
- No uptime commitment is made on self-serve plans.
- No monetary bug bounty is offered.
- No dedicated per-customer database or per-customer signing key is part of the published plans.
- No key revocation list, key transparency log, independent witness or third-party timestamp authority exists today. The write-once copy of receipt hashes narrows what Trustvice could do quietly; it is not an independent witness.

Written answers to a reasonable security questionnaire are given within 30 days under DPA section 9 (`privacy@trustvice.com`). Where documentation is not enough, the DPA provides for an audit by an independent auditor once a year, on 30 days' notice, at the customer's cost [E35].

## Appendix A: evidence references

Public documents are at `https://trustvice.com`.

| Ref | Statement | Public document |
|---|---|---|
| E1 | Receipt format, JCS canonicalisation, Ed25519, key id in signed bytes, offline verification | /legal/receipt-practice-statement, /legal/verification |
| E2 | Observed versus reported facts; what a receipt does not prove | /trust#receipts, /legal/receipt-practice-statement |
| E3 | What is regional and what is not; EU jurisdiction vs location hint | /regions |
| E4 | Gateway region routing, fail closed, never across regions | /regions |
| E5 | Seven regions, AWS KMS region per data region | /regions, /trust#data |
| E6 | MCP server and OAuth sign-in | /docs/ai, /docs/authentication |
| E7 | AWS KMS custody, sign-only credential, fail-closed signing, no fallback | /legal/key-management, /trust#keys |
| E8 | Status probes, thresholds, incident subscriptions | /status, /trust#availability |
| E9 | Credentials, hashing, expiry, rotation, scopes, roles, sign-in, sessions, IP allow-lists | /docs/authentication, /trust#access |
| E10 | Rate limits | /trust#access |
| E11 | Tenancy isolation, signed gateway forward | /trust#architecture, /trust#access |
| E12 | Append-only receipts, audited delete and redaction, write-once copy | /legal/privacy-policy, /trust#data |
| E13 | Key publication, rotation as ceremony | /legal/key-management, /trust#keys |
| E15 | TLS between customer and service | /legal/data-processing-addendum (Annex 2) |
| E19 | Sub-processors and change notice | /legal/subprocessors |
| E20 | D1 encryption at rest (AES-256) and in transit (TLS) | Cloudflare: developers.cloudflare.com/d1/reference/data-security/ |
| E23 | Personnel access and confidentiality | /legal/data-processing-addendum (Annex 2) |
| E25 | Append-only security audit log with IP and user agent | /legal/privacy-policy, /docs/api/audit |
| E26 | Retention periods, plan windows, deletion grace, recovery copies | /legal/privacy-policy, /trust#data |
| E27 | 72-hour breach notice | /legal/data-processing-addendum#8-personal-data-breach |
| E28 | Enterprise SLA terms | /legal/enterprise-sla |
| E30 | Disclosure channels, targets, safe harbor, security.txt | /legal/responsible-disclosure, /security/report, /.well-known/security.txt |
| E31 | D1 Time Travel and the absence of other backup copies | /legal/continuity, /legal/data-processing-addendum |
| E33 | Free export, switching, continuity | /legal/data-act, /legal/continuity |
| E35 | Questionnaire and audit rights | /legal/data-processing-addendum#9-audits |