Security

What we keep, what we never keep, and who sees what.

Written for the person at your firm who has to answer for it. Everything here describes the system as it runs today. Where something is planned rather than done, it says so.

The one-line version

Chat messages, AI answers and the values we catch are never stored. Everything in transit is encrypted with TLS, and the AI model receives placeholders, never the client values our rules catch. The only record we keep of a message is who sent it, when, and what kind of thing was caught.

The gate is updated continuously: new rules and identifier formats ship to every firm, and every update must pass our full automated attack suite before it goes live.

How a message is handled

Step	What happens
1. Check	The message is read against your industry template. Identifiers with checksums (cards, SSNs, routing numbers, IBANs, VINs) are only counted when the checksum holds.
2. Swap	Caught values become numbered placeholders such as [SSN_1]. Passwords, keys and privileged material are stopped outright; nothing is sent.
3. Ask	Only the placeholder version goes to the AI model.
4. Restore	The swap table travels with the conversation sealed (AES-256-GCM, bound to the account). Our server opens it for one request, puts the real values back into the answer, and never writes it to disk or to a log.
5. Record	The owner's log gets a line: who, when, the outcome and the names of the rules that fired. Never the value.

Controls in place

Area	Control	Status
Encryption in transit	HTTPS only, with HSTS. Session cookies are HttpOnly, Secure and SameSite=Strict.	In place
Encryption at rest	Staff names and emails, and the activity trail, are encrypted in the database with AES-256-GCM; sign-in finds an account by a keyed hash of the email. Daily backups are encrypted whole. Keys live outside the data and web folders, readable by the service account only.	In place
Sealed swap table	The table that turns placeholders back into values leaves the server only sealed with AES-256-GCM and bound to one account. Browsers, the extension and API callers hold ciphertext they cannot read, alter or reuse for another account.	In place
Passwords	scrypt with a per-user salt. Sessions are random 256-bit tokens; only their hashes are stored.	In place
Firm isolation	Every query is scoped to the signed-in user's firm. An automated attack suite checks one firm cannot read or change another's data on every build.	In place
Access roles	Staff and owners are separate roles; owner screens are refused to staff by the server, not only hidden.	In place
Request safety	Strict content security policy, same-origin checks on every change, request size limits, rate limits on sign-in, sign-up and chat.	In place
Audit trail	Sign-ins, failed sign-ins, staff changes, setting changes and billing changes are recorded. Owners can read their firm's trail.	In place
Error monitoring	Server and browser errors are recorded after the same scrubbing as chat messages, and new errors alert us immediately.	In place
Backups	A consistent copy of the database is made daily; fourteen days are kept, readable by the service account only.	In place
Off-site backups	Copies stored with a second provider.	Planned
Two-factor sign-in	A second factor for owners and for our own admin access.	Planned
Names, places, dates	A firm's client list is matched exactly and stored only as keyed hashes. Other names, addresses and dates are detected from context, a best effort each firm can set to off, flag or protect.	In place
Independent testing	A third-party penetration test.	Planned

Data we store, and for how long

Data	Kept
Chat messages and AI answers	Never stored
The owner's log (who, when, what kind of thing was caught)	400 days
Client list	Only as one-way keyed hashes, until the owner replaces it
Usage counts (messages and AI tokens per month)	For billing, while the account exists
Activity trail	400 days
Error records (scrubbed)	90 days after last seen
Accounts: names, work emails, password hashes	While the account exists
Daily backups	14 days
Card details	Never; Stripe holds them

Who processes what

Service	Purpose	What it receives
Hostinger	Hosting	The application and its database
Stripe	Billing	Owner name, email, billing address and card
AI model provider	Writing answers, only if your firm uses the built-in chat	Message text with caught values replaced by placeholders
ChatGPT or Claude, through the extension	Only when your staff use them	The placeholder version of what staff paste or send; the extension restores answers on screen
ntfy.sh	Phone alerts, if the owner turns them on	Staff name and the names of rules that fired; never a value

SOC 2

Safe-Desk has not been audited for SOC 2. We are building to the SOC 2 Trust Services Criteria for security, availability and confidentiality, and the controls above are the first part of that work. The remaining steps are written policies, the planned controls above, a compliance monitoring platform, and then an audit by an independent CPA firm. When a report exists we will say so here, and share it under NDA.

It also does not make your firm compliant on its own. It helps you meet confidentiality obligations by keeping client data out of AI tools and keeping a record.

Report a problem

Found a security issue? Email contactus@sophiaxt.com with "Security" in the subject. We read every report and will not take action against good-faith research.