Administration
Users and tokens
Inviting people
Signing up provisions an organisation and makes you its owner. From there an admin or owner invites people, and an invitation has one of two shapes:
| Shape | What accepting it does |
|---|---|
| Seat | Adds the guest to your organisation with the role the invitation names — never owner. An invitation that names owner is issued as member. |
| Workspace | Creates the guest’s own new organisation and makes them its owner. They are never a member of yours. |
Use the workspace shape for an outside company: a seat would put them inside your organisation, next to your repositories.
A seat invitation never grants owner because a link is redeemed later, by whoever holds it, and that is not an owner acting. Ownership of an existing organisation moves only when an owner grants it. Accepting a seat invitation also never changes the role of somebody already in the organisation: inviting a current viewer “as admin” leaves them a viewer.
Changing roles and removing people
New after
v0.2.1. The owner boundary ships in the first garboard release afterv0.2.1. Inv0.2.1, an admin can also make someone an owner, change an owner’s role or remove an owner, subject to the last-owner guard.
An admin manages admins, members and viewers: changes their roles, or removes them. Only an owner may make someone an owner, change an owner’s role, or remove an owner — an admin is refused with owner role required. Removing someone ends every session and token they hold in that organisation. Why owner is a boundary.
The last-owner guard
A request that would demote or remove the last owner is refused. An owner may demote or remove another owner, or step down, as long as another owner remains. The check is made per request, so two owners who demote or remove each other at the same moment can both pass it: change owners one at a time.
This is the kind of guard that looks like a technicality until the day someone tidies up a user list and leaves nobody able to do what only an owner can — make an owner, choose the identity provider, or unlink a GitHub installation. Nobody else can grant ownership, so there is no self-service recovery from that; the guard is cheaper.
Personal access tokens
For scripts and automation.
| Property | Value |
|---|---|
| Prefix | gbp_… |
| Shown | Once, at creation |
| Access | Read-only, by design |
| Rate limit | 120 requests per minute, per token |
| Scope | The token’s own organisation |
Read-only is a property of the token type, not a permission you choose. A PAT cannot mutate anything, so a leaked one cannot adopt a rule, dismiss a finding, or change a setting. What it can read is capped by the current role, in that organisation, of the person who created it — and while SSO is enforced it reads nothing at all.
The rate limit is in a bucket separate from the login limiter, so a script hitting its ceiling never affects anyone’s ability to sign in.
A PAT is not a sign-in. That matters under enforced SSO: a token never gets the owner break-glass, so while enforcement is on every token in the organisation is refused — an owner’s included — because a credential that is not a sign-in should not get a door that nothing records.
If a token leaks
Revoke it. It was read-only and organisation-scoped, so the blast radius is “someone could read your findings”, which is real and is not a write. Rotate, then check the audit log for the period — reads are not audited individually, but any change in that window is attributable.