Roles

Fanout has three roles. They are fixed — there is no custom role builder, and a user holds exactly one.

Every protected route names a capability rather than a role, and a role is a set of capabilities. The table below is that set, read from the same map the middleware consults, so it cannot describe a permission the server does not grant.

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 chat investigator, 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 covers the details, including why the last active administrator is never demoted.

A role is not a data boundary

Roles gate capabilities, not rows. Every role that can read telemetry can read all of it — namespaces scope queries, not access. An instance is one trust domain.