Skip to main content

Privacy and data handling

Metatate Cloud governs how data is used without becoming a copy of that data. This page describes exactly what the platform reads, stores, sends, and deletes. The security page covers the boundaries that enforce it.

What Metatate reads from your systemsDirect link to What Metatate reads from your systems

Connectors are metadata-first. Sync workers read schema metadata — databases, schemas, tables, columns, and their types — using a closed set of metadata-focused discovery queries. Metatate never copies production rows into the catalog and never enforces anything inside your platforms.

You decide what is visible. Every connector has an explicit sync scope: a new connector starts with nothing selected, there is no sync-everything action, and anything outside the saved scope is filtered out at the worker before it can be persisted or classified.

Classification works from that metadata first: deterministic pattern rules over names and types propose data types, sensitivity, and PII flags. Where sample-based classification is used, samples are read inside the isolated worker boundary and pass through a redaction step before any AI-assisted call. What gets stored is the resulting label — data type, sensitivity, PII flag, source, and confidence — never a raw value; the classification records are metadata-only by construction, and manual decisions always take precedence over automated ones.

What Metatate storesDirect link to What Metatate stores

Workspace state in Metatate's managed Postgres consists of:

  • Catalog metadata — the structure of what you synced, plus classifications, collections, and scenario curation. Each successful sync produces a fresh current catalog state; a failed or partial sync is never promoted as current.
  • Policies — the canonical policies your team authors, with their versions and review history.
  • Deployment publications and served decisions — the published instruction state that MCP answers are read from.
  • Audit events — an append-only, member-readable activity log of workspace actions, with closed payload shapes that must never contain secrets, credentials, raw provider payloads, or customer PII beyond intended display fields.
  • Workspace records — memberships, roles, settings, and subscription state.

Not stored: your production rows, and connector credentials in any application table — credentials live by reference in a managed secrets vault, decrypted only inside sync workers, never shown again after entry.

What leaves the platformDirect link to What leaves the platform

  • To model providers: nothing without redaction. AI assistance runs server-side with provider keys isolated from the app, and customer data passes a redaction step before any model-provider call.
  • To your platforms: nothing is pushed back. Connector traffic is read-only metadata discovery, and the MCP tools are read-only and advisory — they never write to your systems, and answers about missing or conflicted published state are returned as typed answer states rather than invented decisions.
  • To Stripe: payment processing is delegated to Stripe on Stripe-hosted pages. Card data never touches Metatate; Metatate keeps only the subscription state needed to know your plan.

RetentionDirect link to Retention

Audit-event retention depends on your plan: 30 days on Free, unlimited on paid plans — see Plans and limits. The activity log is append-only for members; workspace members cannot edit or delete audit rows, and events past a finite plan window are removed by a platform maintenance operation, never by member action.

Everything else — catalog metadata, policies, publications, decisions — is kept while your workspace uses it: catalog state is superseded on each successful sync, and publications are replaced when you publish a new deployment.

Removing dataDirect link to Removing data

  • The sample estate is fully removable. Loading the AcmeCloud sample provisions tagged artifacts, and removing it deletes exactly those artifacts — the sample connectors and their catalog entries, classifications, collections, custom types, policies, and the demo publication with its served decisions. Load and remove are admin/owner actions and are idempotent.
  • Connectors can be archived. Archiving is refused while a test or sync is in flight, and an archived connector can no longer run either — its metadata stops updating from that point.
  • Credentials can be rotated and destroyed. Rotation overwrites the stored secret in place, so the previous value is gone. Vault entries are destroyed through an audited, server-side-only operation; no path exports, re-displays, or returns a stored credential on the way out.