Skip to main content

Data handling

How Tessera protects customer data, consistently with the platform's architecture: encryption everywhere, one project = one isolation unit, and deny-by-default handling of anything the customer has not explicitly approved.

Encryption​

  • In transit: all public endpoints (api.staging.tessera.zone, ingest.staging.tessera.zone, the console, and this docs site) accept TLS 1.2 or newer only; internal service-to-service traffic runs inside a private VPC.
  • At rest: every datastore — object storage, relational databases, the event ledger — is encrypted with customer-managed encryption keys (CMEK) via Cloud KMS. Key rotation is automatic (90-day rotation policy).

Tenant isolation​

A project is the isolation unit. Every storage key, object path, queue message, and database row carries the project_id, and cross-project reads are structurally impossible:

  • Object-storage paths are project-prefixed (projects/{project_id}/…); ledger row keys start with {project_id}#; every relational table with tenant data carries a project_id column with row-level security policies.
  • The authorization layer resolves each credential to exactly one project and environment before any handler runs; storage paths and queries are constructed from that resolved project — never from a request-supplied id.

Credential handling​

  • API keys are stored hashed (SHA-256) and displayed once — at creation. They can be revoked at any time and are scoped to a single project and environment.
  • Connector credentials (warehouse passwords, service-account keys) are envelope-encrypted with Cloud KMS and stored only in the control database — never in code, never in logs, and never in object storage.

Data retention​

Each plan includes a minimum event history:

PlanEvent history
Freeat least 90 days
Proat least 400 days
Enterpriseset by contract (at least 730 days on the listed plan)

Events older than the plan's history are not deleted automatically today: the retention sweeps that would delete them are switched off in every environment. Events are deleted when you delete the entity they belong to or the project.

Deleting a project purges its events, embeddings, models, and derived artifacts after a 7-day grace window. The audit trail, a scrubbed project record, the purge record and entity tombstones are kept by design; see What is retained and why.

Related pages​

Legal documents (Terms of Service, Data Processing Addendum, compliance attestations) are maintained by counsel and linked from your contract; this page describes the engineering controls.