Security
Who can see what, and why.
Snoze is an early product built by a small team in Doha. This page says what the product actually enforces today, and what it does not have yet. We would rather lose a deal than win one on a claim we cannot stand behind.
Access
Six built-in roles
Owner, Admin, Creator, Editor, Operator and Viewer, each with a fixed permission set. Custom roles can be built from the same permissions when the built-ins do not fit.
Permissions per item and per view
A view can be shared without sharing the database behind it. Editing, comments and native controls all resolve against the same effective permission, not the UI that happens to be open.
Public links are opt-in
Nothing is public until someone publishes it. Published pages and public forms are explicit, per item, and can be unpublished at any time. Search-engine indexing of a published page is its own separate switch.
Operators and viewers cost nothing
Free seats are not a reason to share one login. Everyone who touches the work can have their own account and their own permissions.
The assistant
It reads with your permissions
The assistant runs as you. A record you cannot open is a record it cannot read, so an answer cannot leak something you were not allowed to see.
High-stakes actions ask first
Destructive or wide-reaching changes go through an approval gate instead of happening quietly.
Machine work is marked
Anything the assistant writes is marked in one colour across the product, and every change it makes can be undone like any other edit.
Your own agents, your own permissions
The MCP server exposes the workspace to tools you already run. They inherit your permissions and show up in the workspace activity log.
Keys and integrations
Scoped API keys
Keys are created per workspace and scoped to individual permissions - read, write, comment and run, separately across resources, files, databases, records, automations, billing and platform settings.
Expiry and revocation
A key can be given an expiry date and revoked at any time. A key never exceeds the permissions of the member who created it.
Signed webhooks
Workspace events are pushed to your systems as signed webhooks, so you can verify that a payload came from Snoze.
Your data
Export on every plan
Any database exports to CSV and files download as they are - on the free plan too. There is no export paywall and no lock-in.
History you can walk back
Records and pages keep their versions, so an accidental change is recoverable rather than final. How far back depends on your plan.
Deleting an account
Account and workspace deletion is self-serve and documented, including what happens to the data afterwards.
How deletion worksWhat we collect, and why
The privacy policy describes what Snoze processes when you use the service and who it is shared with.
Read the privacy policyControls by plan
Everything above applies on every plan. These are the additions.
Business
- SSO / SAML
- Audit log
- Custom roles
Enterprise
- SCIM provisioning
- SSO enforcement
- Custom DPA and SLA
- Region pinning
- Sandbox workspace
Reporting a vulnerability
Report privately through GitHub Security Advisories rather than a public issue. Include reproduction steps, the affected component and the impact. We acknowledge the report and coordinate remediation and disclosure with you.
What we do not have yet
If one of these is a requirement for you, say so before you start and we will tell you honestly where it sits.
- No SOC 2 or ISO 27001 report. We are pre-launch and have not completed an audit.
- No third-party penetration test published yet.
- No public bug bounty. Reports go through GitHub Security Advisories and get answered.
- No contractual uptime SLA outside an Enterprise agreement.