Roles & Permissions
The five permission levels in Palveron — who can see what, who can change what.
Palveron has five permission levels. Each one is a strict superset of the lower ones — except platform_admin, which is reserved for Palveron staff and not assignable by customers.
The five levels
| Level | Who | Granted by |
|---|---|---|
platform_admin | Palveron support staff | Palveron (cannot be assigned in the dashboard) |
owner | Customer organization owners | Project creation; transferable via support |
admin | Platform admins inside the customer org | Owner or admin |
editor | Compliance officers, MLOps, security engineers | Admin |
viewer (default) | Everyone else | Implicit on user invitation |
The five levels are also what useAccess().isAdmin(), canEdit(), canView() resolve against in the frontend, so the dashboard sidebar and per-page actions filter accordingly — users only see what they can act on.
Permission matrix
| Capability | platform_admin | owner | admin | editor | viewer |
|---|---|---|---|---|---|
| Project & billing | |||||
| Create projects | ✅ | ✅ | — | — | — |
| Manage billing / contracts | ✅ | ✅ | ✅ | — | — |
| Transfer ownership | ✅ | ✅ | — | — | — |
| Delete project | ✅ | ✅ | — | — | — |
| Team & access | |||||
| Invite members | ✅ | ✅ | ✅ | — | — |
| Assign roles | ✅ | ✅ | ✅ | — | — |
| Connect identity provider | ✅ | ✅ | ✅ | — | — |
| Agents | |||||
| Register / approve agents | ✅ | ✅ | ✅ | ✅ | — |
| Pause / resume / suspend | ✅ | ✅ | ✅ | ✅ | — |
| Revoke (terminal) | ✅ | ✅ | ✅ | — | — |
| Emergency stop | ✅ | ✅ | ✅ | — | — |
| Policies | |||||
| Create / edit policies | ✅ | ✅ | ✅ | ✅ | — |
| Activate / deprecate policies | ✅ | ✅ | ✅ | ✅ | — |
| Compliance | |||||
| Export Annex IV PDF | ✅ | ✅ | ✅ | ✅ | ✅ |
| Complete FRIA | ✅ | ✅ | ✅ | ✅ | — |
| Report incidents | ✅ | ✅ | ✅ | ✅ | — |
| Monitoring | |||||
| View Command Center | ✅ | ✅ | ✅ | ✅ | ✅ |
| Search traces | ✅ | ✅ | ✅ | ✅ | ✅ |
| Record user actions on traces (WARN_PROCEEDED, JUSTIFIED) | ✅ | ✅ | ✅ | ✅ | — |
| Integrations | |||||
| Connect Slack / Teams / ServiceNow / Jira | ✅ | ✅ | ✅ | — | — |
| Configure blockchain wallet | ✅ | ✅ | ✅ | — | — |
| System | |||||
| View admin panel | ✅ | ✅ | ✅ | — | — |
| Rotate project API key | ✅ | ✅ | ✅ | — | — |
| Configure NGE / sensitivity preset | ✅ | ✅ | ✅ | — | — |
Role mapping from external systems
When you connect an identity provider (Entra ID, Google Workspace, Okta), Palveron maps IdP groups to these levels — see Configure IdP. The mapping is one-way: changes in the IdP propagate to Palveron, but Palveron does not write back.
How roles work together
A typical workflow inside an enterprise:
- The owner or an admin creates the project, wires up Stripe billing, and connects the identity provider.
- An admin invites a compliance officer (assigned
editor) and a developer (assignedviewer). - The editor registers a new agent in the wizard, classifies it per the EU AI Act, and creates the policies.
- After the wizard completes, the platform generates an agent API key. The editor hands the key (or the integration URL) to the developer.
- The viewer developer integrates the key into their application — they can copy the key, search traces (for debugging), and use the playground, but they cannot change policies or agent state.
- When a policy triggers "approval required," an editor (or higher) receives a Slack / Teams notification and approves or denies. The decision is anchored on Flare.
Connection status — the green / yellow / red badge on the Agents page makes the handoff between editor (registered) and developer (technically connected) visible at a glance.
Sidebar filtering
The dashboard sidebar respects the permission matrix: a viewer never sees menu items for billing, team, integrations, or settings — they're hidden, not just disabled. This keeps the UI focused and prevents accidental clicks on actions the user can't perform.
Assigning roles
Roles are assigned by an owner or admin under Team. When an identity provider is connected, IdP groups are mapped automatically (see Configure IdP).