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

# Role-Based Access Control

> Role hierarchy, permission matrix, and enforcement rules for Quint organizations

Every member of a Quint organization is assigned exactly one role. Roles are hierarchical -- higher roles inherit all permissions of lower roles.

## Role Hierarchy

```
Owner (3)
  └── Admin (2)
        └── Analyst (1)
              └── Viewer (0)
```

Each role has a numeric level. Permission checks compare the required level against the user's role level.

## Permission Matrix

| Action                              | Owner | Admin | Analyst | Viewer |
| ----------------------------------- | :---: | :---: | :-----: | :----: |
| View dashboards, sessions, events   |  Yes  |  Yes  |   Yes   |   Yes  |
| View fleet status and agent details |  Yes  |  Yes  |   Yes   |   Yes  |
| View analytics and reports          |  Yes  |  Yes  |   Yes   |   Yes  |
| Acknowledge alerts                  |  Yes  |  Yes  |   Yes   |   --   |
| Investigate sessions                |  Yes  |  Yes  |   Yes   |   --   |
| Triage and dismiss alerts           |  Yes  |  Yes  |   Yes   |   --   |
| Manage policies                     |  Yes  |  Yes  |    --   |   --   |
| Manage device groups                |  Yes  |  Yes  |    --   |   --   |
| Manage enforcement profiles         |  Yes  |  Yes  |    --   |   --   |
| Invite and remove team members      |  Yes  |  Yes  |    --   |   --   |
| Create and revoke tokens            |  Yes  |  Yes  |    --   |   --   |
| Manage fleet settings               |  Yes  |  Yes  |    --   |   --   |
| Configure SSO                       |  Yes  |   --  |    --   |   --   |
| Manage billing                      |  Yes  |   --  |    --   |   --   |
| Delete organization                 |  Yes  |   --  |    --   |   --   |
| Transfer ownership                  |  Yes  |   --  |    --   |   --   |

## Enforcement

Role checks happen at two layers:

### API Middleware

Every authenticated request passes through role-checking middleware. The middleware extracts the user's org membership and compares the role level against the endpoint's required level.

```typescript theme={null}
// Simplified enforcement logic
function requireRole(minRole: RoleLevel) {
  return (req, res, next) => {
    const membership = req.orgMembership;
    if (membership.role_level < minRole) {
      return res.status(403).json({ error: "insufficient_permissions" });
    }
    next();
  };
}
```

### Dashboard UI

The dashboard hides UI elements the user can't act on. This is cosmetic -- the API enforces the real boundary. A viewer won't see the "Create Policy" button, but even if they craft the request manually, the API rejects it.

## Role Assignment Rules

<Warning>
  You cannot assign a role **higher** than your own -- but you can assign your own. An admin can invite and promote other admins, as well as analysts and viewers. Only an owner can create another owner.
</Warning>

The assignment matrix:

| Assigner | Can assign                    |
| -------- | ----------------------------- |
| Owner    | Owner, Admin, Analyst, Viewer |
| Admin    | Admin, Analyst, Viewer        |
| Analyst  | -- (cannot invite)            |
| Viewer   | -- (cannot invite)            |

## Owner Protection

The last owner of an organization cannot be removed or downgraded. This prevents an org from becoming unmanageable.

* If there's only one owner, they can't change their own role
* If there's only one owner, no one can remove them
* Ownership transfer requires explicitly assigning owner role to another member first

<Note>
  To transfer ownership: promote another member to owner, then (optionally) downgrade yourself. The org must always have at least one owner.
</Note>

## Role Changes

When a member's role changes:

1. The update takes effect immediately on the next API request
2. Active dashboard sessions reflect the new permissions on the next navigation or data fetch
3. Existing tokens created by the member retain their scopes (token permissions are independent of role)

<Tip>
  Revoking a member's access? Remove their membership entirely rather than downgrading to viewer. This also invalidates any personal tokens they created.
</Tip>