Security

Trust & Security

The controls we operate today, where your data lives, and how to reach us about a security concern. Written from the running system, not from intent.

Last reviewed 8 September 2026.

1. Hosting and data residency

  • Google Cloud, single provider. The API (api.dveracity.com), the MCP server, the database (Cloud SQL, PostgreSQL 16) and customer file storage (Cloud Storage) run in the United States, us-east1. The public website is served from the Netherlands, europe-west4.
  • Residency is a per-tenant setting. Each customer organisation is provisioned as its own tenant with its own database and file storage, and the platform records for that tenant its data region, data classification and retention period. us-east1 is the default when no region is requested; a tenant can be provisioned in another Google Cloud region on request. Sovereignty — whose law governs the data — follows the customer's jurisdiction, not the hosting region. See Privacy Policy §4.
  • Encryption. All traffic is TLS in transit, including the connection between the API and the database. Data at rest is encrypted by Google Cloud with Google-managed keys.
  • Storage buckets use uniform bucket-level access (no per-object ACLs); the bucket holding tenant evidence records has public-access prevention enforced.

2. Agent and API access

  • No anonymous access. Every request to the API and the MCP server must carry a credential a human created: an API key from a subscribed account, or an OAuth grant approved on our consent screen. Unauthenticated requests receive 401 before any tool is listed or called.
  • OAuth 2.1 for AI clients (Claude, ChatGPT and other MCP clients): PKCE with S256 is mandatory; dynamic client registration is limited to public clients; every grant passes through a consent screen bound to the registered redirect URL. Access tokens live one hour, refresh tokens thirty days, authorisation codes ten minutes; revoked tokens are kept as an audit record.
  • Least privilege per tool. Each MCP tool and API product requires a specific scope, and a token is granted only the scopes shown on the consent screen. Every MCP tool is read-only against your data; metered tools spend credits, which is a billing event, not a change to your data.
  • Credentials are never stored in the clear. Passwords are bcrypt-hashed; API keys and OAuth tokens are stored as one-way hashes. We cannot recover a key from what we hold.
  • Attribution. Every metered call is recorded with the account or key it was billed to, the connecting client's declared name and version, the endpoint, status and timing. You can see and revoke your keys and connected clients in your dashboard.

3. Tenant isolation

  • Enforced, not advisory. The platform runs with tenant isolation in enforce mode: every data access resolves the caller's tenant first, and a request that cannot be attributed to a tenant is refused rather than served from a shared default.
  • Separate storage per tenant. Each tenant has its own database and its own file-content bucket; one tenant's documents are never written alongside another's.
  • Ingestion is attributed. Data arriving through the messaging layer carries its tenant context end to end, so evidence cannot land in the wrong tenant's ledger.

4. Verification integrity

  • Hash-chained audit trail. Every verification action and status change is written to an audit log in which each entry's SHA-256 hash includes the previous entry's hash, so an inserted, altered or deleted record breaks the chain. The log runs in strict mode: if the audit write fails, the operation is aborted rather than completed unrecorded.
  • Two layers of trust, kept apart. What the platform computed (platform evidence) is recorded separately from what an accredited human verifier concluded (verifier opinion). A platform result is never presented as a verifier's opinion. This separation is a founding rule of the platform and is enforced in production.
  • Signed evidence. Platform evidence records are signed with a key held in Google Secret Manager, never in code or configuration files.
  • Reproducible validation. Standards validation (PACT, Open Footprint sector policies) is evaluated by a policy engine against published, versioned rules, and every response states which checks ran and which could not, so a "valid" result cannot be read without also reading what it was allowed to mean.

5. Secrets, deployment and change control

  • Secrets live in Google Secret Manager — the database password, signing and session keys, the Stripe key and the mail credential — and are injected into the running service at start-up. None are committed to a repository.
  • Deploys are keyless. Production is built and deployed by GitHub Actions using Workload Identity Federation: short-lived, scoped tokens, no long-lived cloud service-account keys held anywhere.
  • Protected main branch on the platform repository: changes land only through pull requests that pass the backend test suite, the frontend build, the policy-rule check and a dependency audit; force-pushes and branch deletion are blocked and the rules apply to administrators too.
  • Production access is limited to the people who operate the service, through Google Cloud IAM with individual accounts.

6. Application security

  • HTTP security headers are set on every response (Helmet); cross-origin requests are allowed only from explicitly configured origins in production.
  • The sign-in cookie is HttpOnly, Secure and SameSite=Strict, and is the only cookie we set. The website runs no analytics or third-party scripts.
  • Requests are traced with OpenTelemetry into Google Cloud Trace and Cloud Monitoring; logs are structured and correlated to the request trace in Cloud Logging. Our operators are alerted on error rates and latency.
  • Payments are handled by Stripe. Card details never reach our systems.

7. Subprocessors

  • Google Cloud — hosting, database, file storage, secrets, logging, telemetry and transactional email relay.
  • Google Vertex AI — extraction and structuring of submitted documents. Google does not use Vertex AI customer inputs to train its models.
  • Stripe — payment processing.

The AI client you connect (Claude, ChatGPT or another MCP client) receives the results of the tools it calls on your behalf; what it does with them is governed by its operator's policies. We do not see your conversation — only the requests that reach us.

8. What we do not have yet

We would rather you learn these here than in a questionnaire.

  • No SOC 2 or ISO 27001 report. The controls above are operated, but they have not been independently attested. We will pursue an attestation when a customer engagement requires one, and the boundary would be small: one API service, one database, one storage layer on Google Cloud.
  • No published penetration test. The MCP server and OAuth flow have been exercised by independent AI-driven test harnesses (including consent bypass and client-registration probes, whose findings were fixed before the Claude connector was approved), but not by a commissioned third-party test.
  • Abuse control is by metering, not throttling. Metered calls are limited by credits and subscription tier; there is no per-IP rate limiter in front of the API today.
  • One default region. Alternative regions are provisioned on request, not self-service.

If your procurement process needs a completed security questionnaire, a data processing agreement, or a walkthrough of any control above, email contact@dveracity.com.

9. Reporting a vulnerability

Email contact@dveracity.com with "Security" in the subject line, or use the contact in /.well-known/security.txt. We acknowledge security reports within two business days and tell you what we found and when it will be fixed. We ask that you do not access, modify or retain other customers' data, do not degrade the service, and give us reasonable time to fix an issue before disclosing it. If we learn of a breach affecting your data we will tell you without undue delay.

See also the Privacy Policy and Support.