Security & grounding
Trust is a mechanism,
not a badge.
This page is the evidence: what the system enforces, what it stores, who can reach it, and what we have not built yet.
Security contact
support@salewise.co.ukInclude reproduction steps. Please do not access another merchant’s data or disrupt the service.
Current posture
- No SOC 2 or ISO 27001 certification.
- No independent penetration test yet.
- No card data held.
The short version
Four claims, and where the evidence lives.
Not marketing adjectives. Design decisions with code behind them.
01
The model cannot set a price.
Retrieval runs before generation. The model selects from candidate IDs; the server validates them and renders price, stock and variants itself.
Read the mechanism02
Provider secrets are encrypted at rest.
AES-256-GCM, a random IV per record, and additional authenticated data that binds each ciphertext to its provider, account and integration record.
Read the mechanism03
No card data enters Salewise.
There is no checkout and no PAN storage. The shopper decides on the phone and pays at the merchant’s existing till.
Read the mechanism04
Access is scoped, not shared.
Store ownership is checked on every store route. Access tokens last 15 minutes; refresh tokens are hashed and rotated on use.
Read the mechanismGrounded by construction
The model selects. The server renders.
Retrieval runs before generation. The model chooses from candidates; the server does the arithmetic and the rendering.
01
Retrieval first
The server retrieves candidate products from the merchant's catalogue before the model is asked anything. The model never searches the open web.
02
The model selects. The server renders.
Prices, stock, variants and offers are rendered server-side from catalogue records. A number in the model's prose is never the source of truth.
03
IDs are validated
Every product the model selects must exist in the retrieved candidate set. Invalid IDs are discarded before the answer reaches the shopper.
04
Honest refusal
If the catalogue does not contain an answer, the agent says so and offers a handover. If the model is unavailable, the assistant says it cannot answer and the shopper can try again or ask a colleague.
What goes to the model
- The shopper’s question.
- A set of retrieved catalogue candidates.
- Store settings and the relevant policy text.
What never goes to the model
- Card data or payment credentials.
- Passwords, API keys or the Salewise master key.
- A tool that can write to the POS.
Control ledger
A control ledger, not a trust badge.
Each row names the control, the mechanism behind it, and where the limit is. If a questionnaire needs more detail, ask.
Grounded answers
The catalogue is the source of truth.
- The server retrieves candidate products before the model runs. The model may only select IDs from that set. Invalid IDs are discarded, and price, stock, variants and offers are rendered server-side. If the catalogue has no answer, the agent says so and offers a handover.
Credentials at rest
Secrets are encrypted, bound and versioned.
- Provider credentials use AES-256-GCM with a random 96-bit IV per record. Additional authenticated data binds the ciphertext to provider:{providerId}:account:{accountId}:credentials, so a record copied to another tenant fails to decrypt. keyVersion supports key rotation; a failed decrypt fails closed rather than returning a secret.
Salewise requests
Signed, not bearer-only.
- Requests to the Salewise master API carry an HMAC-SHA256 signature over the method, path, timestamp, nonce and SHA-256 of the body. The signature is compared in constant time and bounded by a replay window. The master key is server-side, configured once, encrypted at rest and never returned to a browser.
Accounts and roles
A merchant account is not a server admin.
- Sage has merchant and server-admin roles. Passwords use scrypt with per-account salts. Access tokens expire after 15 minutes; refresh tokens are stored as hashes, rotated on use and expire after 30 days. Invites expire after 7 days and are bound to the invited email.
Tenant isolation
A store lookup is an ownership check.
- Every store route resolves the store and checks that it belongs to the authenticated account before returning data. Repository methods are scoped by account and store, and SQL lives behind the repository layer rather than in route handlers.
Card data
No payments, no PANs.
- Salewise does not take payments and does not store card data. The shopper PWA has no checkout, and the transaction stays inside the merchant’s POS. We do not claim PCI DSS scope for card payments because we do not process card payments.
Retention
Configured, not indefinite.
- The reference deployment is configured for 180 days for session transcripts and 365 days for event records, set by environment and the DPA. Merchant-specific retention is agreed in the DPA, and deletion is handled on request. A scheduled purge is not claimed today.
Audit trail
Security-relevant events leave a record.
- Registration, sign-in, failed sign-in, invites, setup and integration credential changes are written to an audit log. Emails are hashed in audit details rather than stored raw. The log is internal today; there is no merchant-facing audit screen yet.
Model boundary
The model gets the minimum it needs.
- The model receives the shopper’s question, retrieved catalogue candidates, store settings and relevant policy text. It does not receive passwords, API credentials or card data, and it has no tool that can write to the POS.
“Built” means the control exists in the product today. It does not mean every control has been independently audited. The gap is listed at the bottom of this page.
Credentials & requests
Encrypted at rest. Signed in transit.
The two mechanisms a security reviewer usually asks for first.
Credentials at rest
- Algorithm
- AES-256-GCM, authenticated encryption.
- IV
- 12 random bytes per record, never reused.
- Binding
- AAD provider:{providerId}:account:{accountId}:credentials. A copied record fails to decrypt.
- Rotation
- keyVersion on every record; the previous key is accepted during rotation.
- Failure
- A failed decrypt fails closed. It does not retry with a stale secret.
Salewise requests
The master key is configured once during server setup. Every request is signed with it; the signature is not a bearer token.
canonical = method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + sha256(body); signature = HMAC-SHA256(masterKey, canonical);
- Sent as X-Sage-Signature with timestamp and nonce headers.
- Compared in constant time, with a replay window.
- Master key held server-side and encrypted at rest.
- Never returned to a browser or written to a log.
Data, roles & retention
Narrow data. Scoped access. A record.
The assistant does not need to know who the shopper is to answer a product question.
A session records
- A session ID, the QR code and the aisle that started it.
- The questions, answers and recommendations.
- Handoff events and timestamps.
No name, account or card data. The demo does not link a session to a named shopper.
Who can reach it
- A merchant account, scoped to the stores linked to it.
- A server admin, for setup and provider configuration.
- No cross-merchant store access through the store routes.
Invites are bound to an email and expire after 7 days.
How long it stays
- Session transcripts: configured for 180 days.
- Event records: configured for 365 days.
- Merchant-specific terms: set in the DPA.
Deletion is handled on request. A scheduled purge is not claimed today.
Audit events
Registration, sign-in, failed sign-in, invites, setup and integration credential changes are written to an audit log. Emails are hashed in audit details rather than stored raw. The log is internal today; we do not present it as a merchant-facing audit screen.
Attribution
The record has to survive an audit.
A matched sale is either exact or modelled. The merchant can see which, and why.
Deterministic
A redemption code carried from the session to the sale. Confidence 1.0. Modelled false. The sale is attributed outright.
Modelled
A same-store sale within a two-hour window containing recommended items. A confidence score is stored, capped at 0.92, and the match is labelled modelled everywhere it is reported.
Exact matches are exact. Modelled matches are labelled modelled wherever they are reported. The subscription is the only fee, and attribution is not presented as revenue.
Honest limits
What we do not claim.
Trust is easier to check when the gaps are stated.
If a questionnaire requires something on this list, say so.
We would rather lose the deal than answer around it.
- 01
We do not hold SOC 2 or ISO 27001 certification today.
- 02
We have not completed an independent penetration test or security audit today.
- 03
We do not claim PCI DSS scope for card payments, because we do not process card payments.
- 04
We do not train a shared model on one merchant's catalogue or conversations in the current product.
- 05
No AI system is risk-free. Grounding reduces invention; it does not remove the need for merchant review and handover rules.
- 06
We do not run a scheduled retention purge today; deletion is an operational procedure under the DPA.
- 07
Our audit log is internal and is not exposed as a merchant-facing audit screen.
- 08
We do not promise a service level on this page; any availability commitment is set in the order form.
Responsible disclosure
If you believe you have found a vulnerability, contact support@salewise.co.uk with enough detail to reproduce it. Please do not access another merchant’s data, disrupt the service, or disclose publicly before we have had a chance to respond.
Security questions
Ask the awkward question.
Security questionnaires, data processing terms and architecture questions are welcome. We will answer what we have and say what we do not.