Wie SilentChat Mandanten voneinander trennt — auch in der KI
Jede Zeile, die einem Kunden gehört, trägt eine Mandanten-ID, und jede Abfrage filtert danach — auch die Vektorsuche, aus der die KI ihre Antworten zieht. Die Mandanten-ID kommt aus dem Anmelde-Token, nie aus der Anfrage. Integrationstests prüfen Zugriffe über Mandantengrenzen, und unsere eigenen Prüfungen haben Lücken gefunden, die wir vor dem Start geschlossen haben.
Das Grundprinzip
SilentChat ist eine Mehrmandanten-Anwendung: Alle Kunden teilen sich die Datenbank, getrennt wird logisch. Deshalb trägt jede Zeile, die einem Kunden gehört, eine Mandanten-ID, und jede Abfrage schränkt darauf ein.
Die ID stammt aus dem Anmelde-Token — bei API-Zugriffen aus dem API-Schlüssel — und wird von der Authentifizierung gesetzt. Eine Anfrage kann sie nicht mitschicken und damit auch nicht fälschen.
Für Abfragen nach einer einzelnen ID gibt es Bausteine, die den Mandantenfilter gleich in die Abfrage legen, statt das Ergebnis nachträglich zu vergleichen. Ein nachträglicher Vergleich ist die Stelle, die man am leichtesten vergisst.
Die KI sieht nur Ihre Inhalte
Die KI beantwortet Fragen aus Ihrer Wissensdatenbank. Dafür zerlegt SilentChat Artikel in Abschnitte, berechnet für jeden einen Vektor und speichert beides in der Tabelle knowledge_chunks — mit der Mandanten-ID in jeder Zeile. Die Ähnlichkeitssuche filtert in der Abfrage selbst auf den Mandanten, bevor sie nach Nähe sortiert. Das gilt auch für die Rückfall-Suche ohne Sprachfilter.
Der Systemprompt wird bei jeder Antwort aus der KI-Einstellung des jeweiligen Mandanten neu gebaut; einen mandantenübergreifenden Zwischenspeicher dafür gibt es nicht. Jede KI-Nutzung wird mit Mandant, Funktion und Kosten gebucht.
Wie wir das prüfen
- Integrationstests greifen über HTTP mit einem zweiten Mandanten auf fremde Daten zu und erwarten „nicht gefunden“ — für Wissensdatenbank, Produkte, Feedback, Tickets, Workflows und weitere Bereiche.
- Echtzeit-Kanäle prüfen, ob ein Nutzer einen Raum betreten darf.
- Audits suchen gezielt nach Abfragen, die Einträge nur über ihre ID laden.
Was es nicht gibt: einen externen Penetrationstest und ein Bug-Bounty-Programm. Beides steht auf unserer Liste.
Was wir gefunden haben
Unsere eigenen Prüfungen haben vor dem Livegang mehrere Stellen gefunden, an denen einzelne Routen Einträge nur über ihre ID luden — unter anderem im Roadmap-Modul, bei Kommentaren zu Feature-Wünschen und bei der Zuordnung von SLA-Richtlinien zu Tickets. Alle Stellen wurden behoben, bevor SilentChat öffentlich wurde, und Regressionstests halten sie fest.
Die Lehre daraus: Eine Liste bekannter Fundstellen ersetzt nicht die Suche nach dem Muster. Wo eine Stelle war, lohnt sich der Blick ins Nachbarmodul.
Wenn Sie eine Schwachstelle finden, schreiben Sie uns bitte an security@silentchat.de.