Multi-tenancy & data isolation

Cloud Control is multi-tenant: many organizations share one deployment, and each sees only its own data. Isolation is enforced at the data-access layer, not left to the UI.

Every request is org-scoped

An authenticated request carries the caller's organization id, and every Store query filters by it. There is no endpoint that returns another organization's users, cloud accounts, inventory, cost or audit rows. Listing endpoints return only your organization's rows; item endpoints look up by (orgId, id).

Cross-tenant identifiers return 404

Asking for a resource that belongs to another organization returns the same 404 as asking for one that does not exist — the API never confirms that an id is valid elsewhere. This holds for cloud accounts, budgets, users, API tokens and every other item route, so an id from one tenant is useless in another and reveals nothing.

The platform organization

One special organization, snoweasl-platform, hosts the platform admin — the operator of the deployment. A platform admin can list and manage every organization's plan, status and feature flags through `/api/admin/orgs`, and suspending an organization immediately kills its sessions. This is fleet administration, not data access: the platform admin console manages tenancy settings, and the platform organization itself can never be suspended. Non-admins receive a 404 for the entire admin surface, so its existence is invisible.

Isolation and API tokens

API tokens inherit the same isolation: a token authenticates as a user within one organization, its role is a capability ceiling, and it can never carry owner or platform powers. A token from one organization cannot address another's resources.