Organization and repository roles
Who can manage members, repositories, billing and audit — and what no role can do.
Written By Dustin
Last updated About 6 hours ago
There are two independent role systems: one over the organization, one over each repository. Someone's authority is the combination, and neither implies the other.
Organization roles
Only an Owner can hand out or take away the Owner role. An Admin cannot promote themselves, and cannot demote an Owner.
Repository roles
The rule that catches people out
No role decrypts anything. Roles are authority over the hosted service — who may press which button, who may see the invoice, who may read the audit log. A repository Admin with no key grant still cannot read a protected path, and an organization Owner cannot either. That is the whole point of the permission model, and it is why an administrator compromise is not automatically a content compromise.
Read the two systems in that order: roles decide what the service will do for someone; policy and keys decide what plaintext they can obtain.
Choosing roles well
Keep more than one Owner, so a single departure cannot strand the organization.
Give finance the Billing role, not Admin.
Give reviewers and auditors the Auditor role rather than a repository grant they do not need.
Default new people to Member, then grant repository access deliberately.
Some organization actions can also be put behind a step-up prompt — settings changes and token minting among them — so a role is a necessary condition, not always a sufficient one.