---
title: "Roles"
summary: "viewer, operator and admin, and what each is permitted to do."
description: "The three Fanout roles and the capabilities each one carries."
status: preview
generated: true
read_when:
  - "You are deciding which role to give someone."
  - "You are mapping identity-provider groups onto Fanout roles."
  - "A request came back 403 and you want to know which capability it needed."
---

Each user has one fixed role: `viewer`, `operator` or `admin`.

| Capability | viewer | operator | admin |
|---|---|---|---|
| `agent:run` | ✓ | ✓ | ✓ |
| `alerts:manage` | — | ✓ | ✓ |
| `dashboards:manage-own` | ✓ | ✓ | ✓ |
| `ingest:manage` | — | — | ✓ |
| `ingest:read-metadata` | ✓ | ✓ | ✓ |
| `operations:read` | — | — | ✓ |
| `telemetry:read` | ✓ | ✓ | ✓ |
| `users:manage` | — | — | ✓ |

## What each capability permits

- `agent:run`: Run the built-in agent, which calls a model provider and acts on the instance's behalf.
- `alerts:manage`: Create, change and delete alert rules.
- `dashboards:manage-own`: Create and edit dashboards you own. Owner-scoped for every role, including admin.
- `ingest:manage`: Rotate the ingest token.
- `ingest:read-metadata`: See ingest settings, but not the token itself.
- `operations:read`: Read the instance's own internals: Prometheus metrics and, when enabled, the profiling endpoints.
- `telemetry:read`: Read every trace, log and metric the instance holds.
- `users:manage`: Create, change and remove user accounts and their roles.

## Who assigns roles

In `local` auth mode, roles are managed inside Fanout by an admin.

In `oidc` mode it depends on configuration. If `FANOUT_OIDC_ADMIN_GROUPS` or
`FANOUT_OIDC_OPERATOR_GROUPS` is set, the provider owns every linked user's
role and reapplies it on each login; otherwise roles stay local.
[Authentication modes](/docs/concepts/authentication) covers the details,
including why the last active administrator is never demoted.

> **Telemetry access**
>
> See [namespace access limits](/docs/reference/capabilities#operating-limits).