> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Control

> Create roles and grant users least-privilege access to CodeAnt product areas, settings, teams, and repositories.

CodeAnt **Access Control** combines three building blocks:

| Building block     | Defines                                                      |
| ------------------ | ------------------------------------------------------------ |
| **Role**           | Which CodeAnt product areas and settings a user can access.  |
| **Assignment**     | Which role a user receives on a repository or team.          |
| **Default access** | The baseline role for members without a matching assignment. |

Use these together to give each person only the product and repository access they need.

## Prerequisites

* You must be an organization administrator to manage Access Control.
* The organization must have more than one member. For a single-member organization, CodeAnt hides the Access Control page.
* Add users through **Settings → Team Management** or, where available, **Directory Sync** before creating assignments.
* [Teams](/settings/teams) are optional. Team-scoped assignments are currently available in the UI for GitHub organizations; every supported provider can use repository-scoped assignments.

Open **Settings → Access Control** in the organization you want to manage.

## Preset roles

CodeAnt creates three preset roles when Access Control is initialized. Preset roles cannot be edited or deleted.

| Preset             | Access                                                                                                                                                      |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Codeant Member** | Read AI Code Review, Code Quality, Code Security, and Cloud Security. This is the initial default role for new members.                                     |
| **Codeant CI/CD**  | Run and read scans, quality gates, and coverage, plus read the product areas used by a pipeline. Recommended for scoped [API tokens](/settings/api-tokens). |
| **Codeant Admin**  | Full access to every action and setting.                                                                                                                    |

You can create custom roles for any access model that the presets do not cover.

## Available permissions

### Product view access

Product permissions control which areas a user can see. These permissions are read-only.

| Permission              | Includes                                                |
| ----------------------- | ------------------------------------------------------- |
| **AI Code Review**      | Pull request reviews and suggestions                    |
| **Code Quality**        | Quality dashboards and results                          |
| **Code Security**       | SAST, SCA, secrets, and related findings                |
| **Cloud Security**      | Cloud Security, DAST, and IaC                           |
| **Engineering Metrics** | DORA and developer metrics                              |
| **IDE**                 | IDE extension features                                  |
| **CI/CD**               | Pipeline scans, quality gates, and test-coverage upload |

### Settings access

Settings permissions support **Read** and **Write**. Write access includes read access.

| Permission         | Includes                                                                                |
| ------------------ | --------------------------------------------------------------------------------------- |
| **Code Review**    | AI Code Review, Custom Agents, Learnings, Rules, and Automations settings               |
| **Code Analysis**  | Analysis Configuration, Quality Gates, and Documentation settings                       |
| **Cloud Security** | Cloud Security settings                                                                 |
| **Organization**   | Teams, Team Management, Access Control, Directory Sync, and organization administration |
| **Integrations**   | Integrations and provider token configuration                                           |
| **Monitoring**     | Audit Logs and Notifications                                                            |

The **Admin** permission grants full access to every product and settings action.

<Note>
  Settings permissions refine access for users who already have organization-administrator access to Settings. They do not promote a **Member** from Team Management to an organization administrator.
</Note>

## Create a custom role

1. Open the **Roles** tab.
2. Click **New role**.
3. Enter a descriptive name and description, such as `Security Viewer`.
4. Expand **View access**, **CI/CD access**, or **Settings access**.
5. Choose the permission level for each area:
   * **None** grants no access.
   * **Read** allows viewing.
   * **Write** allows viewing and changing settings where write is supported.
6. To grant everything, enable **Admin** instead of selecting individual permissions.
7. Click **Create role**.

<Tip>
  Prefer narrow roles named for a job function, such as `Security Viewer`, `PR Reviewer`, or `Metrics Viewer`. They are easier to audit and reuse than one-off roles named after individuals.
</Tip>

## Assign access

1. Open the **Assignments** tab.
2. Click **Assign role**.
3. Select one or more users.
4. Choose a scope:
   * **Repository** applies the role to one repository.
   * **Team** applies the role to every repository in that team and its descendant teams.
5. Select a role and click **Add**.
6. Add more scope-to-role entries if needed.
7. Click **Grant access**.

Each user has one assignment record containing all of their scope-to-role entries. Editing that user and saving replaces the complete set, so review every entry before saving.

## How effective access is resolved

CodeAnt resolves access separately for each repository.

1. **Matching explicit assignments take precedence.** If the user has repository or team assignments that cover the repository, CodeAnt combines those roles. When the same permission appears more than once, **Write** wins over **Read**.
2. **The default role covers repositories without a matching assignment.** A scoped assignment does not remove the default role from unrelated repositories.
3. **Organization administrators keep full access when they have no explicit assignment.** CodeAnt recognizes the organization administrator/owner from Team Management and, for GitHub, from provider ownership.

<Warning>
  An explicit Access Control assignment overrides inherited organization-administrator access. Assign a scoped role to an administrator only when you intend to restrict that administrator to the assignment and the configured default role.
</Warning>

For team scopes:

* an assignment to a parent team covers repositories in its child teams;
* a repository can match multiple teams, and all matching role permissions are combined; and
* an **all repositories** team covers current and future repositories.

The frontend hides unavailable areas and filters repository lists. The backend is the source of truth and rejects protected requests that lack the required permission with HTTP `403`:

```json theme={"system"}
{
  "message": "You don't have access to this resource",
  "code": "rbac_forbidden"
}
```

## Configure default access

The **Default access for new members** selector controls the baseline role used when no explicit assignment covers a repository. CodeAnt initially uses **Codeant Member** so existing members retain read access to the primary product areas.

Choose a custom role when every new member should start with a different baseline. Then use explicit assignments to override that baseline for specific repositories or teams.

<Warning>
  Changing default access affects every member on repositories not covered by one of their explicit assignments. Review the role carefully before saving it.
</Warning>

## Practical use cases

### Security team across many repositories

1. Create a `Security Viewer` role with **Code Security** and **Cloud Security** read access.
2. Create a [Security team](/settings/teams) that includes all repositories.
3. Assign `Security Viewer` to the security engineers on that team.

New repositories are covered automatically when the team uses **Include all repositories**.

### Contractor on one repository

1. Create a `PR Reviewer` role with **AI Code Review** read access.
2. Assign the contractor that role on only the required repository.
3. Keep the organization's default role narrow enough that it does not grant unwanted access on other repositories.

### Platform lead across nested teams

1. Create a role containing the product areas the lead needs.
2. Organize service teams under a Platform parent team.
3. Assign the role once on Platform.

Repositories added to any descendant team inherit the assignment.

### Scoped CI token

Use **Codeant CI/CD** or a custom role when creating an [API token](/settings/api-tokens), then limit the token to the repositories used by that pipeline. Token access cannot exceed the access of its creator.

## Maintain and audit access

* Search assignments by user, role, team, or repository.
* Remove obsolete entries when a person changes teams.
* Delete unused custom roles only after removing their assignments.
* Review changes in **Settings → Audit Logs**.
* Re-check assignments before deleting or restructuring a team.

<Tip>
  Review default access, administrator assignments, all-repositories teams, and CI tokens regularly. These have the widest potential scope.
</Tip>