> For the complete documentation index, see [llms.txt](https://docs.toucanai.cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.toucanai.cloud/embed/permissions-and-row-level-security/permission-level-overview.md).

# Permission level overview

{% hint style="info" %}
**Target Audience**: Non technical users & Developers
{% endhint %}

### TL;DR

Toucan AI utilizes a layered security framework—combining roles, granular permissions, and Row-Level Security (RLS)—to regulate access to assets and specific data rows.

***

### When to use this

Use this page to understand how Toucan AI evaluates user authorization across organizations, datasets, and dashboards before rendering data.

***

### Key Security Concepts

Toucan AI provides a multi-tenant security architecture that enforces access control at different functional levels.

* **Roles**: Define a user's default access level across the organization (e.g., admin, editor, viewer).
* **Permissions**: Specific action-based rights associated with roles, such as the ability to view, edit, or manage resources.
* **Row-Level Security (RLS)**: A dynamic filtering mechanism that ensures users only access specific rows within a dataset based on their unique attributes.
* **Scopes**: The boundary where permissions are applied, ranging from entire organizations to individual datasets or dashboards.

***

### The Permission Evaluation Process

When a user initiates a request, Toucan AI validates authorization through a sequential check:

1. **Organization-level**: Verifies membership and general resource access within the organization.
2. **Dataset-level**: Determines if the user is authorized to query the underlying data source or specific tables.
3. **Dashboard-level**: Validates whether the user can view or modify the specific visualization layout.
4. **Row-level**: Injects dynamic SQL filters into the query based on user attributes (e.g., department, region) to restrict data output.

***

### Implementation Example: Role and RLS Integration

Consider a single "Sales" dashboard accessed by two different users:

| User Role         | Security Configuration                   | Data Visibility                                                   |
| ----------------- | ---------------------------------------- | ----------------------------------------------------------------- |
| **Sales Manager** | High-level Role                          | Authorized to view data across all regions.                       |
| **Sales Rep**     | Role + RLS Attribute (`region: 'North'`) | Restricted to viewing only data rows where the region is 'North'. |

***

### Practical Benefits

* **Data Isolation**: Safely distribute analytics to different teams or external customers within a single dashboard.
* **Compliance**: Maintain strict adherence to privacy requirements by preventing unauthorized data exposure.
* **Access Precision**: Provide users with the exact functional rights required for their specific tasks.