Members & roles
Everyone signs in with a single Hyrax login: a one-time code sent to your email, or Google, or GitHub. There are no Hyrax passwords to manage. Your whole team works in one workspace together on either plan. Each member has a role that sets what they can do by default, and every workspace has exactly one account owner. Membership lives on Members & invites, in the menu at the foot of the rail.
How teammates join
The simplest way to bring someone in is to invite them. Invite a teammate on Members & invites invites someone by email and reserves the role you choose. They get an email to sign in to Hyrax — no GitHub account required — and join the workspace with that role the moment they sign in (the reserved role is claimed by the verified email they sign in with). This means you can invite anyone with an email, including teammates who don't use GitHub. Pending invites appear in a Pending invites list on the same page, where an admin can revoke one before it's claimed.
Joining an existing workspace is by invitation. Someone who signs in to Hyrax without an invite doesn't land in your workspace — they start a new workspace of their own.
The account owner
Every workspace has exactly one account owner — initially the person who created the workspace. The owner:
- Holds every capability, regardless of role.
- Is the only person who can transfer ownership, rename the workspace URL, or disable / delete the workspace.
- Appears on Members & invites as an Admin with a star — the owner's role can't be changed there.
Ownership can be transferred to another member from Workspace settings → General → Danger zone. There is always exactly one owner.
Roles
Four roles, strictly nested — each includes everything the one below it can do.
| Role | What it can do by default |
|---|---|
| Admin | Everything a Member can, plus: configure and delete repositories, edit workspace settings and guidance, create Areas and reorganize Spaces and projects, start missions where they're enabled, manage every API key and the integration secrets, manage the subscription and billing, invite teammates, and change member roles. |
| Member | The day-to-day loop: view repositories, their findings and job runs; register new repositories; run audits and discovery; start fixes; triage findings (keep or dismiss); view, file, claim and close issues, and create Spaces and projects; read and write Team context; cancel their own running jobs; view workspace usage; and create and manage their own API keys, with scopes up to their own permissions. |
| Viewer | Sign-in only, with no default capabilities — the most restrictive tier, for accounts that shouldn't see code findings. |
| No access | Revoked. Can't enter the workspace. Used to remove someone while keeping their history. |
A few things roles deliberately don't change:
- Transferring ownership, renaming the workspace URL, and disabling / deleting the workspace stay owner-only — even admins can't.
- Managing API keys and integration secrets requires a browser session — these actions can never be performed with an
hk_live_API key, even one held by an admin or the owner. - Findings, issues, fixes and job history are shared workspace state: anything a member does is visible to the rest of the team under the same references,
HYRAX-Nfor findings,ISS-Nfor issues andMSN-Nfor missions.
The full action-by-action matrix is in the app: open Members & invites and select Role permissions.
Roles in Spaces and projects
A workspace role sets what someone can do anywhere. Inside a Space or a project, people can also hold a Member or Lead role there, which decides where they can file issues, change team context and create projects. Everyone in the workspace counts as a member of the Default Space for filing issues and creating projects there. See Space and project roles.
Team context permissions
Team context has four permissions of its own. Members and Admins hold all four by default; Viewers hold none.
| Permission | What it allows |
|---|---|
view_context | Read entries, digests and each entry's history. |
manage_context | Create, update, replace, disable and restore entries. Each of these returns the entry's full contents when the key also has view_context, and otherwise only its id, key, version, etag and status. It doesn't include view_context: a key that should read entries as well as write them needs both. |
confirm_context | Confirm entries, which makes agent proposals live. Signed-in people only: an API key can't confirm, even one that carries this permission. |
corroborate_context | Corroborate an entry another API key proposed. API keys only, and the key also needs view_context. The entry stays proposed until a person confirms it. |
Holding a permission isn't the whole rule. Writing at a project, Space or Area also needs a role there or on a level above it (workspace admins and the account owner can write anywhere), and writing at the workspace, or a subtree entry on an Area or a Space, also needs manage_projects, which is an Admin default. See Who can do what.
Changing a role
Admins change roles inline from the Members table — pick the new role and it applies immediately. Setting someone to No access signs them out everywhere right away; you can restore their access later from the same menu. Promoting someone to a higher role asks you to reconfirm with two-factor authentication.
Each member's detail page shows where their current role came from — set by an admin, or claimed from an invitation — along with their job history.
Members and seats
On Free, members are unlimited. Invite as many teammates as you like — nothing is billed, and there's no seat to buy. What bounds a Free workspace is its credit: each job draws against it.
On Paid, each member occupies a seat, and seats are what the plan charges for — $30 per seat, per month. A workspace holds one member per purchased seat, and every dollar of that subscription comes back as spending credit.
- Inviting someone past your seat count is refused, not silently billed. Buy a seat, or free one up — setting a member to No access releases theirs.
- A pending invite holds a seat from the moment it's sent, so an unclaimed invite still counts against capacity. Revoking it gives the seat back.
- Adding seats is self-serve on Settings → Billing and takes effect immediately. Removing them lowers the seat count right away and the bill at your next renewal — and it can't go below the seats currently in use.
Existing members always keep their access — a plan or seat change never removes anyone. Full mechanics, including what's charged when: Seats.
Good to know
- To revoke someone's access, manage it in Hyrax — not in GitHub. Workspace membership is managed on the Members page; removing someone from your GitHub organization does not revoke their Hyrax access on its own. Set their role to No access to sign them out everywhere on the spot.
- Per-member usage is visible. The Members table shows each member's job count and spend, so you can see who's running what. See Security for how workspace data is isolated.