Every record in DataSpice is scoped to the workspace that owns it, and that scope is checked on every request rather than assumed from a session. Credentials for connected services are encrypted before storage with keys held separately from the data, session tokens are stored only as hashes, and everything is served over HTTPS. This page states what is actually implemented, not what is aspired to.
How workspace isolation works
Tenant isolation is enforced on every request, not at sign-in. A session identifies a person; it does not grant access to a workspace by itself, and every query that reads or writes customer data is scoped to the workspace the request is authorised for. A workspace identifier supplied by a client is never trusted as the authority for what may be read.
This matters because the most common way multi-tenant analytics leaks is not a broken login. It is one correctly authenticated customer being handed another customer's row because a filter was applied in the interface rather than in the query.
How credentials for connected services are stored
App Store Connect keys, revenue-provider credentials and Google Search Console authorisations are encrypted before they are written, with key material held separately from the database that holds the ciphertext. They are used only by the backend and never reach the browser: no page in the product ever receives one, and no client-side code has a path to read one.
The same rule governs the AI layer's provider key. It is backend-only, and no prompt, key or raw provider payload is exposed to the client.
How sessions and sign-in are protected
Sign-in is passwordless: a link sent to your email address, or an external identity provider if you choose one. There is no password to reuse, leak or phish.
Session tokens are stored as hashes, so a copy of the database cannot be replayed as a sign-in. We keep sign-in records (the time, the provider and the network address) so that unfamiliar access is visible to you and to us.
What the tracking script sends from your visitors
Less than most analytics tools, by design, because the least risky data is the data never collected. Query strings and fragments are dropped in the browser before the request leaves, so names, tokens and search terms in a URL are never transmitted. Referrers are reduced to their origin. Country comes from the connection; no location is read from the device and no permission is requested. The visitor IP address is hashed to resolve a session and is never retained.
No cookies are set for analytics, and no identifier is shared between sites, so there is no profile that follows anybody across the web.
What DataSpice does not have
Stated plainly, because a security page that lists only strengths is a security page nobody should believe.
No SOC 2, ISO 27001 or comparable third-party audit.
No completed standard security questionnaire and no vendor references, because there is no public customer base yet.
No self-hosted build, so the data is on our infrastructure rather than yours. If that is disqualifying, Matomo and Umami are the honest alternatives.
No customer-facing API key or data export, which is a limitation but also removes an entire class of credential-leak risk.
No published bug-bounty programme. Reports are still welcome and are read.
How to report a security problem
Send it to [email protected] and it will be read. Include enough detail to reproduce it; you do not need to prove impact first, and you will not be pursued for reporting something found in good faith without damaging or accessing other people's data.
If a breach affects you, you will be told, and so will the relevant authority, within the time the law requires. You will get what is known at the time rather than a tidy account weeks later.