Permissions
Permissions control access to administrative features and protected routes in Nairo.
This page describes the current permission model used in the workspace application.
How permissions work today
Nairo uses a permission model checked at the route level.
Routes can declare required permissions. If a user does not have the required permission, the protected area is not shown or access is blocked.
The primary permission in use today is:
| Permission | Purpose |
|---|---|
auth:user_management | Access to the user management area, including inviting users and changing roles |
This model is currently focused on administrative access rather than fine-grained product-level controls.
Administrator vs member
Permission assignment is currently derived from the user’s organisation role.
The main practical distinction is:
- Organisation administrators - users with administrative permissions, including user management
- Members - users who may access product surfaces available to their workspace and role, but do not access administrative pages in the current implementation
Product surfaces may include:
- Assistant
- Projects
- Experts
- Actions
- Insight Table
- Library
The exact access available to a user depends on the workspace configuration, assigned role and enabled permissions.
Library sharing
Library document and folder sharing uses a separate sharing model.
This means access to a shared document or folder can be controlled at the resource level, separately from the route-level permission model described above.
For example, a user may have access to the Library surface but only see the folders or documents that are available to them.
Current limitations
The current permission model does not provide full fine-grained access control across every product feature.
For example, it does not currently provide:
- Custom role creation by customer administrators in the UI
- Fine-grained per-feature permissions for every product surface
- A centralised customer-facing audit log of permission changes
- A complete policy engine for document, workflow and feature access
The permission model is expected to evolve as customer administration requirements become more granular.
What permissions are not
Permissions do not replace the customer’s internal access governance process.
They do not decide who should be authorised to review, approve or use AI-generated outputs in business workflows.
They do not replace internal compliance, approval or authority processes.
Customer administrators remain responsible for deciding which users should have access to the workspace and which internal rules apply to use of the product.
Related areas
- Users and Roles - inviting users and assigning roles
- Workspace Setup - preparing a workspace
- Tenant Isolation - workspace and tenant boundaries
- Library - document and folder sharing
- Security Overview - authentication and access model
Getting started
Start by identifying who needs administrative access.
For most pilot workspaces, this is usually limited to IT administrators, team leads or operational owners responsible for onboarding users.
Assign administrative access only to users who need to manage invitations, roles or workspace access.