Roles, approvals, moderation & audit
This page brings together four Web UI screens that decide who may do what and how risky actions are controlled: Roles, Approvals, Moderation and Audit.
Where to start: baseline security setup
If you have just launched, a sensible minimum is three actions:
- Assign roles to people. On the “Roles” screen give each person a suitable
role:
owner/admin/operator/member. A role drives both permissions and tab visibility. Built-in roles can’t be changed — if needed, create your own with the right permission grid. - Turn on approval of risky actions. Configure which tool calls need confirmation (see Approvals) — such actions then land in the queue on the “Approvals” screen and won’t run without your “Approve”.
- Set forbidden topics. On the “Moderation” screen, list the topics the agent must refuse — one per line.
Networking, separately. Restricting admin-UI access by IP (an IP allowlist) and
network isolation are configured not here but described in
Network, audit & air-gapped; enabling
enterprise SSO to protect /admin/* is in
First login.
Roles
The “Roles” screen manages RBAC roles. Built-in roles are read-only (a
“builtin” badge); a role that is in use can’t be deleted. Human-assignable roles
are owner, admin, operator, member.
Creating/editing a role is a modal with a name, description and a permission
checkbox grid: Read and Write columns per domain. Write implies read.
Permissions are stored as domain:read / domain:write / domain:* (or * for
everything). Each role shows its in-use count and a domain preview. A role is what
drives tab visibility.
Approvals
The “Approvals” screen is a queue of pending risky tool calls. Each row: a warning shield, the tool name, truncated arguments (Details expands the full JSON), and Approve / Reject buttons. A rejected call is not executed. If the approval gate is disabled, the screen shows a friendly empty state. Configuring which tools need approval is covered in Approvals.
After a managed-cloud administrator password reset
The cloud reset changes only the bootstrap admin account’s password and closes
that account’s active sessions. It does not change other users, roles, SSO
settings or API keys. Sign in again with the one-time password shown by the
customer portal.
For a self-hosted instance, use the local
aihummer set-password procedure
instead; the customer portal does not rotate a self-hosted credential.
Moderation guardrails
The “Moderation” screen is a single textarea of forbidden-topic patterns, one
per line. Saving strips blank lines. The agent must refuse the listed topics.
It is a simple, hard barrier on top of agent behavior; for its relationship to
refusal_style see the agent profile.
Audit
The “Audit” screen is a paginated action log (50 rows per page, “previous / next”, a “from–to / total” counter). It is a provable history of changes and sensitive operations. Audit needs the Business plan or higher; on Community the screen shows an upgrade prompt, not an error.
Next
- RBAC — the full permission model.
- Approvals — the human-approval gate.
- Guardrails and Audit.