---
id: project-settings.project-members
title: Project Members
summary: Grant or remove user and group access to a project while keeping task assignment and artifact governance separate.
kind: reference
product_area: project_settings
status: stable
updated: 2026-09-07
canonical: /docs/project-settings/project-members
---

# Project Members

## Definition

Project Members manages which workspace users and groups can access a project. A grant names a principal of type **USER** or **GROUP**; removing the grant removes that project-level access path.

Membership is not the same as selecting an expert for a Contribution, assigning a review task, or approving an artifact. Those workflows add scoped responsibility inside an already accessible project.

Before removing access, check whether the person or group owns active Contribution work or operational follow-up. Reassign that work first; this page does not define what historical records remain visible after access changes.

## Fields, states, or lifecycle rules

- A grant targets a user or group principal.
- Adding a grant creates a project access path.
- Removing a grant removes that current Project access path.
- Effective access can remain through another user, group, or workspace-level path.

## Manage access

1. Open **Project Settings → Project Members**.
2. Review existing principals and whether each grant belongs to a user or group.
3. Add the smallest appropriate principal. Prefer a managed group when access follows a durable team responsibility.
4. Before removing a grant, check active Contributions, reviews, and operational ownership that may need reassignment.
5. Confirm the resulting member list and test the intended product path through ordinary authorization.

Group access follows the group relationship managed by the workspace; it should not be duplicated as many individual grants without an operational reason. A user can also have more than one access path, so removing one grant may not remove all effective access.

> Access boundary
>
> Grant the smallest appropriate project scope. Do not copy credentials or sensitive material into project content as a substitute for access control.

Project access does not grant secret values automatically. Harness secret grants remain explicit. Contribution selection also remains separate: an expert needs the applicable project access path and a scoped Contribution before completing assigned work.

This page makes no retention-period or post-removal visibility guarantee. Historical attribution and record access are governed by the records and permissions the current product exposes at the time they are inspected.

{% related-card-grid title="Related governance" %}
- [Roles and permissions](/docs/governance/roles-and-permissions)
- [Reviewer and project access](/docs/governance/reviewer-and-project-access)
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
{% /related-card-grid %}

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Request an Expert Contribution](/docs/expert-contributions/request-contribution)
- [Complete an Expert Contribution](/docs/expert-contributions/complete-contribution)
{% /related-card-grid %}

## Source confidence

Code-backed: the active members and project-permissions routes expose user and group grants and removal. Workspace-wide role administration remains a separate governance surface.