Roles and permissions

Outcome

You can tell exactly what any account may see and do in prpl, and why. Access is the combination of four independent layers: a site role (what tier your account is), namespace ownership (which GitHub organizations you administer), organization membership with repository scope (which repositories an owner granted you), and named per-repository roles (what you may do on one specific repository).

Who can do it

This reference is public. Changing the layers is scoped: only a site admin changes site roles; only the mapped organization owner (or a site admin) manages members, seats, repository access, and named roles for their namespace.

Before you begin

• Site roles are waitlist, customer, and site_admin. Every new GitHub sign-up starts on the waitlist (the very first account ever created becomes the site admin). Waitlist accounts can pre-configure GitHub access and browse; only customers and site admins can start cost-incurring work (Harness builds, scans, patch generation).
• Ownership is bound to the GitHub namespace: signing in claims the namespace matching your own GitHub login if it is unclaimed, and a site admin can map additional namespaces to an owner. The owner administers members and repository access for every owner/* repository.
• Membership is created by an email invitation and consumes a licensed seat while active. Membership alone shows nothing: a member sees and acts on only the repositories the owner explicitly grants (capability AND scope — both are required). Owners are never scope-limited in their own namespace.
• Named repository roles refine one repository: Repo owner (the full delegated working set on that repository) and Findings reviewer (browse, view scan results, and review findings on that repository).

Steps: check what an account can do

1. Open your profile menu and select Settings. The Account page header shows your identity and role.
2. If you own a namespace, the Users section lists your members, seat usage (used/limit), pending invitations, and the Per-repo access grid of access grants and named roles.
3. If you are a member, the Your organization access section lists each organization and exactly the repositories you were granted — jobs and attack-surface data are limited to that list.
4. Site admins audit everything under /admin/users (site roles, account state) and /admin/policy (ownership map, seat limits, capability kill-switches, per-user overrides).

Verification

• Your Account page (Settings) shows the site role prpl has for you.
• A member's Your organization access list matches exactly the repositories they can see under Attack surface and Jobs.
• Actions you lack simply are not rendered (no launch, review, or archive controls); direct requests are refused with a message naming the missing permission.

Troubleshooting

• “BYOS launches require a customer account …” — your role is still waitlist; a site admin must promote you.
• “you do not have scan access to this repository” — the repository is outside your granted scope, or your seat grants do not include scanning. Ask the organization owner — see Assign repository access and roles.
• A member sees no repositories at all — expected default. Membership grants nothing until the owner grants per-repository access.
• An action disappeared for everyone — a site admin may have switched the capability off globally (cost kill-switch).
• More failure routing: Troubleshooting.

Next step

Owners: put the model to work in Invite members with initial repository access. Everyone else: Scan and finding lifecycle shows where each permission applies.