feat: Multi-tenancy support (workspace per organization)

[notyorch]

Overview

Currently TUP operates as a single-tenant system. To position it as a SaaS product, multiple organizations need to be able to use the same deployment with fully isolated data, users, and detection policies.

Problem

• Single shared data store means all events are mixed together
• No concept of "organization" or "workspace"
• Impossible to resell or white-label without this
• API keys are global, not scoped to a tenant

Proposed Solution

Add a lightweight multi-tenancy layer at the tup-manager level using a workspace abstraction.

Data Model

Organization
  └── Workspaces (1:N)
        └── API Keys
        └── Users (N:M)
        └── Events
        └── Detection Policies
        └── Alert Rules

Changes Required

Backend (tup-manager)

• Add organizations and workspaces tables to DB schema
• Scope all events, alerts, and policies to a workspace_id
• Add workspace context to JWT claims
• Add API key scoping: each key belongs to a workspace
• Add /api/v1/workspaces CRUD endpoints
• Add workspace-scoped rate limiting

Frontend (tup-dashboard)

• Workspace switcher in navbar
• Workspace settings page (name, members, API keys)
• Filter all views by active workspace

Infrastructure

• Ensure tup-collector sends workspace_id in event payload
• Update .env.example with DEFAULT_WORKSPACE_NAME

Security Considerations

• Row-level security (RLS) in PostgreSQL to enforce tenant isolation at DB level
• Workspace ID must be validated on every authenticated request
• Super-admin role for platform operators

Acceptance Criteria

• Two workspaces cannot see each other's events
• API key from workspace A rejected by workspace B endpoints
• Workspace creation via API and dashboard both work
• Existing single-tenant deployments migrate cleanly via a script

Priority

🟠 Medium — required before any SaaS / commercial launch