---
summary: ScaiPersona module permissions and which roles get them by default.
title: Permissions
path: reference/permissions
status: published
---

ScaiPersona defines three module-permission keys, mapped onto ScaiGrid's RBAC system. The module's CRUD endpoints all run under the standard tenant-admin / partner-admin / super-admin catch-alls; invocation of a published persona is governed by the underlying inference permissions, not by ScaiPersona.

## Permission keys

| Key | What it grants |
|---|---|
| `scaipersona:view` | List personas, read persona config, list attached sources, view ScaiDrive shares. |
| `scaipersona:manage` | Create, update, delete personas; attach / update / detach sources; upload avatars; publish and unpublish. |
| `scaipersona:test` | Reserved for the admin-UI test playground (no public endpoint at present). |

## Default role mapping

Built-in roles auto-grant these via ScaiGrid's catch-all in `CurrentUser.has_module_permission`:

| Role | Auto-grants |
|---|---|
| `super_admin` | All of the above; can also assign published personas to global / partner / cross-tenant model groups. |
| `partner_admin` | All of the above for tenants under the partner; can add to partner-scoped model groups. |
| `tenant_admin` | All of the above for the tenant; can add to tenant-scoped model groups. |
| `tenant_user` | None by default. |
| `tenant_viewer` | `scaipersona:view`. |

The group-assignment scope check on publish is enforced server-side regardless of role — passing `group_ids` for groups outside your scope silently drops them rather than erroring.

## Invoking a published persona

Once published, a persona is a frontend model. Calling it through `/v1/inference/chat` requires `models:use`, just like any other model. The persona-level `scaipersona:*` permissions are not consulted on invocation — RAG access enforcement happens via the caller's own collection access (for ScaiMatrix sources) and the caller's own token exchange (for ScaiDrive sources).