Auth and tenancy

Browser sessions, SDK API keys, workspace isolation, scopes, and permission checks.

Open .md

InstantML deliberately uses different credentials for humans and training jobs, and both resolve to exactly one workspace before any product data is read or written.

CredentialTransportMain use
Browser sessioninstantml_session HttpOnly cookieDashboard after hosted sign-in.
SDK API keyAuthorization: Bearer instantml_...SDK, uploader, imports, exports, and automation.

The identity provider's session token never becomes the SDK credential, and the SDK API key never depends on the identity provider.

Browser sign-in flow

StepCallerAction
1BrowserGET /api/auth/config to learn the available auth providers.
2BrowserSign in or sign up with the configured identity provider (Clerk on the hosted service).
3BrowserSubmit the provider token to POST /api/auth/clerk.
4InstantML APIVerify the token signature, issuer, and verified email.
5InstantML APIUpsert user, workspace, membership, and session records in the control plane.
6InstantML APIProvision or load the workspace's tenant route.
7InstantML APIReturn the auth payload and set the browser session cookie.

Cookie-authenticated mutating requests validate Origin against the allowed frontend origins. Bearer-token SDK requests are not origin-gated because they are not browser-cookie requests.

The CLI signs in without a browser cookie: instantml login uses the device-code flow (/api/auth/device-code/*) to mint an API key after you confirm the code in the dashboard. See CLI login.

API-key flow

StageWhat happens
Bearer keyThe request presents Authorization: Bearer instantml_....
Key authenticationThe API authenticates the key hash; plaintext keys are never stored.
Tenant resolutionThe API resolves the workspace (org_id) and any project scope attached to the key.
Route lookupThe API loads the tenant route for that workspace.
Scope checksThe route handler enforces API-key scopes and project boundaries.
Product accessThe request reads or mutates tenant data.

Project-scoped API keys can only read or mutate their project. Workspace-scoped keys can access every project allowed by their scopes.

API-key scopes

ScopeGrants
sdk:ingestCreate projects and runs, log metrics, logs, attributes, and objects.
artifacts:writeUpload artifacts and create artifact versions.
artifacts:manageManage artifact collections, aliases, and retention.
imports:writeCreate import jobs.
export:readRead data exports.
usage:readRead usage summaries (unrestricted workspace keys only).
api_keys:writeAdminister API keys.
runs:controlRecord cooperative stop signals for runs.

Permission matrix

Route classAPI keyOwner/admin sessionMember sessionViewer session
Dashboard readsScope and workspace/project checksAllowedAllowedAllowed
Run/project mutationssdk:ingestAllowedAllowedDenied
Artifact mutationsartifacts:writeAllowedAllowedDenied
Importsimports:writeAllowedDeniedDenied
ReportsSame-workspace key for writes; same-workspace key or share token for readsAllowedRead/write allowedReads allowed; writes denied
Usage readsUnrestricted workspace key with usage:readAllowedDeniedDenied
API-key adminapi_keys:write workspace keyAllowedDeniedDenied
Seat and invitation adminNot a public SDK flowAllowedDeniedDenied

Shared demo sessions

The shared demo workspace is read-only. Demo credentials are treated as export:read at authorization time, so demo sessions can browse and export sample data but cannot create runs, mutate artifacts, import data, administer API keys, or change seats.

Tenant boundaries

Every tenant-owned product row carries the workspace's org_id, and run and project helpers reject rows from a different workspace. Project-scoped keys add a second boundary around a single project.

Sign-out and revocation

POST /api/auth/logout revokes the current browser session and clears the cookie. Revoked or expired sessions are rejected on the next request.

Removing a user from a workspace invalidates their effective access immediately, because building a session payload requires an active membership.

Next steps