Konzept

Mandantenmodell.

Jeder knowmind-Account erhält einen eigenen Arbeitsbereich. Die Trennung der Arbeitsbereiche 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 diese Trennung 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 — Mandantenfilter auf jedem Knoten

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

Speicher — eigener Bucket pro Arbeitsbereich

Datei-Uploads landen in getrennten S3-Buckets (MinIO) je Arbeitsbereich. Vektor-Index in pgvector hat tenant_id als Filter-Spalte. Audit-Logs in Langfuse sind mit dem jeweiligen Arbeitsbereich getaggt.

Was Arbeitsbereiche nicht teilen

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

Was Arbeitsbereiche teilen können

Die Modellierungs-Wahl unterstützt mandanten­übergreifende Funktionen, ohne dass Daten leaken können: Marktplätze für Memory-Packs (Vorlagen, keine Daten) und Eval-Goldsets, die als Code committed sind.