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.
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.
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.
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**.
## 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](/en/v1.0/webui/overview#role-based-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](/en/v1.0/security/approvals).
## 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](/en/v1.0/webui/agents#behavior-sections).
## 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](/en/v1.0/security/rbac) — the full permission model.
- [Approvals](/en/v1.0/security/approvals) — the human-approval gate.
- [Guardrails](/en/v1.0/security/guardrails) and
[Audit](/en/v1.0/operations/observability).
