[Feature] Systematic tenant data isolation review before v1.0

[Polliog]

Feature Description

Conduct a systematic review of the entire codebase to verify that every data access path is correctly scoped to the tenant (organization, project) it should be. Document the findings, fix any gaps discovered, and add automated tests that lock in the invariants for future development.

Problem/Use Case

Logtide is multi-tenant by design — multiple organizations and projects share the same database. Cross-tenant data leakage is the worst class of bug a system like this can have: it's a privacy and compliance failure, and it destroys trust permanently. The cost of finding such a bug post-1.0, with real users in production, is dramatically higher than finding it now.

Coverage today is good but not exhaustively audited. Some paths predate the multi-tenancy model and may have implicit assumptions that no longer hold. Some new code paths may have been added without consistently propagating organization scoping. The honest answer to "are we sure we're tenant-safe everywhere?" is "mostly, but we haven't checked systematically".

Proposed Solution

A structured audit with deliverables:

1. Inventory of all data access paths. Every Kysely query, every reservoir call, every BullMQ producer/consumer, every cache key. Categorized by whether it's tenant-scoped, intentionally global, or unclear.
2. Per-path verification. For each tenant-scoped path, confirm that the organization (and where applicable, project) id is part of the WHERE clause / cache key / job payload. Fix anything missing.
3. Test coverage for isolation invariants. Add integration tests that create two organizations with similar data and assert that operations performed as one org never return or affect the other. These tests live in tests/isolation/ and run on every CI build.
4. A documented "tenant safety" checklist for contributors. Every new endpoint, query, or background job must satisfy these rules. Add a PR template section that requires confirming this.
5. Static analysis where feasible. Consider an ESLint rule or a custom check that flags Kysely queries against tenant tables that don't include organization_id in their WHERE clause. Imperfect but valuable as a tripwire.

Alternatives Considered

• Assume the codebase is already correct. Probably mostly true, but "probably mostly" is the wrong posture for this class of bug. Doing the audit is cheap insurance.
• Defer until a customer reports a leak. That's the worst possible time to find one. Rejected.
• Adopt row-level security in PostgreSQL. Defense in depth that's worth considering long-term, but it's a significant change and complementary to (not a substitute for) auditing the application layer. Out of scope for this issue.

Implementation Details (Optional)

Concrete checklist for each data access path:

• Does the query include organization_id (and project_id where relevant) in the WHERE clause?
• If the query joins multiple tables, is the scoping enforced at every level, not just the outer query?
• If the query updates or deletes, is the scoping verified before execution and not just trusted to filter results?
• If results go to a cache, does the cache key include the organization id?
• If the operation is enqueued as a background job, is the organization id in the payload, and does the consumer re-validate it instead of trusting the payload blindly?
• If an id is taken from a URL parameter or request body, is it verified to belong to the requesting org before being used?
  The output of this audit should be a markdown document checked into the repo (docs/security/tenant-isolation-audit.md) listing every path and its status. This becomes a living document — new code paths are added to it as they land.

The integration test suite should specifically cover:

• Search/query paths returning logs
• Alert evaluation reading logs and historical data
• Pipeline execution
• Dashboard data loading
• API key validation (an API key for org A must not authenticate against org B)
• Webhook delivery (a webhook configured by org A must not fire for org B's events)
• Audit log queries
• Usage/metering queries

Priority

• Critical - Blocking my usage of Logtide
• High - Would significantly improve my workflow
• Medium - Nice to have
• Low - Minor enhancement
  (Marked Critical because it's a v1.0 gating concern: shipping multi-tenant software without an isolation audit is not acceptable.)

Target Users

• All multi-tenant deployments (which is most of them)
• Operators with compliance obligations who need to attest to tenant isolation
• Maintainers — the test suite and audit document protect every future change from accidentally regressing isolation

Contribution

• I would like to work on implementing this feature