Accounts and organizations
How people, service accounts, organizations, tenants, sessions, and adopted agents are separated.
/v1/auth/signup returns 404 {"error":"signup_unavailable"}. The live login page is available, but accounts must already exist or be created through an invitation or operator-assisted provisioning path.On this page
Access today
The deployed management service serves a preconfigured demonstration organization and supports an ordinary login flow. It is not an open registration service. A person needs a valid existing account or an unexpired, single-use invitation issued by an organization administrator. This is intentional: the development-only open signup route is forbidden in production configuration.
After account creation, the first-party identity path supports local password login, password reset, logout, session inventory and revocation, TOTP multifactor authentication, recovery codes, member suspension, and optional OIDC federation. OIDC is an integration, not a prerequisite.
Intended public signup flow
The public SaaS code implements the following workflow, but that provisioner is not deployed on the live service:
- Enter a work email, organization name, workspace slug, and region.
- Verify the email through a short-lived signed claim.
- Reserve a unique organization ID, tenant ID, and account subdomain.
- Provision tenant signing keys, policy, storage bindings, quotas, and either pooled or dedicated placement.
- Create a single-use owner invitation on the tenant-scoped identity service.
- Create the owner password directly on the account host, then continue to agent adoption.
No password should pass through the global signup service. It verifies and provisions the workspace, then hands the browser to the isolated account origin.
Organization and tenant isolation
Each authority binds one organization to one cryptographic tenant. Browser sessions obtain tenant scope from the authenticated account context; a tenant_id query parameter cannot switch the user into another organization. Object stores and repository keys repeat tenant ownership checks, while signed node artifacts carry the same tenant identity.
Enrollment tokens, node credentials, trust bundles, policies, decisions, receipts, fleet reports, exchanges, audit records, and usage units are tenant-bound. A token issued by Organization A cannot produce an Organization B identity. Separate authority cells are the recommended hard boundary for unrelated customers; pooled placement additionally requires database- and credential-level isolation before general release.
Multiple organizations
The product model supports many organizations, each with its own slug, tenant, authority, members, policies, nodes, and evidence. The current live deployment does not yet expose that public multi-organization provisioning layer.
- One adopted agent identity belongs to exactly one tenant.
- The default managed attachment path supports one adopted identity per operating-system user home.
- Separate users, containers, or isolated homes can hold separate identities on the same physical host.
- The installer refuses to consume a second enrollment token while a managed attachment already exists.
- Moving an agent between organizations requires retiring or revoking the old identity and performing a fresh adoption. A polished self-service transfer workflow is not available today.
- A human who belongs to multiple organizations will require an explicit organization choice or separate host-bound sessions; URL parameter substitution is never a switch mechanism.
Identity and roles
Permissions separate account administration, policy writing, independent policy approval, consent voting, trust and mandate administration, fleet commands, integration management, evidence access, and audit administration. Browser mutations require a session-bound CSRF token and same-origin validation.
| Identity | Use | Lifecycle |
|---|---|---|
| Organization owner/admin | Members, roles, security configuration, and delegated administration. | Protected against removing the final administrator. |
| Member | Role-scoped console and API access. | Invite, activate, suspend, reactivate, remove. |
| Service account | Non-browser automation with explicit permissions. | Create, rotate API keys, disable, revoke. |
| Node identity | Signs agent intents, reports, acknowledgements, results, and receipts. | Adopt, rotate, quarantine, retire, revoke, re-adopt. |
Launch entitlements and metering
Plans are disabled for the initial public launch. Every organization receives the same launch entitlement; users do not select a tier, enter payment details, see upgrade prompts, or pass through Stripe. Billing and plan-management routes must remain hidden or return a clear disabled state.
Planless does not mean unbounded. Every tenant still needs hard node, request, semantic-token, storage, retention, and event limits plus rate limiting and abuse controls. Semantic/model usage is attributed by tenant, agent, evaluator, model call, and token counts through an idempotent usage ledger for cost visibility and future product decisions, but it is not invoiced.
The data model may retain internal entitlement fields so plans can be introduced later without a tenant migration. Those fields are operational defaults, not a customer-visible commercial contract while plan mode is disabled. A metering or quota failure must never expand action authority.
Lifecycle boundaries
Invitations, sessions, API keys, members, and nodes have explicit terminal states rather than destructive deletion where evidence must remain verifiable. Organization rename, export, deletion, suspension, owner transfer, legal holds, final-admin protection, node revocation, subdomain cleanup, and usage-ledger closure must behave atomically before public SaaS launch. Those complete organization-lifecycle tests remain a release gate.