Workspaces & tenancy

The hierarchy#

Top-down, the identity hierarchy is:

1

Partner  →  Tenant  →  Workspace

• Partner — top-level organisation / reseller (a ScaiKey concept).
• Tenant — an identity and billing container under a partner (a ScaiKey concept).
• Workspace — ScaiCrew's own concept, nested inside a tenant, modelling a sub-area of the virtual "company" (a department or domain). A tenant may have many workspaces.

The isolation boundary#

The workspace is the hard tenancy boundary. Every control-plane table carries workspace_id, and the API always derives it from the caller's token, never from a request body. Cross-workspace reads are impossible by construction, and ScaiCrew owns that isolation itself — even across tenants.

A "crew" is a grouping within a workspace for organising members; it is not a security boundary.

Membership#

Because a real ScaiKey user token proves who and which tenant — but not which workspace (that's ScaiCrew's concept) — membership decides which workspaces a user may enter and as what role:

• GET /v1/me/workspaces lists the workspaces a logged-in user may enter, with their role.
• A tenant's first user is bootstrapped a default workspace as admin, so there is always a way in. That admin can create more workspaces and add members.
• A user's membership is always scoped to their tenant — it cannot cross tenants.

The chosen workspace is carried inside the session token, so every subsequent request is scoped and role-checked from the token alone.