---
title: "Role-Based Access Control (RBAC)"
slug: "rbac"
description: "Learn how to implement role-based access control in Traceable. Define predefined and custom roles, manage permissions, and scope access to ensure secure API management and effective team collaboration."
updated: 2026-07-06T21:39:26Z
published: 2026-07-06T21:39:26Z
canonical: "traceabledocs.document360.io/rbac"
---

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

# Role-Based Access Control (RBAC)

##### Updates (April 2026 to June 2026)

- *June 2026* — Updated the topic to add information about the environment-based RBAC scoping. For more information, see [Access Controls](/v1/docs/rbac#rolebased-access-control1).

**RBAC** stands for **Role-Based Access Control**. Granular Role-Based Access Control (RBAC) and environment-level scoping provide fine-grained control over access within the Traceable platform. They define what users and service accounts can do and where those permissions apply, ensuring access remains tightly aligned with organizational responsibilities. You can assign permissions through roles and extend control by restricting those roles to specific environments. This ensures that each user and automated system operates only within the scope of resources relevant to their function. This access control model applies consistently across all platform capabilities, creating a unified framework for authorization, governance, and authorized access to platform resources.

## What will you learn in this topic?

By the end of this topic, you will be able to:

- Understand how RBAC controls access to Traceable resources.
- Differentiate between roles, permissions, and scope.
- Configure environment-level scoping to restrict access to specific resources.
- Create and manage custom roles based on your requirements.
- Manage access consistently across applications and environments.

---

## Before you begin

Before you start creating and assigning roles, you should understand Traceable’s role-based environment scoping. The following table explains why environment scoping is used, when it should be applied, and how it works within RBAC in Traceable:

| **Why use it?** | **When to use it?** | **How can you leverage it?** |
| --- | --- | --- |
| You use environment scoping to ensure users and Service Accounts access only the resources relevant to their responsibilities. It strengthens least-privilege access, reduces exposure to unrelated APIs and configurations, and enforces policy access control across environments. | You use environment scoping when a single Traceable deployment serves multiple teams, applications, or business units that require clear separation of access across environments such as development, testing, and production. | You assign one or more environments to a user, along with roles. Roles define what actions are allowed, while environment scope defines where those actions apply. This ensures policy access control is enforced by limiting policy visibility, creation, and modification strictly to authorized environments. |

---

## **Access controls**

Role-Based Access Control (RBAC) enables you to manage access to Traceable resources by assigning permissions through roles. Using RBAC, you can control which users have what permissions and access for specific platform capabilities, what actions they can perform, and the resources to which those permissions apply. For more information, see [Authentication and Users](/v1/docs/users-and-auth).

> [!NOTE]
> Note
> 
> Traceable now enables environment-based RBAC scoping.

![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/Traceable_settings_users_environment_based_scope.png)

Environment-based RBAC Scoping

---

## Definitions

- **Module-level Access** — Permission to access platform functionalities, such as *Discovery* and *API Protection*.
- **Administrative-level Access** — Permission to access application settings, such as notifications and team.
- **Base Permissions** — Minimum set of privileges you wish to assign at either of the above levels.
- **Scope** — The areas or extent to which the privileges should apply, for example, *specific environments* or *endpoints*.

Permissions in RBAC are categorized into module and administrative-level access, providing a differentiation between functional and system-level controls. For example, you may want a user to access *Discovery* and *Notifications* at the **Module** and **Administrative** levels, respectively, but not in other areas. This categorization enhances data security while preventing unauthorized access. Traceable provides a few out-of-the-box roles, such as **Account Owner** and **Security Admin**, to help you enforce RBAC. These roles, by default, are assigned specific levels of access within the platform, with the **Account Owner** being the super-user. You can also edit these roles (except *Account Owner*) to grant the privileges you wish to a user. To ensure flexibility, Traceable also supports custom roles to tailor permissions and access settings according to your business requirements. This combination ensures precise access control while promoting secure collaboration.

Traceable also allows Account Owners and users with the necessary privileges to invite team members and assign them out-of-the-box and/or custom roles. Assigning the correct role promotes the separation of duties, ensuring users have appropriate access for carrying out their responsibilities. Further, while inviting users, RBAC provides granular control through role scoping, allowing you to assign roles for specific environments, endpoints, and/or services. This allows the same user to hold multiple roles with distinct scopes, while ensuring that users can access only the resources they need to carry out their responsibilities. For more information, see [Authentication and Users](/v1/docs/users-and-auth).

> [!NOTE]
> Note
> 
> Availability of scoping may vary for each role.

Traceable’s out-of-the-box roles provide a quick way to assign standard access levels for common use cases, ensuring immediate functionality. Custom roles, on the other hand, provide the flexibility to define unique permissions and scopes tailored to your business requirements.

### Out-of-the-box roles

Traceable provides the following roles out of the box:

| Role | Description |
| --- | --- |
| **Account Owner** | An account owner manages the Traceable account, including managing users, assigning privileges, and creating roles. > [!NOTE] > Note > > A Traceable account can contain one or more account owners. |
| **Security Admin** | A security admin configures and manages security policies, investigates attack information, and monitors security events. |
| **Security Analyst** | A security analyst looks for security events and application threats. They are usually a part of the Security Operations Center (SOC) or product security teams. They must be aware of any security events as soon as they occur in your application. Security analysts can manage events and vulnerabilities, configure notifications. |
| **Global Reader** | A global reader is responsible for understanding API risk and posture, threat activity, and incidents from runtime protection, and for understanding how API testing maps to the vulnerabilities discovered in the pre-production environment. This is a read-only role that allows users to view and access the product, minimizing the risk of inadvertent actions. They will then be able to prioritize vulnerabilities that need to be addressed based on overall exposure. Users or executives interested in viewing product features and data, and who do not want to get involved in operational tasks, can also leverage this role. |
| **Developer** | A developer looks for risks or threats associated with the APIs that they have developed. |

While you can *edit* the above roles (except *Account Owner*) to modify the privileges according to your requirements, you can also create custom roles. The following section discusses the access levels in each of these roles.

### Access levels

Traceable provides role-based access control on the following levels:

![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/traceable_rbac_access_levels.png)

RBAC Levels

- **Module-level Access** — This refers to permissions for accessing specific functional areas within the Traceable platform. Each module is considered an independent unit, and you can grant or restrict access to the members while creating the role.
  - **Purpose** **of module-level access** — Focuses on providing access to particular features or components of an application, such as **Discovery** and **API Protection**.
  - **Example** — An *Analyst* role may have access to the **Analytics** module but not the **API Security Testing**.
- **Administration** — Administration-level access refers to permissions for accessing specific user management or application settings. This level oversees modules, such as **Integrations** and **Data Collection**.
  - **Purpose of administration-level access** — Focuses on managing the system's operations, settings, and user activities.
  - **Example**: An **Administrator** role may have full access to all administrative functions, including creating users, assigning roles, managing integrations, and viewing system-wide notifications.

The following section explains the permissions in each of these levels:

### Permissions

In each of the above levels, you must define the **Base Permissions**.

#### What are base permissions?

Base permissions are a set of privileges that you can assign to a role. These privileges apply to all modules within a level. For example, when you select the *View* permission under **Module-level Access**, users assigned this role can only view all functional areas within the platform, such as Sonar and API Testing.

The **Base Permission** drop-down has the following values. You can select either of them according to your requirements:

- **None** — Does not assign any privilege to users.
- **View** — This option allows users to view information in all modules' sections except Settings. For example, under Discovery, you can view the Discovery and API Risk sections, but not the **Settings** section.
- **View & Edit** — This option allows users to view and edit information in all modules except **Settings**.
- **View, Edit & Settings** — This option allows users to view and edit the information in all sections (including Settings) of the modules.

> [!NOTE]
> Note
> 
> The privileges you select as part of the **Base Permissions** are inherited automatically for all pages or modules added to the Traceable platform in the future.

#### Additional permissions

After selecting the base permissions for each level, you can also select additional permissions for each module as needed. The following table explains these permissions:

| Permission | Description |
| --- | --- |
| **View** | Allows users to access and view the information shown in the modules without making changes. For example, users assigned this permission can view the Discovery and Data Collection modules. This privilege applies to the modules you select in either of the levels mentioned above. > [!NOTE] > Note > > This permission does not allow you to view the **Settings** section of a module. |
| **Edit** (View & Edit) | Allows users to access, view, and modify the information shown in the modules. For example, users assigned this permission can mark a threat as internal under Protection or schedule a conformance analysis under Discovery. This privilege applies to the modules you select in either of the levels mentioned above. > [!NOTE] > Note > > This permission does not allow you to view or make modifications to the **Settings** section of a module. |
| **Settings** | Allows users to access, view, and modify the information shown in the **Settings**, along with other sections in the modules. For example, users assigned this role can create policies under Protection or modify risk-scoring configurations under Discovery. This privilege applies to the modules you select in either of the levels mentioned above. |

> [!NOTE]
> Note
> 
> The availability of the above permissions depends on whether or not the module contains the *Edit* or *Settings* option. For example, **Dashboard** does not contain the *Settings* option.

The following tab discusses the user and roles that help you create and assign roles, scope, and access permissions effectively:

### Steps to create roles

To create a custom role, navigate to **Settings** (![traceable_icon_settings](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/traceable_icon_settings.png)) → **Team** → **Roles** tab, click **Create Role**, and complete the following steps:

1. **Name** — Specify a name for the role, for example, *role-admin*.
2. **Description** — Specify a summary of the role description.
3. Select the checkboxes for the following according to your business requirements:
  - **Access to call detailed data** — Traceable monitors and analyzes the API activity in your application system. Based on that analysis, traces and spans are shown for APIs. This unfiltered and unprocessed (raw) data is shown across various modules in the platform. Exposing this data to all users may lead to unauthorized access and, hence, data misuse. You can select the **View** checkbox to show this raw data across the platform, but only to authorized individuals. For more information on the traces and spans, see [Explorer](/docs/explorer).
  - **Manage API access** — Traceable allows you to create API tokens to access its public APIs. Users can interact with these APIs to retrieve, send, and modify data and perform specific operations. This may lead to unauthorized access, misuse, and data leaks. You can select the **Enabled** checkbox to allow the generation of API tokens from the platform, but only to authorized individuals. For more information on API tokens, see [Public APIs](/v1/docs/public-apis).
  - **Manage Access to issues** — Traceable analyzes APIs in your application system and finds security issues (vulnerabilities) through live traffic, security testing, and compliance policies. Post-detection, these issues are shown across various modules in the platform. Exposing this data to all users may lead to information misuse or unauthorized debugging in the platform. You can select the **View** and/or **Edit** checkbox according to your requirements so that only authorized individuals can perform the necessary actions. For more information on these security issues, see [Issues](/docs/issues).
4. Select the permissions or checkboxes for the following modules according to your business requirements:
  - **Base Permissions** — The default set of privileges that you wish to assign to this role, as mentioned above. For more information, see [Permissions](/v1/docs/rbac#permissions1).
  - **Dashboards, Discovery**, **API Protection**, **Analytics**, **API Testing**, **Reports**, **Sonar** — The set of privileges you wish to assign to users over and above the base permissions, if any. For more information, see [Additional Permissions](/v1/docs/rbac#additional-permissions1).

> [!NOTE]
> Note
> 
> Traceable provides the *View* permission for Discovery by default.
5. Select the permissions or checkboxes for the following administrative-level modules according to your business requirements:
  - **Base Permissions** — The default set of privileges that you wish to assign to this role, as mentioned above. For more information, see [Permissions](/v1/docs/rbac#permissions1).
  - **Data Collection**, **Notifications**, **License**, **Team**, **Integrations** — The set of privileges you wish to assign to users over and above the base permissions, if any. For more information, see [Additional Permissions](/v1/docs/rbac#additional-permissions1).
6. Click **Save**.

---

### Manage team users and roles

You can click the **Ellipse** (![traceable_ellipse_icon](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/traceable_ellipse_icon.png)) icon corresponding to an out-of-the-box or custom role to perform the following actions:

- **View** — View the role's details, including the description and permissions.
- **Clone** — Create a copy of the role with the same permissions and descriptions. This is useful when you want to make minor modifications to a role's permissions while creating a new one.
- **Edit** — Modify the role's details, such as its description and permissions.
- **Delete** — Delete the role.

> [!NOTE]
> Note
> 
> - You cannot delete a role if one or more users are assigned to that role.
> - The *Account Owner* role cannot be deleted.
> - A deleted role cannot be restored.