Mosaic · Security
Security.
Mosaic is given access to the systems a business runs on. This page says how that access is kept to reading, where your data lives, what is written down, and what has and has not been independently checked yet.
The short version
- Mosaic reads your systems and never changes them. That is enforced in three layers, the last of which is a login you control.
- Self-hosted, your data stays on your network. The rows being reconciled never reach us, and we have no route by which to read them.
- Credentials are encrypted at rest with a key that lives with your installation, not with us.
- Every result can be traced to what produced it, and every change to what a check computes is in an audit trail you can export.
- We are not certified yet. See the last section for what that means and what we offer meanwhile.
Read-only, in three layers
The systems Mosaic is pointed at are your live POS, your ERP, your warehouse. So "only reads" is not left to good behaviour.
-
The query is checked. A statement that is not a read —
INSERT,UPDATE,DELETE,DROP,EXEC,SELECT … INTOa table, a statement hidden insideOPENQUERY, and the rest — is refused as it is typed and again on the server, after every parameter has been filled in. A REST source may read withGET;PUT,PATCHandDELETEare refused, andPOSTruns only once somebody has confirmed it is a search. - The database is told. Each run asks the database itself to refuse writes on the session Mosaic opens: a read-only session on PostgreSQL, MySQL and Oracle, a transaction that is always rolled back on SQL Server and Snowflake. That catches what no keyword list can, such as a function that writes while looking like a read. The few engines that cannot be asked (Redshift, CockroachDB, MySQL before 5.6) rely on the other two layers.
- A read-only login. The guarantee an auditor accepts, because it holds whatever any software does. The documentation gives the exact statements for each database: Read-only access.
Where your data lives
Self-hosted, Mosaic runs on your own machines, as a Windows service or a systemd unit, and reads your systems from inside your network. Nothing it reads is sent to us. The one thing an installation sends, once a day, is a licence check-in holding the licence key, an identifier the installation made for itself, and its version — no hostname, no user, no data — and it can be switched off. The privacy page has the detail.
On the hosted service, Mosaic runs on our infrastructure and processes what you connect it to on your behalf. For a system that must not be reached from outside your network, run Mosaic inside it instead: it is the same product.
Credentials
Passwords, tokens and secret variables are encrypted at rest with AES-256-GCM. The key is
the installation's own — generated on first start, or supplied in
MOSAIC_MASTER_KEY — and the hosted service will not start without one.
A saved password is never shown back in the interface, never exported with a check, and
never written to the audit trail. Connections to your databases use TLS where you switch
it on for that source.
Signing in
Passwords are stored only as scrypt hashes, and repeated failures slow the next attempt. Anybody can add a second factor, a code from an authenticator app with single-use recovery codes, and an installation can make it compulsory for everybody. Where your organisation has an identity provider, Mosaic can sign people in through it over OpenID Connect (Microsoft Entra ID, Okta, Google Workspace and others) and can turn passwords off altogether. Your provider says who somebody is. Whether they have an account in Mosaic is still decided in Mosaic.
Who can do what
Four roles — owner, admin, editor, viewer — checked on every request against one table that refuses anything it does not name. Workspaces are kept apart: a member of one cannot read another's checks, sources or results. API keys are stored only as hashes, carry a role no higher than editor, expire, and can be revoked. A page published for readers shows the figures chosen for it and never a query, a source or a credential.
Evidence
A reconciliation you cannot explain is not evidence. Every run of a check records the definition it used — its sources, comparisons, rules and parameters, with passwords masked — and a run reopened later says whether the check has changed since, and what. The audit trail records who signed in, who changed access, what was published, and who created, edited or deleted a check, a source or a comparison. Admins can export it as CSV for an auditor or a SIEM.
How we run our own side
The service that issues licences is separate from the product and holds the one key that signs them. Staff sign in to it with a password and a second factor, attempts are throttled, and each licence records who issued it.
Every change runs through automated type checks, the full test suite and a dependency audit before it is released, and dependency updates arrive by pull request every week.
Certification
DataMosaic is not SOC 2 or ISO/IEC 27001 certified today. The product is being built so that it can be — access, encryption, audit and the evidence behind each result are in place now rather than added for an auditor later — and this page will say so, with the report or the certificate, when an independent auditor has checked it. Until then we will not describe it as certified in any other words.
Meanwhile, if your organisation runs a security review, we will complete your questionnaire and walk your team through the architecture: support@getdatamosaic.com.
Reporting a vulnerability
If you believe you have found a security problem in Mosaic or in this site, write to support@getdatamosaic.com with "Security" in the subject. Please give us a reasonable time to fix it before telling anybody else. We will acknowledge the report, keep you told, and credit you if you would like. There is a machine-readable version at /.well-known/security.txt.