Settings

Settings is the appliance's configuration surface. The page header describes it as Manage your account, how detection behaves, and who can get in. — three groups of panes in a left-hand navigation, and every pane is a separate saved configuration with its own API endpoint behind it.

Screenshot pendingSettings with the three navigation groups — Account, Detection & processing, Identity & access — and the Profile pane open/assets/screenshots/settings-overview@0.4.png

What lives under Settings

Account

Every signed-in account reaches these three, whatever its role.

Detection & processing

Identity & access

Two system pages sit beside Settings rather than inside it: License and System updates.

Who can change what

Access to Settings is decided in two independent places, and both have to agree before a change lands.

The dashboard decides which panes are listed. Nine configuration panes are shown only to superadmin and to viewer, its read-only twin:

• ML Worker Tuning, Model Routing, Prompt Compression, Document Redaction
• Data Retention, SIEM Export, Help assistant, Certificates
• Password delivery

The reasoning is recorded in the code rather than left to convention: retention can delete evidence, SIEM export ships detection metadata off the box, and the help-assistant pane decides whether everyone's help questions on this appliance are inspected. All three are appliance-wide, so all three sit on the same list.

An auditor account sees the Account group and nothing else. It reaches Settings for exactly one reason — changing the password it was seeded with — and every other group would render links that refuse to open.

The API decides whether the change is accepted. Each pane's endpoint carries its own role requirement, and it applies regardless of what the dashboard drew:

A viewer account is refused every mutating request globally, by the shape of the request rather than by which endpoint it called. The refusal carries the code READ_ONLY_ROLE, and the panes render read-only with a Read-only demo view notice.

Limits and known gaps

Per-pane access is not access control. The page registry holds one settings row whose baseline admits every role, so the registry cannot gate a pane. The nine-pane superadmin list is a hard-coded array in the dashboard shell, mirrored by a drift check in the gateway. It hides links; it does not deny anything. Treat the endpoint's role requirement as the boundary.

The two halves disagree in both directions today. The dashboard hides Certificates, Data Retention, SIEM Export and Help assistant from an admin_user, although the gateway accepts that role on all four — an administrator has to be superadmin to reach them through the interface, or call the API directly. In the other direction the four identity panes are listed for normal_user, whose requests those endpoints then refuse.

Capabilities are declared, not enforced. Most settings endpoints also declare a capability — system.certificates, retention.view and retention.manage, ldap.configure, password_delivery.configure, integrations.manage. The help-assistant pane is the exception: help.configure exists in the capability registry, but neither handler that writes help settings carries the decorator, so shadow mode does not watch them at all. The capability model runs in shadow mode: it computes what it would have decided, records the comparison, and decides nothing. Requesting the enforcing mode is refused and runs as shadow. Roles are what enforce.

Related tasks

• Certificates — serve a certificate your clients already trust.
• Active Directory and LDAP — sign users in with their domain accounts.
• Access control — the five roles, what each may read, and the page matrix.