[howethomas]

Adds the strict tenant pack: opt-in SQL that makes row-level security fail closed, a catalog guard that catches an upgrade undoing it, and a REST-level test harness on a throwaway stack.

What it adds

• supabase/strict/: strict_pack.sql, catalog_guard.sql and apply.sh. supabase db push does not read this folder, so nothing changes for a deployment that does not run it.
• tests/tenant-isolation/: PostgreSQL 17 with pgvector and PostgREST 16.2 at pool 4 in Docker, every migration unmodified, HS256 JWTs, and synthetic tenants with a canary each.
• A Tenant isolation workflow with two jobs: strict (catalog guard, then REST shape) and baseline. No npm install; Node 24 runs the TypeScript directly.
• docs/guide/strict-tenant-pack.md, and corrections to docs/guide/debugging-tenant-rls.md and two source comments.

What the pack changes

• One policy per tenant table for authenticated, with no NULL branch. RLS forced.
• get_current_tenant_id() reads the JWT tenant_id claim only. No claim, an empty claim and _quarantine mean no tenant. The session-variable fallback is gone.
• Tenant roles read and delete only. authenticated keeps SELECT and DELETE on the tenant tables and SELECT on views, and executes no VOLATILE function (the write RPCs, plus three read-only helpers declared VOLATILE).
• PUBLIC, anon and authenticated lose TRUNCATE, TRIGGER, REFERENCES and MAINTAIN on every table and view, also by default for tables created later.
• The trigger that refreshes conversation_start after a dialog or attachment delete runs as its owner, so a tenant's delete_vcon still works.
• vcon_tags_scoped, a tenant-filtered view over vcon_tags_mv, owned by the materialized view's owner. Tenant roles lose the materialized view and its refresh functions.
• Twelve search and tag RPCs lose their NULL branch and read the scoped view. search_vcons_by_tags_and_date and its count gain a tenant predicate.
• tenant_id is NOT NULL and never empty on the ten tenant tables.
• Composite keys: each child references its parent by (id, tenant_id).
• authenticated loses vkong.vcons. Service-only functions (exec_sql, the tag refresh, both tenant backfills, vcon_tenant_stamp, release_vcon_from_quarantine and others) are taken back if re-granted.

The apply script refuses, changing nothing, while a tenant table holds a row with no tenant or a child whose tenant differs from its vCon's. A second run changes nothing. It takes the connection string from DATABASE_URL or --url-file and hands the password to psql in PGPASSWORD.

The catalog guard

It fails on all of the above being undone, and on a reachable function that treats the tenant in a NULL-tolerant way: IS NULL, IS [NOT] DISTINCT FROM, COALESCE or NULLIF around it, or a comparison with ''. The guide says what it cannot see.

Behaviour changes for a deployment that applies it

• With the service key and no tenant claim, these return nothing:
  • MCP search_vcons_content, search_vcons_semantic, search_vcons_hybrid, search_by_tags and vcon_aggregate;
  • search_vcons and vcon_search with tags or a dealer filter;
  • vcon_search in keyword, semantic or hybrid mode;
  • REST /vcons/search/content, /vcons/search/semantic, /vcons/search/hybrid, /tags/search, and /vcons with tags.
• With dates and no subject, search_vcons still returns rows but reports a total of 0. Table reads, get_vcon, delete_vcon and the write tools are unchanged.
• No row can be written without a tenant, including by the service key. A save_vcon_batch re-post whose vCon row has no tenant_id fails with a not-null error. TENANT_MODE=writer always stamps one.
• The first apply scans every tenant table under ACCESS EXCLUSIVE locks in one transaction. Apply it in a maintenance window. A store of a few hundred vCons takes well under a second.

Results

Rebased on the writer (#125) and lane (#124) changes: 69 migrations, all applied unmodified.

Command	Result
node tests/tenant-isolation/rest-shape.ts	311 passed, 0 failed
node tests/tenant-isolation/rest-shape.ts --baseline	302 passed, 0 failed, 146 known leaks reproduced
node tests/tenant-isolation/catalog-guard.ts	155 passed, 0 failed

On the unmodified schema the guard reports 129 violations. The baseline run shows the leaks the pack closes:

• SET ROLE authenticated; TRUNCATE empties every table;
• a tenant's insert of another tenant's uuid answers 23505 instead of success;
• a tenant can claim a uuid that the writer later fills with another tenant's content.

Not in this PR

• The log text in src/db/tenant-context.ts still says queries return only NULL-tenant rows. Only comments were changed there; a comment above it says what is true.
• A database session that can SET ROLE authenticated can still LOCK a tenant table it may delete from. PostgREST never issues LOCK. Listed in the guide's known limits.

Test fixtures carry no lawful_basis attachment, on purpose. They are synthetic.

🤖 Generated with Claude Code