---
summary: "The Partner \u2192 Tenant \u2192 Workspace hierarchy and the isolation boundary."
title: Workspaces & tenancy
path: workspaces
status: published
---

# Workspaces & tenancy

## The hierarchy

Top-down, the identity hierarchy is:

```
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](/docs/scaicrew/authentication/login), so every
subsequent request is scoped and role-checked from the token alone.