Konzept

Mandantenmodell.

Jeder Knowmind-Account ist ein Tenant. Tenant-Isolation ist nicht eine Empfehlung an die Programmierenden, sondern ein technisch erzwungener Zustand auf drei Ebenen.

PostgreSQL — Row-Level-Security

Jede geschäftsrelevante Tabelle trägt eine tenant_id NOT NULL-Spalte. Die Service-Rolle knowmind_app hat NOBYPASSRLS — auch wir können RLS nicht aushebeln. Jede Query läuft in einer Transaktion mit SET LOCAL app.current_tenant_id = <uuid>, die Policy prüft tenant_id = current_setting('app.current_tenant_id'). Vergisst eine neue Route den Filter, sieht sie keine Daten — kein Leak-Risiko.

Neo4j — tenantId auf jedem Knoten

Cypher-Queries werden über einen schmalen Wrapper geschickt, der den tenantId-Filter pflicht-injiziert. Composite-Indizes auf (tenantId, name) sorgen dafür, dass die Filterung performant bleibt.

Speicher — Bucket pro Tenant

Datei-Uploads landen in tenant-getrennten S3-Buckets (MinIO). Vektor-Index in pgvector hat tenant_id als Filter-Spalte. Audit-Logs in Langfuse sind mit tenant=… getaggt.

Was Tenants nicht teilen

• • Memories, Edges, Dokumente
• • Vektor-Embeddings
• • Provider-Keys (BYOK)
• • API-Tokens und Sessions
• • Audit-Trail
• • Settings und Onboarding-Vorlagen

Was Tenants teilen

Die Modellierungs-Wahl unterstützt Cross-Tenant-Funktionen, ohne dass Daten leaken können: Marketplaces für Memory-Packs (Templates, keine Daten) und Eval-Goldsets, die als Code committed sind.