tidyr

Security at Tidyr

The full picture: how your data is isolated, encrypted, kept in-region, and handled by AI — stated plainly, including what's live today and what's on the roadmap.

Dedicated Project Isolation

Every customer gets a dedicated cloud project — your own warehouse, your own IAM, your own audit log. Isolation is structural, enforced by the cloud platform itself, not by a filter clause in application code.

Your Own Encryption Keys

Per-customer encryption keys (CMEK) from day one. Every dataset, storage bucket, and secret in your project is created under your key. TLS 1.3 in transit, AES-256 at rest.

Region Pinned by Policy

UK customers run in our London cell; US customers in our US cell. Residency is enforced by organization policy on the cloud platform and negative-tested — not promised in a document.

Credentials Stay Home

Data ingestion is self-hosted inside your region. OAuth tokens for your source systems never touch a third-party ELT service.

Access Control

Role-based access enforced server-side on every route, with row-level security in the application database. Least-privilege service accounts scoped to your project.

Monitoring & Response

Monitoring for suspicious activity, documented incident response, and breach notification within at most 72 hours of awareness.

Clean Offboarding

Leave, and we delete your project — warehouse, keys, jobs, logs, everything in it. Deletion certification available on request.

Privacy by Design

We never sell or share your data, and nothing you connect is used to train models — by us or our model providers.

The detail
01

Architecture: a dedicated cloud project per customer

  • Every customer's data lives in a dedicated Google Cloud project: their own BigQuery warehouse, storage, service accounts, pipeline jobs, and audit logs. There is no shared warehouse with per-row tenant filtering.
  • Isolation is enforced by the cloud platform's IAM boundary, so the blast radius of any incident is limited to a single customer project by design.
  • Each project is created by an automated provisioning factory: project, APIs, encryption keyring, service accounts, secrets, buckets, datasets, and pipeline jobs — every encrypted resource created under the customer's own key from the first minute.
02

Data residency & enforcement

  • Two cells are live today: a United Kingdom cell in London (europe-west2) and a United States cell (us-central1). A customer's application, database, pipelines, and warehouse all run in their cell's region.
  • Residency is enforced in three layers: a source-code gate that blocks hardcoded regions, a deploy gate that pins each cell's build configuration to its region, and a cloud organization policy that restricts resource locations per cell — verified by negative testing (out-of-region resource creation is denied by the platform).
  • A fully sovereign, non-US tier (non-US providers, no US Cloud Act exposure) is on the roadmap and is built on committed demand.
03

Encryption

  • In transit: TLS 1.2+ (TLS 1.3 preferred) on all public endpoints, HTTPS-only with managed certificates. Internal service-to-service traffic runs over the cloud provider's encrypted network.
  • At rest: all data stores are encrypted (AES-256). Customer warehouse data is additionally encrypted under customer-dedicated CMEK keys in Cloud KMS.
  • Secrets: all credentials, API keys, and tokens live in Google Secret Manager with per-secret IAM and rotation support. No secrets in code, configuration files, or version control.
04

Identity, authentication & access control

  • Customer authentication via Google Cloud Identity Platform: email/password with breach-resistant hashing and Google single sign-on; enterprise SSO (SAML/OIDC, Microsoft/Azure AD) available on enterprise plans.
  • Sessions are short-lived, HttpOnly, Secure cookies that can only be minted within minutes of a fresh authentication — a stolen older token cannot create a new session. Revocation is enforced on sensitive operations.
  • Authorization is role-based (owner / admin / member / viewer), enforced server-side on every API route, with row-level security in the application database.
  • Tidyr-side access to customer projects uses least-privilege service accounts scoped to that project. Human operator access is limited to named personnel via individually-identified accounts and is captured in the customer project's audit logs.
05

Integrations & credential handling

  • Tidyr connects to customer systems (HubSpot, Xero, Intercom, and others) via OAuth using a self-hosted integration broker running inside Tidyr's own infrastructure, in-region. There is no third-party iPaaS or managed ELT vendor holding customer credentials or relaying customer data.
  • Connections use the minimum OAuth scopes required; customers authorize each connection explicitly and can revoke it at any time from the source system or from Tidyr.
  • Webhook endpoints validate signatures, and pipeline jobs run inside the customer's own project.
06

AI features & model data handling

  • No customer data is used to train models — by Tidyr or by its model providers. Model APIs are used in inference-only mode (Anthropic Claude via API; Google Vertex AI for embeddings and in-warehouse AI functions).
  • AI context is strictly tenant-scoped: retrieval, memory, and grounding data are resolved per tenant inside the tenant's own project, subject to the same isolation boundary as everything else.
  • AI-initiated actions are auditable: tool invocations are recorded and surfaced to users, and AI match decisions are written to an append-only decision ledger alongside human decisions.
  • Model inference for LLM features may be processed in the provider's regions (including the US) under contractual safeguards. Customers with strict in-region inference requirements should discuss the sovereign tier.
07

Auditability & data integrity

  • Append-only decision ledger: entity-matching decisions (human and AI) are recorded with actor identity, timestamp, and rationale — never silently overwritten.
  • Application audit logs cover authentication events, team changes, settings changes, data exports, and integration changes, with automated retention cleanup.
  • Infrastructure audit logs run per customer project (admin activity and data access).
  • All production changes ship via version-controlled CI/CD with reviewed pull requests; deployment images are pinned by digest and rolled out with canary verification.
08

Incident response & breach notification

  • Monitoring and alerting on authentication anomalies, pipeline failures, error rates, and infrastructure events, with per-project observability.
  • Documented incident process: detect → contain (revoke credentials, isolate the affected project) → investigate via audit logs → remediate → post-mortem. Blast radius is limited to a single customer project by design.
  • Breach notification without undue delay and within at most 72 hours of awareness, with the information the controller needs for their own regulatory assessment.
09

Business continuity & backups

  • Managed, replicated storage across all data stores: automated database backups with point-in-time recovery, warehouse durability with time-travel, versioned object storage. Backups remain in-region with the primary data.
  • Infrastructure is defined as code (Terraform / Cloud Build), enabling regional rebuild; customer projects are re-provisionable from the same factory that created them.
  • Destructive operations (tenant purge, offboarding) are gated behind explicit human approval with a pre-deletion backup step.
10

Secure development practices

  • All code in version control with mandatory review before merge to production; adversarial security review for auth, tenant-isolation, and data-path changes.
  • 1,200+ automated tests run in CI on the application alone; type-checked codebase; deployment gates on green builds.
  • Parameterized queries everywhere — string interpolation of tenant values into SQL is prohibited by policy and lint gates.
  • No production credentials on developer machines or in repositories; production secrets live only in Secret Manager with per-secret IAM.
11

Subprocessors & international transfers

  • Core subprocessors: Google Cloud (all infrastructure, processed in your cell's region), Anthropic (LLM inference, US, no-training commitment), Resend (transactional email, US), Stripe (billing only). Connected systems like HubSpot or Xero are your own providers, accessed under your authorization — not subprocessors.
  • Where a subprocessor processes data in the US, transfers are covered by Standard Contractual Clauses / the UK IDTA, with supplementary measures: TLS, minimization of what is sent, and no-training commitments. Subprocessor changes are notified in advance per the DPA.
  • Transparency on the US CLOUD Act: Google is a US-headquartered provider, and data hosted in its UK/EU regions remains within reach of lawful US access requests. We state this plainly rather than marketing an EU region as "EU sovereign." Customers for whom this is disqualifying should discuss the sovereign tier.
12

Data rights, retention & deletion

  • Because each customer's data is consolidated in their own project with unified entities, Tidyr can support data subject requests efficiently: locate all records for a person across connected sources, export them, or delete them, on documented instruction.
  • Customer data is retained for the duration of the subscription; derived layers are rebuilt, not accumulated indefinitely.
  • On termination: inventory manifest → customer review → deletion of the customer's dedicated cloud project and all application records. Time-limited backups age out on a fixed schedule. Deletion certification is available on request.
  • Customers can export their data in standard formats at any time; warehouse-level export can be arranged since the warehouse is a dedicated per-customer project.
12

Compliance posture

GDPR / UK GDPR processor obligationsDPA offered with SCCs / UK IDTA
Data residency (UK / US cells)Live
Per-customer project isolation + CMEKLive
Subprocessor list + advance-notice commitmentMaintained
SOC 2 Type IIPlanned — controls operated to SOC 2 standards in anticipation of formal audit
Penetration testingInternal adversarial reviews ongoing; independent external test planned ahead of SOC 2

A signed Data Processing Agreement, subprocessor list, and security questionnaire support are available for customers and prospects — ask via the address below.

Questions or vulnerability reports

Security questionnaires, DPA requests, or responsible disclosure: security@tidyr.ai