Workspace access and roles
Invite people, review access, and enforce least-privilege workspace capabilities.
A workspace is the tenant boundary for members, repositories, evidence, policies, audits, and actions. Membership is explicit: platform access alone never grants access to a workspace.
Invite a teammate
Owners and Admins can invite a verified email address from Members. An existing Hyperoru account receives an in-product invitation and can accept or decline it. A new user receives an account-bound registration link. Invitations expire after seven days, can be resent or revoked, and cannot be accepted by a different account.
New accounts verify their email before signing in. A user can request a replacement verification link without revealing whether an account exists; requests are protected by Turnstile and short resend cooldowns. If initial email delivery fails, registration and invitation redemption are rolled back together so the user can retry instead of being left with an inaccessible account.
Invitations are idempotent while pending. Repeating the same invitation rotates its one-time token instead of creating multiple active records. Suspended accounts and existing members are rejected.
Role capabilities
| Role | Intended capability |
|---|---|
| Viewer | Inspect repositories, evidence, findings, reports, usage, policies, and member identity |
| Developer | Run audits, submit evidence and uploads, request remediation, and request workflow actions |
| Analyst | Classify findings, approve reports and remediation, and approve bounded workflow actions |
| Admin | Manage repositories, policies, members, invitations, and all Analyst capabilities |
| Owner | Full workspace control, including Admin and Owner membership changes |
The API evaluates both the minimum role and the named permission on every scoped route. Browser sessions do not bypass scope checks. Workspace API tokens are constrained by their explicit scopes and by the current role of the member who created them.
Use GET /v1/workspaces/{workspace_id}/access to retrieve the server-authoritative role and permission list for the current identity.
Membership safeguards
- Only an Owner can invite, add, change, or remove an Admin or Owner.
- Ownership cannot be assigned through an invitation.
- A workspace must always retain at least one Owner.
- A user cannot accept an invitation issued to another email or account.
- Accept and decline decisions are serialized so the same invitation cannot produce competing membership state.
- Membership and invitation changes create workspace audit events.
The generated API reference covers workspace invitations, pending invitations, and membership changes.
Policies are workspace-scoped
Workspace policy changes require Admin or Owner access. Policy versions remain attributable to the member who changed them, and downstream audit, report, remediation, and workflow-action checks continue to enforce their own role and permission gates.