Security overview

The core posture: no customer data to breach

Mock Matrix's most important security property is architectural, not procedural: the platform never ingests real data. There are no uploads of customer records, no customer-dataset PII or PHI processing (the only personal data we hold is your account profile — see the privacy policy), no de-identification pipeline to defend, and no possibility of re-identification — every generated value is sampled from public reference data and pack-authored distributions. The compliance story is provenance ("no real inputs exist"), which is categorically stronger than statistical privacy claims and far easier to audit.

• No dataset-upload features exist, and this is a product invariant: any future "match my schema" capability accepts schemas/DDL only, never rows.
• Generated datasets are still treated as your confidential business fixtures (a scenario spec can reveal test plans), so tenant isolation applies even though the data is synthetic.
• Because no real patients or people exist in the output, generated healthcare-style data contains no PHI by construction. We state this precisely and do not market "HIPAA-compliant data" — the claim is about provenance, not certification.

Synthetic provenance marking

Realism cuts both ways: data that looks like a real business must never be mistaken for one. Every dataset ships with a manifest.json carrying an explicit synthetic-data statement, the spec hash, seed, pack and engine versions, and per-file SHA-256 checksums. Identifiers are generated inside safe ranges (e.g. 555-01xx phone numbers, invalid-by-spec SSN ranges formatted realistically), and an identifier_style knob can switch to visibly fictitious TEST--prefixed identifiers where policy demands it.

Authentication and access

• Sign-in is Google-only (OpenID Connect); Mock Matrix never sees or stores passwords. Sessions are server-side tokens with expiry and can be revoked by signing out.
• API keys are stored hashed, displayed once at creation, and revocable. All API access is bearer-token authenticated and scoped to your organization.
• Downloads use HMAC-signed, short-lived URLs (or presigned object storage URLs), scoped to a single job artifact — links expire and can be re-minted from the API.
• Tenancy: every row is organization-scoped and enforced in the data access layer; artifact storage keys are prefixed per organization.

Infrastructure

• API and generation workers run on Fly.io.
• Metadata lives in Neon (managed Postgres); connections are TLS.
• Artifacts are stored in Cloudflare R2 and the web app is served from Cloudflare Pages, behind Cloudflare's network.
• Secrets live in the platforms' secret stores, never in the repository; logs carry identifiers and hashes, not spec contents or generated data.

Retention and abuse controls

Artifacts are automatically deleted after the plan's retention window (7 days Free, 30 days Pro, 90 days Enterprise), and every plan enforces quotas — concurrent jobs, jobs per day, generated rows per day, and preview rate limits — so a compromised credential has bounded blast radius. Details are on the pricing page.

Responsible disclosure

We do not currently hold formal certifications such as SOC 2; this page, the provenance system, and our disclosure process are the honest current state. If you believe you have found a security issue, email synthetic-data-lab+security@gmail.comwith reproduction details. We will acknowledge reports promptly, keep you informed while we fix the issue, and will not pursue action against good-faith research that avoids accessing other tenants' data or degrading the service.