Access
How Sazabi controls who can see and change your data — roles, project access, sign-in, two-factor, sessions, and the isolation between organizations.
Access to your data is scoped to your organization and enforced on every request. Who can see and change what is governed by roles, project membership, and the credential a request carries.
Roles
Every member holds one organization role, from most to least access:
| Role | Can do |
|---|---|
| Owner | Everything, including renaming and deleting the organization. |
| Admin | Manage members, billing, integrations, and settings — everything except organization rename and delete. |
| Member | Day-to-day work: connect sources, run investigations, configure tools. Cannot manage organization settings. |
| Viewer | Read-only access. |
Permissions are enforced on the server, not only in the interface. See Access control for the full permission model.
Project access
By default, every organization member can reach every project. A project can be restricted so ordinary members can open it only when they are named on it — the restriction is enforced on reads and writes alike, so a member who is not on a restricted project cannot query its data. Organization owners and admins retain organization-level access to every project, including restricted ones.
Sign-in and two-factor
Members sign in with email or a connected identity provider — Google, GitHub, Microsoft, Slack, or Linear. Sazabi links a social sign-in to an existing account only when the provider has verified the email or domain, which prevents an attacker from claiming an account by asserting someone else's address. Each member can add two-factor authentication under Settings > Security.
Sessions
Permissions are evaluated live, on every request, against the member's current role and membership — not against what was true when they signed in. Changing a member's role takes effect on their next request, removing them from the organization or disabling the organization revokes their sessions, and administrators can revoke a member's sessions when access needs to end immediately.
Tenant isolation
Your organization's data is isolated from every other organization. Sazabi resolves the organization and project for a request from the credential it carries, never from a value the caller supplies, and re-checks membership on every authenticated request. A request for a resource you cannot reach is denied with the same uniform response whether or not the resource exists, so access boundaries do not leak information about other tenants.
Keys
Two credential types reach your data: public keys, which are project-scoped and used only to send telemetry in, and secret keys, which grant full read and write — organization-scoped by default, or restricted to a single project at creation so the narrowest credential can be issued. Treat secret keys like production credentials. See Manage keys for scoping, rotation, and revocation.