Assign repository access and roles

Outcome

A member of your organization can see and work on exactly the repositories you chose — and nothing else. You understand prpl's two-level model: access puts a repository in a member's scope, and named roles refine what they may do there.

Who can do it

Only the organization's mapped owner or a site administrator can grant or revoke repository access and assign named roles. Roles can only be assigned to people who are already members of the organization — invite them first (Invite members with initial repository access).

Before you begin

• Understand the two levels. Membership alone exposes no repository. A member may act on a repository only when both halves hold:
  1. Access (scope): you granted them that specific repository. Without it they cannot see the repository, its scans, or its findings at all.
  2. Capability: what they may do inside that scope. Members receive the standard working set when they join (run Harness builds, launch scans, review findings, generate patches, approve pull requests, archive) — but it only applies to repositories in their scope. Named roles add or narrow capabilities on one repository.
• The repository must have run history. The per-repo controls list a repository only after it has been worked on at least once under your namespace — its environment prepared or a scan run. Scan first (Run a security scan), then delegate.
• Revoking access is a full cut. Revoking a member's access to a repository also clears their named roles on it, and the repository disappears from their view immediately.

Steps

1. Open your profile menu (top right), choose Settings, and scroll to the Users section on the Account page.
2. In your organization's card, find Per-repo access. Each repository is listed with a row per active member.
3. Grant access. Select + Grant access next to the member on the repository you want to expose. The button changes to ✓ Access and the page confirms Repository access updated. The repository is now in the member's scope, and their org-wide working capabilities apply to it.

4. Optionally assign a named role. Once a member has access, role buttons appear next to the access toggle:
   • Repo owner — the full delegable working set on that repository: view, run Harness builds and scans, review findings, generate patches, approve pull requests, archive.
   • Findings reviewer — a triage-focused set on that repository: browse it, view scan results, and acknowledge or reject findings.
   Selecting a role button toggles it; the page confirms Role updated.

5. Revoke when done. Selecting ✓ Access removes the repository from the member's scope and clears every role they held on it.

Verification

• The member's row on the repository shows ✓ Access (and any role toggled to its ✓ state).
• The member's own Account page lists the repository under Your organization access.
• Signed in as the member, the Attack surface page shows that repository — and no repository you did not grant.

Troubleshooting

• The repository is not listed under Per-repo access. It has no scan history yet — the card shows No repos scanned in this org yet — once a scan runs, grant per-repo access here. Run a scan first.
• The member is missing from a repository's rows. Disabled members are hidden from the access table. Re-enable them under the member table first (this re-occupies a seat).
• The member has a role but still cannot act. Check the access toggle: a named role only works on a repository that is in the member's scope, and revoking access clears roles. Re-grant access, then re-assign the role.
• "user is not a member of this org." You tried to point a non-member at a repository. Invite them first, then grant access.

Next step

Review the seat picture and offboarding controls in Manage members and seats. For the full permission matrix behind this page, see Roles and permissions.