Die Anmeldung nutzt Supabase Auth (GoTrue) mit JWT-Sitzungen. Tokens werden über den Supabase-SSR-Client in HTTP-only-, Secure-, SameSite-Cookies gespeichert. Die Anmeldung über Google oder Apple erfolgt über OAuth 2.0 / OIDC; wir sehen niemals Anbieterpasswörter.

Passwörter (bei der Anmeldung mit E-Mail/Passwort) werden mit bcrypt zu branchenüblich empfohlenen Kosten gehasht. Wir protokollieren oder übertragen niemals Klartext-Passwörter.

Sensible Aktionen (Passwortänderung, Kontolöschung) können eine erneute Authentifizierung oder einen einmaligen E-Mail-Code erfordern. Verdächtige Aktivitäten lösen Rate Limits aus und können eine Kontoüberprüfung auslösen.

Der gesamte öffentliche Verkehr läuft ausschließlich über HTTPS. Marketing-Website und Web-App: TLS-Terminierung durch das Edge von Vercel und Cloudflare. API und Auth: TLS-Terminierung durch unseren Caddy Reverse Proxy mit automatisierten Let's Encrypt-Zertifikaten; Cloudflare proxyt davor (Full-Strict-Modus).

Strikte HSTS ist mit preload-tauglicher max-age aktiviert, und die Header X-Content-Type-Options, Referrer-Policy und Permissions-Policy werden auf den von uns ausgelieferten Antworten gesetzt.

Daten im Ruhezustand liegen auf verschlüsselten Hetzner-Volumes in Deutschland. Datenbankzugriffe erfordern authentifizierte Zugangsdaten mit minimalen Berechtigungen.

Von Nutzern hochgeladene Dateien werden in einem privaten Supabase Storage-Bucket gespeichert; signierte URLs sind kurzlebig und auf den Arbeitsbereich des anfragenden Nutzers beschränkt.

Der Produktionsserver (Hetzner, Falkenstein) läuft auf Ubuntu LTS mit UFW, das standardmäßig sämtlichen eingehenden Verkehr ablehnt; nur die Ports 22 (SSH), 80 und 443 sind öffentlich erreichbar. SSH erfolgt ausschließlich per Key.

Interne Dienste (PostgreSQL, Embeddings, DECIMER, Supabase) binden innerhalb ihrer Container an 127.0.0.1 und sind für andere Dienste nur über ein privates Docker-Bridge-Netzwerk erreichbar; sie sind nicht im öffentlichen Internet exponiert.

Der Reverse Proxy (Caddy 2) leitet api.cheemly.com an die NestJS API und auth.cheemly.com an das Supabase Kong Gateway weiter. Cloudflare sitzt davor zur DDoS-Abwehr und Edge-Filterung.

Container-Images werden aus der GitHub Container Registry (GHCR) bezogen; das Deployment erfolgt über einen signierten GitHub Actions Workflow, der die Images überträgt und ein kontrolliertes `docker compose up -d` auf dem Server auslöst.

Die Trennung der Arbeitsbereiche wird auf Anwendungsebene erzwungen: Jede API-Anfrage erfordert ein gültiges Supabase-JWT, die Benutzerkennung wird serverseitig extrahiert, und Datenbankabfragen filtern nach dieser Kennung, sodass Nutzer nur auf ihre eigenen Threads, Dateien, Embeddings, Literaturhinweise, Lernsitzungen und Berichte zugreifen können.

Die CORS-Allowlist ist auf https://cheemly.com (Produktion) und den konfigurierten Marketing-Ursprung beschränkt.

Eingaben werden mit class-validator (NestJS-DTOs) und Pydantic (FastAPI) validiert, was viele Klassen von Injektionen verhindert.

Geheimnisse liegen außerhalb der Versionskontrolle in Umgebungsdateien, die auf dem Produktionsserver auf root beschränkt sind, mit Dateimodus 600. Der GitHub Actions Deploy-Key ist auf die Produktions-VM beschränkt und rotierbar.

Jede chemische Antwort durchläuft vor Auslieferung an den Nutzer eine deterministische Python-Prüfung: SMILES werden mit RDKit geparst, Atombilanzen werden für Reaktionen ausgeglichen, IUPAC-Namen werden über OPSIN hin- und zurückgewandelt, und Zitate werden gegen offene wissenschaftliche APIs aufgelöst.

Wenn die Prüfung fehlschlägt, wird die Antwort erneut angefordert oder als „geringes Vertrauen“ markiert; wir versenden niemals stillschweigend eine halluzinierte Struktur.

ASCII-Art-Strukturen sind per Prompt-Regel verboten und werden vom Critic erkannt; das Modell wird gezwungen, eine echte, mit RDKit gerenderte Struktur neu zu erzeugen.

Alle Zahlungsdetails (Kartennummer, CVC, Bankzugangsdaten) werden von Stripe verarbeitet, einem nach PCI-DSS Level 1 zertifizierten Anbieter. Cheemly speichert nur Abonnementstatus, Tarif, Rechnungsmetadaten sowie die Stripe-Kunden-/Abonnement-Kennungen.

Webhook-Ereignisse von Stripe werden vor der Verarbeitung mit dem Webhook-Signaturschlüssel verifiziert. Die Abrechnungsabgleichung wird zu Auditzwecken protokolliert.

Betriebsprotokolle erfassen Fehler, Latenz, fehlgeschlagene Jobs, Authentifizierungsereignisse und Kontingentabrechnung. Personenbezogene Daten werden in Protokollen minimiert; vollständige Prompt-Inhalte und Dateiinhalte werden nicht routinemäßig protokolliert.

Authentifizierungsereignisse speichern die IP-Adresse, den User-Agent und einen geparsten Geräte-Fingerprint, damit Nutzer überprüfen können, „wo ich angemeldet bin“.

Wir führen ein internes Aktivitätsprotokoll für sicherheitsrelevante Ereignisse (Anmeldung, Abmeldung, Passwortänderung, Datei-Upload, Thread-Erstellung, Tarifwechsel). Nutzer können über privacy@cheemly.com eine Kopie ihres eigenen Aktivitätsprotokolls anfordern.

PostgreSQL wird nach einem täglichen rotierenden Zeitplan gesichert. Backups werden verschlüsselt und auf einem separaten Hetzner-Volume aufbewahrt.

Ziel der Wiederherstellungszeit (RTO): 4 Stunden für eine vollständige Datenbankwiederherstellung. Ziel des Wiederherstellungspunkts (RPO): 24 Stunden.

Wir führen regelmäßig Wiederherstellungsübungen durch und betreiben eine separate Staging-Umgebung für nicht zerstörerische Tests.

Jeder Agent erhält einen Guardrail-Prompt: Moll gibt niemals den Namen des zugrunde liegenden Modells oder Anbieters preis, lehnt fachfremde Anfragen ab und verweigert Arbeitsabläufe, die gegen die Richtlinie zur akzeptablen Nutzung verstoßen.

Der Deep-Research-Modus erfordert vor der Ausführung eine ausdrückliche Nutzerbestätigung; Planung, Abruf und Synthese erfolgen in Phasen, die der Nutzer beobachten und abbrechen kann.

Kontingente werden serverseitig erzwungen; Clients können den Zähler nicht umgehen.

Wir folgen einem dokumentierten Incident-Response-Prozess: erkennen, eindämmen, beseitigen, wiederherstellen, benachrichtigen und eine Nachbereitung durchführen.

Wenn eine Verletzung des Schutzes personenbezogener Daten voraussichtlich ein Risiko für die Rechte der Nutzer mit sich bringt, benachrichtigen wir die zuständige Aufsichtsbehörde innerhalb von 72 Stunden (Art. 33 DSGVO) und, wenn das Risiko hoch ist, die betroffenen Nutzer unverzüglich (Art. 34 DSGVO). Art. 12 Abs. 5 KVKK wird mit demselben 72-Stunden-Ziel behandelt.

Die Benachrichtigungen enthalten, was geschehen ist, welche Daten betroffen sind, welche Maßnahmen ergriffen wurden und empfohlene Schritte für die Nutzer.

Sicherheitsforscher sind willkommen. Bitte senden Sie eine E-Mail an security@cheemly.com mit Reproduktionsschritten, betroffenen URLs, Auswirkungsbewertung und Kontaktinformationen. Eine maschinenlesbare Zusammenfassung wird zudem unter /.well-known/security.txt veröffentlicht.

Bitte greifen Sie nicht auf Daten anderer Nutzer zu, verändern, löschen oder exfiltrieren Sie diese nicht; führen Sie keine zerstörerischen Tests, Spam, Phishing, Social Engineering oder Denial-of-Service-Angriffe durch. Wir bestätigen gültige Meldungen innerhalb von 5 Geschäftstagen und streben an, kritische Probleme innerhalb von 30 Tagen zu beheben. Derzeit betreiben wir kein bezahltes Bug-Bounty-Programm; auf Wunsch nennen wir Forscher in den Release Notes.

Gutgläubige Forschung nach dieser Richtlinie wird von uns nicht zum Gegenstand rechtlicher Schritte gemacht.

Cheemly ist darauf ausgelegt, die für einen kleinen KI-Produktbetreiber relevanten Verpflichtungen aus DSGVO, UK GDPR, türkischem KVKK, Schweizer FADP und CCPA/CPRA zu erfüllen.

Wir verfügen derzeit nicht über Zertifizierungen nach SOC 2, ISO 27001 oder HIPAA. Enterprise-Kunden, die formelle Drittanbieter-Bescheinigungen benötigen, können ihre Anforderungen mit sales@cheemly.com besprechen.

Wenn Sie einen Auftragsverarbeitungsvertrag, eine exportierbare Liste der Unterauftragsverarbeiter, eine Sicherheitsfragebogen-Antwort oder eine Folgenabschätzung für Übermittlungen benötigen, wenden Sie sich bitte an legal@cheemly.com.