# Access Management Key Concepts


This guide covers the key concepts and terms related to the design and functionality of RudderStack's Access Management system.

## Policy-based Access Control (PBAC)

RudderStack's Access Management system is based on **Policy-based Access Control (PBAC)**.

{{< info >}}
Policy-based Access Control (PBAC) allows Admins to define granular permissions for resources and actions, and assign them to users directly via an [access policy](#access-policy).
{{< /info >}}

## Additive permissions model

The Access Management system follows an **additive permissions model**, meaning permissions from the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}), [Group Workspace Policies]({{< ref "access-management/groups.md" >}}), and [Member Workspace Policy]({{< ref "access-management/members.md" >}}) are combined.

Inherited permissions from lower levels cannot be removed at higher levels. Access only expands — **it does not contract**.

For example:

- A baseline workspace policy might grant **Edit** permission on **Event Stream Sources**.
- A group workspace policy might grant **Connect** permission on **Event Stream Sources**.
- A member workspace policy might grant **Create & Delete** permission on **Event Stream Sources**.

The member's effective [access policy](#access-policy) would then include all three permissions for **Event Stream Sources**.

## Permission

A **permission** defines a specific action a user can take, like **Edit**, **Connect**, or **Create & Delete**. Permissions are the most granular building blocks of access and always refer to actions on specific resources, like sources, destinations, transformations, etc.

{{< info >}}
Permissions **do not** grant access by themselves — you must assign them to members via an [access policy](#access-policy).
{{< /info >}}

## Access policy

A member's **access policy** is the effective set of permissions they have in a workspace. It is computed by aggregating:

- The [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}})
- Any [Group Workspace Policies]({{< ref "access-management/groups.md" >}})
- The member's [Member Workspace Policy]({{< ref "access-management/members.md" >}})

## Workspace policy

A **workspace policy** is a named bundle of permissions. Policies can be:

- Applied as **Baseline**, applicable to the entire workspace
- Assigned to **Groups** created within the workspace
- Assigned to individual **Members** in the workspace

Each policy defines what members can and cannot do in the given workspace.

### Baseline Workspace Policy

Every workspace has **one baseline policy** that applies to all groups and members. This ensures consistent baseline access for all users, such as view-only permissions for resources or restricted access to PII.

Unless otherwise configured by an Admin, the baseline workspace policy is set to:

- **View-only** for [resources]({{< ref "access-management/policies-overview.md#resource-permissions" >}}) 
- **No access** to [PII views]({{< ref "access-management/policies-overview.md#pii-permissions" >}}) in [Enterprise](https://www.rudderstack.com/enterprise-quote/) plan
- **Full** PII access to all members in **non-Enterprise** plans

### Group policies

Each group can have one workspace policy configured per workspace. Members of the group will inherit all permissions from both:

- [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}})
- [Group Workspace Policy]({{< ref "access-management/groups.md" >}})

This allows Admins to create custom roles and share consistent access patterns without manual duplication.

### Member policies

You can customize and configure a workspace policy for an individual member. This policy **extends** permissions from the [Baseline Workspace Policy]({{< ref "access-management/baseline-workspace-policy.md" >}}) and [Group Workspace Policies]({{< ref "access-management/groups.md" >}}) — it does not override them.

<br />