Home / Security & trust
What we do, and what we do not have yet.
Security pages usually list everything a vendor has and quietly omit the rest. This one has a section for the gaps, because you will find them during procurement anyway and it is cheaper for both of us if you find them now.
Isolation
One workspace cannot read another.
- →Every read and write is scoped. Queries are constrained to one workspace and one project, and a request that arrives without a scope is refused rather than widened to everything.
- →Membership is a stored fact. Which workspace a user belongs to is recorded on the account, not inferred from their email domain — so a customer whose team signs in with personal addresses is isolated exactly like anyone else.
- →Reads run as a restricted account. The warehouse credential used for tenant queries is read-only, with hard limits on execution time, memory and rows that no query can raise.
- →Identity is verified at the edge. Internal services refuse identity headers that do not come from the gateway, so a request cannot impersonate a user by setting a header.
Data handling
Privacy that happens before the data leaves.
- →Replay masks inputs in the browser. Not stripped on our servers afterwards, which would mean it had already travelled. Anything typed never enters the recording.
- →IP addresses are anonymised on arrival, and used for coarse geography only.
- →Consent travels with the event. If consent has not been given, nothing is recorded — rather than recorded and filtered later.
- →Credentials are encrypted at rest and never returned by any API once saved. You see a hint such as …7Qx2, never the value.
- →Secrets stay out of logs. API keys, model keys and connection strings are never written to a log line.
- →Raw events never reach a model. AI features send your schema and your question, and the query runs on your own rows.
Access & accountability
Who did what, and when.
Single sign-on
OIDC, with domain verification. SAML is not available yet.
Two-factor authentication
TOTP with recovery codes, on every plan.
Roles & permissions
Owner, admin, member and read-only, scoped per project.
Audit trail
Administrative changes are recorded with the actor, the before and after values, and the time.
Session revocation
Sessions can be invalidated centrally and stop working at the edge immediately.
Durability
Events land in a replayable log before storage, so an outage downstream is caught up, not lost.
The gaps
Not yet, stated plainly.
If any of these is a requirement rather than a preference, tell us before you invest time in an evaluation — we would rather lose the deal early than waste your quarter.
- ✗SOC 2 is not certified. We have not completed an audit. Saying otherwise would be the easiest lie on this page and the worst one.
- ✗SAML and SCIM are not implemented. Single sign-on is OIDC only; user provisioning is manual or by invitation.
- ✗Per-customer restore is not available. Recovering one workspace's data without touching others is not yet possible with our backup method.
- ✗No published uptime SLA. We will not promise a number we cannot yet measure over a meaningful period.
- ✗No third-party penetration test yet. Internal review only, including a full audit of authentication and tenant isolation.
Security contact
Found something? Tell us.
Report a vulnerability to [email protected]. We will acknowledge within two working days and keep you updated until it is closed. We will not take legal action against good-faith research.