Tenant & workspace

Prometheus is multi-tenant. Two levels of isolation matter:

1. Tenant — the billing account. One per organisation. Owns API keys, members, and a Postgres row-level-security identifier.
2. Workspace — a single indexed codebase inside a tenant. Tenants commonly have one workspace per monorepo or per service group.

Data model

tenant (1) ── (N) workspace (1) ── (N) file ── (N) symbol ── (N) embedding
       │                       │
       └── (N) api_key         └── (N) index_run

Every row in every table carries tenant_id. RLS policies on Supabase enforce that an API key scoped to tenant_id = T cannot see rows from any other tenant — not via the worker, not via the MCP server, not via direct Postgres if a key leaked.

API keys

Each API key is scoped to exactly one tenant and grants access to all of that tenant's workspaces. Per-workspace scoping is on the roadmap (Phase 4) for customers who want CI-only keys.

Keys are 32-byte secrets, prefixed prom_live_ (production) or prom_test_ (staging tenants). The worker hashes them with Argon2id before lookup — cleartext never hits the database after issuance.

Workspace creation

During the private beta, workspaces are created by us. You send the GitHub URL and we provision the workspace_id. Self-service workspace creation arrives with the dashboard (Phase 2.9).

RLS verification

The Supabase migration 0001_initial.sql ships explicit CREATE POLICY statements for every table. The integration tests in packages/context-mcp/tests/supabase-e2e.test.ts round-trip an insert under two distinct SET LOCAL request.jwt.claim.tenant_id identifiers and assert cross-tenant reads return zero rows. The test suite runs on every CI build — an RLS regression breaks the pipeline before deploy.