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

# Roles & Permissions (RBAC)

Avigrah uses a **Role-Based Access Control (RBAC)** system to ensure that every user has the right level of access — no more, no less.

Access is controlled at two levels:

* **Organization Level** → Who can manage the system
* **Project Level (via Teams)** → Who can use the AI

This separation ensures both **security** and **clarity of responsibility**.

***

## How Access Works

Avigrah separates users into two categories:

### 1. System Operators (Organization Level)

These users **build, manage, and control AI systems**

### 2. AI Consumers (Project Level via Teams)

These users **interact with AI and consume outputs**

This ensures:

* Builders don’t interfere with consumers
* Consumers don’t access system internals

***

## Role Overview

### Owner

The Owner has **full control over the organization**.

* Manages billing, security, and ownership
* Can create and manage all resources
* Has unrestricted system access

Best suited for:

* Founders
* Business owners
* Primary stakeholders

***

### Admin

Admins manage the **day-to-day operations** of the system.

* Manage users, teams, and projects
* Configure pipelines and integrations
* Monitor system activity

Limitations:

* Cannot manage billing
* Cannot delete the organization

Best suited for:

* Team leads
* Operations managers

***

### Operator

Operators are responsible for **running and maintaining AI workflows**.

* Build and run pipelines
* Execute AI workflows
* Monitor logs and outputs

Limitations:

* No control over organization settings
* No billing or ownership permissions

Best suited for:

* Data/AI operators
* Technical execution teams

***

### AI Consumer

AI Consumers **interact with AI**, but do not manage the system.

* Use chat and AI interfaces
* Trigger tasks and workflows
* View insights and outputs

Limitations:

* No access to system configuration
* No visibility outside assigned projects

Best suited for:

* Business users
* Relationship managers
* Decision-makers

***

## Access Scope

### Organization-Level Access

Roles like **Owner, Admin, and Operator** are assigned at the organization level.

They can:

* See system-wide resources
* Manage infrastructure
* Control execution and workflows

***

### Project-Level Access (via Teams)

AI Consumers do **not get direct system access**.

Instead:

* Users are added to **Teams**
* Teams are assigned to **Projects**
* Access is restricted to only those projects

This means:

> A user can only see and interact with AI outputs from the projects they are assigned to.

***

## Why This Model Matters

This structure ensures:

### Security

Sensitive data and configurations are protected

### Clarity

Clear separation between builders and users

### Scalability

Easily manage multiple teams, clients, and use cases

### Control

Every action is permission-based and auditable

***

## Permission Model

Instead of exposing technical permissions, Avigrah groups access into functional capabilities:

| Area                    | What It Controls                 |
| :---------------------- | :------------------------------- |
| Organization & Security | Settings, ownership, compliance  |
| Billing                 | Usage tracking and payments      |
| Projects                | AI use cases and configurations  |
| Teams                   | User grouping and access control |
| Pipelines               | Data processing and preparation  |
| Integrations            | External system connections      |
| AI Execution            | Tasks, workflows, and automation |
| Monitoring & Logs       | System activity and debugging    |
| Data Sources            | Data connections and credentials |
| AI Interaction          | Chat, insights, and outputs      |

***

## Advanced Permissions

Each role is backed by a detailed permission system that controls:

* What actions a user can perform
* What data they can access
* What systems they can modify

These permissions are enforced **at runtime**, not just in the interface.

> For most users, understanding roles and access scope is sufficient.\
> Detailed permissions are only relevant for advanced configuration.

***