Administration
Users and tokens
Inviting people
Signing up provisions an organisation. From there an admin invites members and assigns a role.
The last-owner guard
An organisation cannot be left without an owner. Endpoints refuse to demote or remove the last one.
This is the kind of guard that looks like a technicality until the day someone tidies up a user list and locks the organisation out of its own billing and settings. 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. It can read what its organisation can read.
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 does not receive an owner break-glass entry, because a credential that is not a sign-in should not get one 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.