Sicherheit & Fundierung
Vertrauen ist ein Mechanismus,
kein Abzeichen.
Diese Seite liefert die Belege: was das System erzwingt, was es speichert, wer darauf zugreifen kann und was wir noch nicht gebaut haben.
Sicherheitskontakt
support@salewise.co.ukBitte senden Sie Schritte zur Reproduktion. Greifen Sie nicht auf Daten anderer Händler zu und stören Sie den Dienst nicht.
Aktueller Stand
- Keine SOC-2- oder ISO-27001-Zertifizierung.
- Noch kein unabhängiger Penetrationstest.
- Keine Kartendaten gespeichert.
Die Kurzfassung
Vier Aussagen und wo die Belege liegen.
Keine Marketing-Adjektive. Designentscheidungen mit Code dahinter.
01
Das Modell kann keinen Preis festlegen.
Retrieval läuft vor der Generierung. Das Modell wählt aus Kandidaten-IDs; der Server validiert sie und rendert Preis, Bestand und Varianten selbst.
Den Mechanismus lesen02
Zugangsdaten von Anbietern sind im Ruhezustand verschlüsselt.
AES-256-GCM, ein zufälliger IV pro Datensatz und zusätzliche authentifizierte Daten, die jeden Geheimtext an Anbieter, Konto und Integrationsdatensatz binden.
Den Mechanismus lesen03
Keine Kartendaten gelangen zu Salewise.
Es gibt keinen Checkout und keinen PAN-Speicher. Der Kunde entscheidet auf dem Smartphone und zahlt an der vorhandenen Kasse des Händlers.
Den Mechanismus lesen04
Zugriff ist begrenzt, nicht geteilt.
Die Eigentümerschaft einer Filiale wird bei jeder Filialroute geprüft. Zugriffstoken gelten 15 Minuten; Refresh-Token werden gehasht und bei Nutzung rotiert.
Den Mechanismus lesenDurch Konstruktion fundiert
Das Modell wählt aus. Der Server rendert.
Retrieval läuft vor der Generierung. Das Modell wählt aus Kandidaten; der Server rechnet und rendert.
01
Zuerst der Abruf
Der Server ruft passende Produkte aus dem Katalog des Händlers ab, bevor das Modell überhaupt gefragt wird. Das Modell durchsucht nie das offene Web.
02
Das Modell wählt. Der Server rendert.
Preise, Bestand, Varianten und Angebote werden serverseitig aus Katalogdaten gerendert. Eine Zahl im Text des Modells ist nie die Quelle der Wahrheit.
03
IDs werden validiert
Jedes Produkt, das vom Modell ausgewählt wird, muss in der abgerufenen Kandidatenmenge enthalten sein. Ungültige IDs werden verworfen, bevor die Antwort den Kunden erreicht.
04
Ehrliche Ablehnung
Enthält der Katalog keine Antwort, sagt der Assistent das und bietet eine Übergabe an. Ist das Modell nicht verfügbar, sagt der Assistent, dass er nicht antworten kann; der Kunde kann es erneut versuchen oder jemanden vom Personal fragen.
Was das Modell erhält
- Die Frage des Kunden.
- Eine Menge abgerufener Katalogkandidaten.
- Filialeinstellungen und der relevante Richtlinientext.
Was nie an das Modell geht
- Kartendaten oder Zahlungszugangsdaten.
- Passwörter, API-Schlüssel oder den Salewise-Master-Key.
- Ein Tool, das in das POS schreiben kann.
Kontrollregister
Ein Kontrollregister, kein Vertrauenssiegel.
Jede Zeile nennt die Kontrolle, den dahinterliegenden Mechanismus und die Grenze. Wenn ein Fragebogen mehr Details braucht, fragen Sie.
Belegte Antworten
Der Katalog ist die Quelle der Wahrheit.
- Der Server ruft Kandidatenprodukte ab, bevor das Modell läuft. Das Modell darf nur IDs aus dieser Menge wählen. Ungültige IDs werden verworfen; Preis, Bestand, Varianten und Angebote werden serverseitig gerendert. Wenn der Katalog keine Antwort enthält, sagt der Agent das und bietet eine Übergabe an.
Zugangsdaten im Ruhezustand
Geheimnisse sind verschlüsselt, gebunden und versioniert.
- Zugangsdaten von Anbietern nutzen AES-256-GCM mit einem zufälligen 96-Bit-IV pro Datensatz. Zusätzliche authentifizierte Daten binden den Geheimtext an provider:{providerId}:account:{accountId}:credentials, sodass ein in einen anderen Mandanten kopierter Datensatz nicht entschlüsselt werden kann. keyVersion unterstützt die Schlüsselrotation; eine fehlgeschlagene Entschlüsselung schlägt geschlossen fehl, statt ein Geheimnis zurückzugeben.
Salewise-Anfragen
Signiert, nicht nur Bearer.
- Anfragen an die Salewise-Master-API tragen eine HMAC-SHA256-Signatur über Methode, Pfad, Zeitstempel, Nonce und SHA-256 des Bodys. Die Signatur wird in konstanter Zeit verglichen und durch ein Replay-Fenster begrenzt. Der Master-Key liegt serverseitig, wird einmal konfiguriert, im Ruhezustand verschlüsselt und nie an einen Browser zurückgegeben.
Konten und Rollen
Ein Händlerkonto ist kein Server-Admin.
- Sage kennt Händler- und Server-Admin-Rollen. Passwörter verwenden scrypt mit Salts pro Konto. Zugriffstoken laufen nach 15 Minuten ab; Refresh-Token werden als Hashes gespeichert, bei Nutzung rotiert und laufen nach 30 Tagen ab. Einladungen laufen nach 7 Tagen ab und sind an die eingeladene E-Mail-Adresse gebunden.
Mandantentrennung
Eine Filialabfrage ist eine Eigentumsprüfung.
- Jede Filialroute löst die Filiale auf und prüft, ob sie zum authentifizierten Konto gehört, bevor Daten zurückgegeben werden. Repository-Methoden sind nach Konto und Filiale begrenzt, und SQL liegt hinter der Repository-Schicht statt in Route-Handlern.
Kartendaten
Keine Zahlungen, keine PANs.
- Salewise nimmt keine Zahlungen entgegen und speichert keine Kartendaten. Die Kunden-PWA hat keinen Checkout, und die Transaktion bleibt im POS des Händlers. Wir beanspruchen keinen PCI-DSS-Geltungsbereich für Kartenzahlungen, weil wir keine Kartenzahlungen verarbeiten.
Aufbewahrung
Konfiguriert, nicht unbegrenzt.
- Die Referenzbereitstellung ist auf 180 Tage für Sitzungstranskripte und 365 Tage für Ereignisdatensätze konfiguriert, festgelegt über Umgebungsvariablen und den AVV. Händlerspezifische Aufbewahrungsfristen werden im AVV vereinbart; Löschungen erfolgen auf Anfrage. Eine geplante automatische Löschung wird heute nicht zugesagt.
Audit-Trail
Sicherheitsrelevante Ereignisse hinterlassen einen Datensatz.
- Registrierung, Anmeldung, fehlgeschlagene Anmeldung, Einladungen, Setup und Änderungen an Integrations-Zugangsdaten werden in einem Audit-Log erfasst. E-Mail-Adressen werden in Audit-Details gehasht statt im Klartext gespeichert. Das Log ist heute intern; eine Audit-Ansicht für Händler gibt es noch nicht.
Modellgrenze
Das Modell erhält nur das Nötigste.
- Das Modell erhält die Frage des Kunden, abgerufene Katalogkandidaten, Filialeinstellungen und relevanten Richtlinientext. Es erhält keine Passwörter, API-Zugangsdaten oder Kartendaten und hat kein Tool, das in das POS schreiben kann.
„Umgesetzt“ bedeutet, dass die Kontrolle heute im Produkt existiert. Es bedeutet nicht, dass jede Kontrolle unabhängig geprüft wurde. Die Lücke ist unten auf dieser Seite aufgeführt.
Zugangsdaten & Anfragen
Im Ruhezustand verschlüsselt. Im Transit signiert.
Die beiden Mechanismen, nach denen Sicherheitsprüfer zuerst fragen.
Zugangsdaten im Ruhezustand
- Algorithmus
- AES-256-GCM, authentifizierte Verschlüsselung.
- IV
- 12 zufällige Bytes pro Datensatz, niemals wiederverwendet.
- Bindung
- AAD provider:{providerId}:account:{accountId}:credentials. Ein kopierter Datensatz lässt sich nicht entschlüsseln.
- Rotation
- keyVersion in jedem Datensatz; während der Rotation wird der vorherige Schlüssel akzeptiert.
- Fehlerfall
- Eine fehlgeschlagene Entschlüsselung schlägt geschlossen fehl. Es wird nicht mit einem veralteten Geheimnis erneut versucht.
Salewise-Anfragen
Der Master-Key wird einmal während des Server-Setups konfiguriert. Jede Anfrage wird damit signiert; die Signatur ist kein Bearer-Token.
canonical = method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + sha256(body); signature = HMAC-SHA256(masterKey, canonical);
- Wird als X-Sage-Signature mit Zeitstempel- und Nonce-Headern gesendet.
- Vergleich in konstanter Zeit, mit Replay-Fenster.
- Master-Key serverseitig gehalten und im Ruhezustand verschlüsselt.
- Nie an einen Browser zurückgegeben oder in ein Log geschrieben.
Daten, Rollen & Aufbewahrung
Schmale Daten. Begrenzter Zugriff. Ein Datensatz.
Der Assistent muss nicht wissen, wer der Kunde ist, um eine Produktfrage zu beantworten.
Eine Sitzung erfasst
- Eine Sitzungs-ID, den QR-Code und den Gang, in dem sie begonnen hat.
- Die Fragen, Antworten und Empfehlungen.
- Übergabeereignisse und Zeitstempel.
Kein Name, kein Konto und keine Kartendaten. Die Demo verknüpft eine Sitzung nicht mit einem namentlich bekannten Kunden.
Wer darauf zugreifen kann
- Ein Händlerkonto, begrenzt auf die damit verknüpften Filialen.
- Ein Server-Admin für Setup und Anbieterkonfiguration.
- Kein filialübergreifender Zugriff zwischen Händlern über die Filialrouten.
Einladungen sind an eine E-Mail-Adresse gebunden und laufen nach 7 Tagen ab.
Wie lange Daten bleiben
- Sitzungstranskripte: auf 180 Tage konfiguriert.
- Ereignisdatensätze: auf 365 Tage konfiguriert.
- Händlerspezifische Bedingungen: im AVV festgelegt.
Löschungen erfolgen auf Anfrage. Eine geplante automatische Löschung wird heute nicht zugesagt.
Audit-Ereignisse
Registrierung, Anmeldung, fehlgeschlagene Anmeldung, Einladungen, Setup und Änderungen an Integrations-Zugangsdaten werden in einem Audit-Log erfasst. E-Mail-Adressen werden in Audit-Details gehasht statt im Klartext gespeichert. Das Log ist heute intern; wir stellen es nicht als Audit-Ansicht für Händler dar.
Attribution
Der Datensatz muss einem Audit standhalten.
Ein zugeordneter Verkauf ist entweder exakt oder modelliert. Der Händler sieht, welcher Fall vorliegt und warum.
Deterministisch
Ein Einlösecode, der von der Sitzung bis zum Verkauf mitgeführt wird. Konfidenz 1,0. Modelliert: falsch. Der Verkauf wird direkt zugeordnet.
Modelliert
Ein Verkauf in derselben Filiale innerhalb eines Zwei-Stunden-Fensters, der empfohlene Artikel enthält. Ein Konfidenzwert wird gespeichert, auf 0,92 begrenzt, und die Zuordnung wird überall, wo sie berichtet wird, als modelliert gekennzeichnet.
Exakte Treffer sind exakt. Modellierte Treffer werden überall als modelliert gekennzeichnet, wo sie berichtet werden. Das Abonnement ist die einzige Gebühr, und die Attribution wird nicht als Umsatz dargestellt.
Ehrliche Grenzen
Was wir nicht behaupten.
Vertrauen lässt sich leichter prüfen, wenn die Lücken benannt sind.
Wenn ein Fragebogen etwas von dieser Liste verlangt, sagen Sie es.
Wir verlieren lieber den Auftrag, als darum herum zu antworten.
- 01
Wir haben heute keine SOC-2- oder ISO-27001-Zertifizierung.
- 02
Wir haben heute keinen unabhängigen Penetrationstest und kein Sicherheitsaudit abgeschlossen.
- 03
Wir beanspruchen keinen PCI-DSS-Geltungsbereich für Kartenzahlungen, weil wir keine Kartenzahlungen verarbeiten.
- 04
Im aktuellen Produkt trainieren wir kein gemeinsames Modell mit dem Katalog oder den Gesprächen eines Händlers.
- 05
Kein KI-System ist risikofrei. Fundierung reduziert Erfindungen; es ersetzt weder die Prüfung durch den Händler noch Übergaberegeln.
- 06
Wir betreiben heute keine geplante automatische Aufbewahrungslöschung; Löschung ist ein operatives Verfahren nach dem AVV.
- 07
Unser Audit-Log ist intern und nicht als Audit-Ansicht für Händler verfügbar.
- 08
Wir versprechen auf dieser Seite kein Service-Level; jede Verfügbarkeitszusage steht im Bestellformular.
Verantwortungsvolle Offenlegung
Wenn Sie glauben, eine Schwachstelle gefunden zu haben, kontaktieren Sie support@salewise.co.uk mit ausreichenden Details zur Reproduktion. Bitte greifen Sie nicht auf Daten anderer Händler zu, stören Sie den Dienst nicht und veröffentlichen Sie nichts, bevor wir reagieren konnten.
Sicherheitsfragen
Stellen Sie die unbequeme Frage.
Sicherheitsfragebögen, Auftragsverarbeitungsverträge (AVV) und Architekturfragen sind willkommen. Wir beantworten, was wir haben, und sagen, was wir nicht haben.