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 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 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.
• Decision records — a durable, citable record of every authorize_use and validate_query_context answer: the normalized inputs, the decision or verdict, the rules it cited, the purpose that was stated, and an actor snapshot. These are what makes an answer explainable months later.
• Access requests and exceptions — the review workflow: an agent's request, the steward's resolution, and any granted exception with its scope and expiry.
• 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.

Free text an agent sends

Three MCP inputs are free text an agent writes: the use description on authorize_use and validate_query_context, the sql on validate_query_context, the on_behalf_of delegation label, and the note on request_access. All four are handled the same conservative way.

By default none of them is stored. Decision records hold only normalized, redacted evidence — the canonical asset, scenario, purpose, and transfer context. A decision record never contains your use text, and it never contains your SQL. What it stores of a query instead is a fingerprint: a stable hash of the evaluation, not of the query text. explain_why therefore cannot leak raw content, because the raw content is not in what it reads.

Raw text is stored only if you turn it on. Your workspace has two privacy switches — one for raw use text and delegation labels, one for raw SQL — and both default to off. When enabled, raw content goes into a separate protected table readable only by workspace admins and owners. It is never returned by any MCP tool, and request_access reports note_recorded: false when the switch is off, so an agent is told the truth about whether its note survived.

on_behalf_of is recorded as a presence flag always — that a delegation was claimed — and as raw text only under the same switch. It is never echoed into any answer, and it is decision-neutral: no evaluator reads it.

Notes are pruned. Recorded request and resolution notes are deleted after 90 days. The workflow rows and audit events — the durable record of what was asked and decided — are never touched by that prune.

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 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.

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.

Recorded request and resolution notes are pruned after 90 days, independently of your plan. Access requests themselves carry a 30-day lifetime and are reported as expired past it; granted exceptions carry their own expiry, at most 90 days.

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 data

• The sample estate is fully removable. Loading the Customer 360 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.