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 | ✅ | ✅ | ✅ | — | — |
| Manage contracts | ✅ | ✅ | — | — | — |
| Transfer ownership | ✅ | ✅ | — | — | — |
| Take project out of service | ✅ | ✅ | ✅ | — | — |
| Team & access | |||||
| Invite members | ✅ | ✅ | ✅ | — | — |
| Assign roles | ✅ | ✅ | ✅ | — | — |
| Agents | |||||
| Register agents | ✅ | ✅ | ✅ | ✅ | — |
| Approve / reject agents | ✅ | ✅ | ✅ | — | — |
| Pause / resume / suspend / reactivate | ✅ | ✅ | ✅ | — | — |
| Revoke (terminal) | ✅ | ✅ | ✅ | — | — |
| Project emergency stop (set / lift) | ✅ | ✅ | ✅ | — | — |
| View emergency stop state | ✅ | ✅ | ✅ | ✅ | ✅ |
| Policies | |||||
| Create / edit policies | ✅ | ✅ | ✅ | ✅ | — |
| Activate policies | ✅ | ✅ | ✅ | ✅ | — |
| Archive (retire) policies | ✅ | ✅ | ✅ | — | — |
| Compliance | |||||
| Export Annex IV PDF | ✅ | ✅ | ✅ | ✅ | — |
| Complete FRIA | ✅ | ✅ | ✅ | ✅ | — |
| Report incidents | ✅ | ✅ | ✅ | ✅ | — |
| Monitoring | |||||
| View Command Center | ✅ | ✅ | ✅ | ✅ | ✅ |
| Search traces | ✅ | ✅ | ✅ | ✅ | ✅ |
| Note on an overridden browser warning (written by Palveron Guard at the moment of the warning, never from the dashboard) | — | — | — | — | — |
| Integrations | |||||
| Connect Slack | ✅ | ✅ | ✅ | — | — |
| Configure blockchain wallet | ✅ | ✅ | ✅ | — | — |
| System | |||||
| View admin panel | ✅ | — | — | — | — |
| Rotate project API key | ✅ | ✅ | ✅ | — | — |
| Configure the checking engine | ✅ | ✅ | ✅ | — | — |
How roles work together
A typical workflow inside an enterprise:
- The owner or an admin creates the project and wires up Stripe billing.
- 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, registration does not issue an agent key; every request authenticates with the project key (
pv_live_...). The editor hands the integration details to the developer. - The viewer developer integrates the project key into their application and attributes calls with
metadata.agent_id; they can search traces (for debugging) and use the playground, but cannot change policies or agent state. - When a policy requires approval, a message goes to your Slack channel if you have connected Slack, and an Admin approves or denies. The decision is recorded as proof.
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 sees no menu items for billing, team, or settings (hidden, not just disabled); the integrations page is visible to viewers too. This keeps the UI focused and prevents accidental clicks on actions the user cannot perform.
Assigning roles
Roles are assigned by an owner or admin under Team.