The five roles, the page-visibility matrix that narrows them, and what the capability model does and does not enforce.

Access Control decides which roles are offered which pages. The role set is fixed at five and cannot be extended; what you edit here is a subtraction from what each role's API access already allows.

What do I need?

Licence: Any
Role: superadmin

Prerequisites

You are signed in as the superadmin. A viewer can open this page read-only; every other role is redirected away from this address.
The accounts whose access you want to narrow already exist under Tenant Management.

How access is decided

Three independent questions answer whether a person can use a page.

Question	Decided by	Editable here
Does this appliance have the module at all?	The installed licence tier	No
Does this role reach the API behind the page?	The `@Roles` requirement on the controller	No
Should this role be offered the page?	This matrix	Yes

The matrix only ever takes access away. A role the API never admitted cannot be granted a page here, and denying a page hides it from the sidebar and redirects anyone who types its address — it does not change what the API answers.

The five roles

Role	What it is	Read-only
`superadmin`	The appliance owner. Holds every capability, can never be denied a page, and is the only role that manages accounts and this matrix	No
`admin_user`	Day-to-day administration: security policy, detections, compliance, governance, channels. Reads its own account and the members of groups it owns	No
`normal_user`	An end user of the gateway. No administrative access; reads only its own data	No
`viewer`	A read-only demo account. Satisfies any role requirement on a safe HTTP method and is refused every mutating request with `READ_ONLY_ROLE`	Yes
`auditor`	An external reviewer. Reads compliance and governance evidence across every account, never message content, and is refused the chat with `ROLE_NOT_FOR_CHAT`	No, but it changes almost nothing

The full role × capability × page table is generated from the code — see Roles, capabilities and pages.

Warning

The capability model is computed and compared on every request and enforces nothing. What decides a request today is the role requirement on the controller; what decides navigation is this matrix. There is no capability editor in the dashboard, and enforce is refused as a stored value. Do not plan a separation of duties around capabilities that no request consults.

Screenshot pendingAccess Control matrix with pages grouped by section and a checkbox per role column/assets/screenshots/access-control@0.4.png

Narrow a role's page access

Open the matrix

Select Administration → Access Control.

Rows are the dashboard's pages, grouped under section bands — Overview, AI inventory, Detection & filtering, Security & compliance, Governance, Access management, Endpoints, Reporting, Testing lab, System. Columns are the five roles: Superadmin, Admin, User, Viewer, Auditor.

Read the cells before you change one

Each cell is either a checkbox, a locked checkbox, or an em dash.

A ticked checkbox — the role is offered the page.
An em dash with the tooltip The API does not allow this role here — the role could never open the page, so there is nothing to take away.
A permanently ticked Superadmin cell — superadmin can never be denied, because the role that edits this table must not be able to lock itself out.
A dimmed row with Not in this licence tier — nobody can open this page on this installation — the module is not in the installed licence.

Untick the pages you want hidden

Clear the checkbox in the role's column for each page that role should not be offered.

The amber note You have unsaved changes appears. Nothing has been sent yet — every change goes out as one save.

Save

Select Save changes.

The toast Page access updated confirms it, the Last updated timestamp refreshes, and the sidebar of anyone holding that role loses those entries on their next page load.

To abandon an edit, select Discard. That reverts to the state currently stored on the appliance; it is not a reset to the shipped defaults, and the dashboard offers no such reset.

Give an account a different role

Roles are assigned on the account, not here.

Edit the account

Select Administration → Tenant Management, open the account, and set Role.

See Manage users for the whole procedure. The change takes effect the next time that account signs in and its page manifest is fetched.

What the viewer role can and cannot do

viewer exists for read-only demonstrations. It reaches every read on the appliance, including pages that admin_user cannot open, and every request that is not a safe method is refused globally — not endpoint by endpoint — with the message This is a read-only demo account (viewer role) — actions and changes are disabled. and the code READ_ONLY_ROLE. A viewer carries a Read-only demo chip beside the wordmark on every page, and a Read-only demo view banner on the handful of pages where a demonstration dataset could be mistaken for a complete one.

Two consequences worth knowing:

A viewer sees data scoped as a global reader, so its lists are wider than an admin_user's.
The chat is excluded from a viewer at the backend rather than by this matrix, because running a conversation spends provider credit.

Fields reference

Control	What it does
Checkbox in a role column	Ticked = the role is offered the page. Cleared = denied
Superadmin column	Always ticked and disabled
Em dash cell	Outside the page's baseline: The API does not allow this role here
Dimmed row	Not licensed on this appliance. Your setting is kept and applies if the tier is added
Save changes	Sends the whole denial table as one write
Discard	Reverts the buffer to the stored table
Last updated	When the stored table was last written. Shown once an operator has saved the table at least once and there are no unsaved changes; a table still on its shipped defaults shows nothing

Verify

The Last updated timestamp reflects your save and the You have unsaved changes note is gone.
Open Event logs. A matrix save writes a RESOURCE_UPDATED row recording the table before and after, and who wrote it — the same before/after treatment an account edit gets on Manage users.
Sign in as an account holding the narrowed role. The denied pages are absent from the sidebar, and typing one of their addresses lands the account on its fallback page rather than on the page.

If it fails

Could not update page access — the save was refused for a reason the dashboard could not classify. Reload the page and read the specific message. Every cause below produces this toast except the concurrent-edit conflict, which has its own message.
Someone else changed page access while this screen was open. The table has been reloaded with their change — review it and save again. — another administrator saved between your load and your save. This is the gateway's PAGE_ACCESS_STALE conflict; nothing of yours was written and nothing of theirs was overwritten.
superadmin access cannot be removed — it is the role that edits this table — a save tried to deny the superadmin. The dashboard's superadmin checkboxes are disabled, so this appears only for a scripted call.
Unknown page: {id} or Unknown role: {role} — a scripted save named something the registry does not define. The whole save is rejected rather than the unknown entry silently dropped.
You have unsaved page access changes. Leave without saving? — not a failure: you are navigating away with an unsaved edit.
A page you expected is missing from the matrix — it is not in the page registry, so it is not governed by the matrix and stays reachable to whoever the API admits.

Next steps

Manage users — assign the roles this matrix narrows.
Tenant groups — scope an admin_user to a department.
Roles, capabilities and pages — the generated table of every role, capability and page.

Access control