Sicherheit, die Sie nachprüfen können.Belegt, nicht behauptet.
Was ein Sicherheitsfragebogen abfragt, steht hier — mit Status. Was wir nicht haben, steht auch hier.
Wir starten in Kürze — sichern Sie sich einen der ersten Plätze.
Sicherheit je Organisation
Zwei-Faktor-Pflicht, IP-Allowlist, Sitzungsdauer, SSO und SCIM — Einstellungen, die der Owner setzt und das Audit-Log festhält.
Die Sicherheitseinstellungen einer Organisation: Zwei-Faktor-Pflicht, SSO, SCIM, IP-Allowlist und Sitzungsdauer, alle eingeschaltet; nur der Owner ändert sie.
Audit-Log ohne Inhalte
Wer wann was geändert hat: Rollen, Freigaben, Einstellungen. Nie ein Chat, nie eine Datei.
Das Audit-Log einer Organisation: vier Einträge mit Zeit, Person und Aktion — Rolle geändert, Agent freigegeben, Souveränitätsstufe gelockert, Verbindung erlaubt; nie Inhalte.
Was gilt — mit Status
Jede Zeile ist eine Aussage, die wir im Produkt belegen können. „Aktiv“ heißt live für jede Organisation; „Intern“ heißt: gemacht, aber ohne externen Nachweis.
Mandantentrennung und Berechtigungen
- Jede Route, Aktion und jedes Werkzeug läuft durch eine zentrale Berechtigungsprüfung — keine verstreute LogikAktiv
- Row-Level-Security in der Datenbank trennt Organisationen zusätzlich auf DatenbankebeneAktiv
- Admins sehen nie Chat-Inhalte ihrer Mitglieder — nur aggregierte NutzungAktiv
- Es gibt keinen „Als Nutzer ansehen“-ModusAktiv
Identität und Zugang
- Zwei-Faktor-Authentifizierung je Person; org-weite Pflicht durch den OwnerAktiv
- Single Sign-on über SAML und OIDCAktiv
- Automatisches Anlegen und Sperren von Konten über SCIM 2.0Aktiv
- IP-Allowlist, Sitzungsdauer von 1 Stunde bis 30 Tagen, org-weites AbmeldenAktiv
- Audit-Log der Organisation: Rollen, Freigaben, Einstellungen — nie InhalteAktiv
- Rate-Limits auf Anmeldung und Schlüssel, fail-closedAktiv
Verschlüsselung und Betrieb
- TLS auf jeder VerbindungAktiv
- Speicherung verschlüsselt beim Hoster; Backups zusätzlich clientseitig mit AES-256Aktiv
- Point-in-Time-Backups, täglich, 14 Tage — mit wöchentlichem automatischem WiederherstellungstestAktiv
- Sicherheits-Header (HSTS, Framing-Verbot, Content-Security-Policy) per Test erzwungenAktiv
- Verfügbarkeits-Monitoring und selbst gehostetes Fehler-Tracking — keine US-DiensteAktiv
- Notbremsen: Wartungsmodus, Generierungs-Stopp, globaler AusgabendeckelAktiv
Löschung, Daten, Vertrag
- Hard-Delete: einzelne Chats sofort, Konten sofort, Organisationen nach 30 Tagen vollständigAktiv
- Aufbewahrungsfristen pro Organisation, nächtlich durchgesetztAktiv
- Datenexport der eigenen Chats, Dateien und Notizen als JSON, Markdown und ZIPAktiv
- Wir trainieren keine Modelle auf KundendatenAktiv
- Auftragsverarbeitungsvertrag mit namentlicher Subprozessoren-Anlage und WiderspruchsfristAktiv
Lieferkette und Prüfung
- Abhängigkeits- und Container-Scans wöchentlich und bei jeder ÄnderungAktiv
- Software-Stückliste (SBOM) je BuildAktiv
- Secret-Scan in der Build-PipelineAktiv
- Penetrationstests gegen eine Wegwerf-Instanz vor jeder größeren Änderung — durch unsIntern
KI-spezifisch
- Deterministische Prüfschicht an den Vertrauensgrenzen: fremde Inhalte aus Dateien, Websuche und Werkzeugen sind Daten, nie AnweisungenAktiv
- Werkzeug-Allow-Lists je Verbindung und je Automatisierung, beim Anlegen festgeschriebenAktiv
- KI-Nutzungsrichtlinie, Freigabe-Lebenszyklus für Agenten und KI-SystemregisterAktiv
- Kennzeichnung KI-erzeugter Inhalte nach Art. 50 Abs. 2 KI-VO — in der Datei, nicht nur im BildAktiv
- Souveränitätsstufe je Organisation, Wechsel nach oben nur durch den Owner mit ProtokollAktiv
Aktiv: live in der Plattform · Intern: durch uns, ohne externen Nachweis
Was wir nicht behaupten
Ein Trust Center ist nur so viel wert wie seine Lücken. Diese hier kennen wir.
- Keine ISO-27001-Zertifizierung
- Kein SOC-2-Bericht
- Kein externer Penetrationstest — unsere Tests sind intern und haben für einen Einkäufer keine Beweiskraft; ein externer Test ist der geplante nächste Schritt
- Kein SIEM und keine Anomalieerkennung — Monitoring ja, Sicherheitsanalytik in Echtzeit nein
Wenn eine dieser Lücken für Ihre Beschaffung entscheidend ist, sagen Sie es uns — wir antworten mit dem Stand, nicht mit einer Zusage.
Wie wir an Sicherheit arbeiten
Vier Regeln, die für jede Änderung gelten — auch für kleine.
- Klasse statt Zeile: Ein behobener Fehler wird als Fehlerklasse im ganzen Code gesucht und unmöglich gemacht
- Jede Regel hat einen Wächter: Typsystem, Test oder Build-Gate — eine Regel ohne Wächter ist ein Wunsch
- Belegen statt behaupten: Jede Sicherheitsaussage hat eine Fundstelle oder einen ausgeführten Test
- Keine Inhalte in Logs, Berichten oder Tickets — auch nicht im Fehlerfall
Sicherheitsfragebogen?
Wir beantworten Ihren Fragebogen mit dem Stand, der hier steht — und schicken auf Wunsch AVV, Subprozessoren-Liste und Löschkonzept mit.
Fragebogen einreichenBereit, Ihre KI-Infrastruktur nach Europa zu holen?
In wenigen Minuten startklar — Stufe wählen, monatlich kündbar.
Wir starten in Kürze — sichern Sie sich einen der ersten Plätze.