Security

Metatate Cloud's security model is a set of enforced boundaries, each backed by tests that must stay green for a change to ship. This page walks through them one at a time. Metatate never claims a boundary it cannot demonstrate, and it does not describe internal mechanisms here — only the guarantees they produce.

Workspace isolation

Every workspace-owned table carries its workspace's ID, and row-level security at the database layer is the isolation boundary. Members can read only the workspaces they belong to; a query from one workspace against another workspace's rows comes back empty. Isolation is exercised by dedicated negative tests — cross-workspace reads and writes are required to fail — and every write goes through a server-side operation that re-verifies your role before touching data.

The MCP server adds its own layer. Each tool call resolves the workspace entirely from the bearer token and pins every read to that workspace; auth fails closed. A reference to another workspace's asset is indistinguishable from an asset that does not exist, so the API cannot be used to probe what other workspaces contain.

MCP access tokens

Workspace access tokens for the MCP server are designed to be safe to operate:

• Hashed at rest. Only a cryptographic hash is stored. The platform cannot re-display a token, and nothing member-readable exposes the hash.
• Shown once. The plaintext is returned exactly once at issuance and never persisted.
• Revocable, with optional expiry. Admins and owners issue and revoke tokens; issuance and revocation are recorded in the workspace activity log.
• Uniform unauthorized. A missing, malformed, expired, revoked, or unknown token produces the same unauthorized response — the API does not reveal which check failed.

Rate limits and quotas are enforced before any tool work runs, and errors use a closed, redacted set of codes that never include raw SQL, token material, credentials, or connector details. See Connect an agent for token setup.

Connector credentials

Credentials for your data platforms are stored by reference in a managed secrets vault — application tables hold a reference, never the secret. Decryption happens only inside isolated sync workers; credentials are never returned to the browser and never re-shown after entry. Connector configuration visible in the app excludes secret material entirely. You can rotate a credential at any time — rotation replaces the stored secret in place and is recorded in the activity log — but no flow displays or exports one.

Network egress

Outbound connector traffic is guarded before any connection is made:

• Private-address refusal. Connections to private, loopback, link-local, multicast, and unspecified addresses are refused. For connectors where you supply a hostname, the name is resolved and checked before dialing, and this refusal is never relaxed in production.
• Closed allowlists for cloud APIs. Connectors for cloud-vendor APIs talk only to a closed allowlist of the vendor's own endpoints, over verified TLS. Endpoint overrides embedded in an uploaded credential file are ignored in favor of the fixed vendor endpoints.

The AI boundary

AI assistance runs server-side, in an isolated internal service. Model-provider keys live only there — never in the web app and never in the browser — and customer data passes a redaction step before any call to a model provider. Prompts never carry secrets, credential material, or connector details. AI output is a suggestion, not an authority: AI-assisted classifications are written through the same guarded server-side path as deterministic ones, and manual decisions always take precedence over them.

Payments

Payment processing is delegated to Stripe. Checkout and subscription management happen on Stripe-hosted pages, so card data never touches Metatate. Payment-provider secrets are confined to an isolated billing service that the browser cannot reach; incoming billing events are signature-verified and processed idempotently, and billing logs and audit events never contain card data or raw payment payloads. What your plan entitles you to is decided by Metatate's own records, not inferred from the payment provider.

Roles and least privilege

Every membership has one of four roles — viewer, editor, admin, owner — and they are enforced capability tiers, re-checked server-side on every write, not UI labels:

Capability	viewer	editor	admin	owner
Read the workspace	✓	✓	✓	✓
Author policies, curate the catalog, publish deployments	—	✓	✓	✓
Manage connectors, MCP tokens, members, billing	—	—	✓	✓
Grant owner/admin, change roles, edit workspace settings	—	—	—	✓

A reserved service-account role exists for future machine identities; it is non-grantable — no invitation flow can issue it. Roles are assigned when you create a workspace and invite your team.