La confiance est un mécanisme,
pas un badge.

Réponses ancrées

Le catalogue est la source de vérité.

Le serveur récupère les produits candidats avant l’exécution du modèle. Le modèle ne peut sélectionner que des identifiants de cet ensemble. Les identifiants invalides sont écartés, et le prix, le stock, les variantes et les offres sont affichés côté serveur. Si le catalogue ne contient pas de réponse, l’agent le dit et propose un relais.

Identifiants au repos

Les secrets sont chiffrés, liés et versionnés.

Les identifiants fournisseurs utilisent AES-256-GCM avec un IV aléatoire de 96 bits par enregistrement. Les données authentifiées supplémentaires lient le texte chiffré à provider:{providerId}:account:{accountId}:credentials, de sorte qu’un enregistrement copié vers un autre locataire ne peut pas être déchiffré. keyVersion permet la rotation des clés ; un déchiffrement échoué échoue de façon fermée au lieu de renvoyer un secret.

Requêtes Salewise

Signées, pas seulement porteuses d’un jeton.

Les requêtes vers l’API maîtresse Salewise portent une signature HMAC-SHA256 sur la méthode, le chemin, l’horodatage, le nonce et le SHA-256 du corps. La signature est comparée en temps constant et bornée par une fenêtre anti-rejeu. La clé maîtresse reste côté serveur, configurée une fois, chiffrée au repos et jamais renvoyée à un navigateur.

Comptes et rôles

Un compte commerçant n’est pas un administrateur serveur.

Sage dispose de rôles commerçant et administrateur serveur. Les mots de passe utilisent scrypt avec un sel par compte. Les jetons d’accès expirent après 15 minutes ; les jetons de rafraîchissement sont stockés sous forme de hachages, renouvelés à chaque utilisation et expirent après 30 jours. Les invitations expirent après 7 jours et sont liées à l’adresse e-mail invitée.

Isolation des locataires

La consultation d’un magasin est un contrôle de propriété.

Chaque route magasin résout le magasin et vérifie qu’il appartient au compte authentifié avant de renvoyer des données. Les méthodes du dépôt sont limitées par compte et par magasin, et le SQL reste derrière la couche de dépôt plutôt que dans les gestionnaires de routes.

Données de carte

Aucun paiement, aucun PAN.

Salewise ne prend pas de paiements et ne stocke pas de données de carte. La PWA acheteur n’a pas de paiement en ligne, et la transaction reste dans le POS du commerçant. Nous ne revendiquons pas de périmètre PCI DSS pour les paiements par carte, car nous ne traitons pas de paiements par carte.

Conservation

Configurée, pas indéfinie.

Le déploiement de référence prévoit 180 jours pour les transcriptions de session et 365 jours pour les enregistrements d’événements, définis par l’environnement et le DPA. La conservation propre au commerçant est convenue dans le DPA, et la suppression est traitée sur demande. Aucune purge planifiée n’est revendiquée à ce jour.

Piste d’audit

Les événements liés à la sécurité laissent une trace.

L’inscription, la connexion, les échecs de connexion, les invitations, la configuration et les modifications d’identifiants d’intégration sont écrits dans un journal d’audit. Les adresses e-mail sont hachées dans les détails d’audit plutôt que stockées en clair. Le journal est interne aujourd’hui ; il n’existe pas encore d’écran d’audit pour le commerçant.

Périmètre du modèle

Le modèle reçoit le minimum nécessaire.

Le modèle reçoit la question de l’acheteur, les produits candidats extraits du catalogue, les paramètres du magasin et le texte des politiques applicables. Il ne reçoit ni mots de passe, ni identifiants API, ni données de carte, et il ne dispose d’aucun outil capable d’écrire dans le POS.

« Construit » signifie que le contrôle existe aujourd’hui dans le produit. Cela ne signifie pas que chaque contrôle a fait l’objet d’un audit indépendant. Les écarts sont listés en bas de cette page.