> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # Roles and permissions > The five aiAxonIQ roles, exactly what each one can do, the Auditor role that is not a rung on the ladder, and the rules on who may grant what. Every membership carries one role, and the role is resolved from your signed session — never from a header, a query parameter or a field in the request body. There is no client-side permission model to bypass. ## The five roles | Role | Can do | | :---------- | :----------------------------------------------------------------------------------------------------------------------------------- | | **Viewer** | Read dashboards, logs, metrics, traces, services, alerts and synthetic results. Change nothing. | | **Auditor** | Everything a Viewer can, **plus** read the audit log and export it. Change nothing. | | **Editor** | Everything a Viewer can, plus create and edit product configuration: dashboards, alert rules, SLOs, synthetic checks, saved queries. | | **Admin** | Everything an Editor can, plus manage users and their roles, license keys, billing, and read the audit log. | | **Owner** | Everything an Admin can, plus organization lifecycle — creating organizations, and granting the Owner role itself. | ## Auditor is deliberately not a rung Viewer → Editor → Admin → Owner is a ladder: each holds everything below it. **Auditor is not on that ladder.** It sits beside it. **An Auditor can read the audit log, which an Editor cannot — and cannot edit a dashboard, which an Editor can.** Neither is a subset of the other. This is the point of the role. A compliance reviewer needs to see who changed what, and specifically must not be able to change anything themselves. Giving them Admin to grant audit access would defeat the purpose; giving them Editor would not grant it at all. The practical consequences: * A permission gate requiring **Editor** rejects an Auditor. Every mutation does, without exception. * A gate requiring **Auditor** admits Auditor, Admin and Owner — the roles that hold audit access — and rejects Viewer and Editor. ## Who may grant which role Two rules, both enforced by the API rather than only by the interface: An Admin can grant up to Admin. **Only an Owner can grant Owner.** This stops an Admin from promoting itself. Auditor is outside the hierarchy, so "no higher than your own" does not define it. It is restricted to the roles that already hold audit access. **An Owner cannot be demoted by an Admin.** The check is on the target's *current* role, not only on the role being assigned — otherwise an Admin could remove the organization's Owner and take it over, which is an escalation even though no role above Admin was ever granted. If you need to change an Owner, sign in as an Owner. ## What needs which role The full permission model is per endpoint, and the [API reference](/api-reference/introduction) states the requirement on each one. The cases that come up in practice: | Task | Minimum role | | :------------------------------------------------------------- | :--------------------------- | | View any telemetry or dashboard | Viewer | | Read and export the audit log | Auditor *(or Admin / Owner)* | | Create or edit a dashboard, alert rule, SLO or synthetic check | Editor | | Create or revoke a **license key** | Admin | | Invite a user or change someone's role | Admin | | Manage billing and the plan | Admin | | Index documents into the knowledge base | Editor | | Create another organization | Owner | | Grant the Owner role | Owner | **"I can see the license key list but there is no create button."** That is the Viewer or Editor view. Key creation is Admin — ask your organization's Owner or an Admin to mint one, or to grant you the role. See [Create a license key](/get-started/license-keys). ## Roles do not restrict telemetry A role controls what you can *do*, not which services you can *see*. Every member of an organization sees all of its telemetry. **There is no per-service or per-team read restriction.** If some telemetry must not be visible to some members of your team, the boundary you need is a separate organization — see [Organizations and multi-tenancy](/concepts/organizations). Do not rely on Viewer to hide data; it does not. ## Every change is recorded Role changes, invitations, key creation and revocation, and support access are all written to the audit log with the actor, the target and the time. An Auditor, Admin or Owner can read and export it. See [Audit log](/guides/audit). ## Next How invitations work and what happens when one expires. SAML, one-time codes, and why SSO does not create accounts. What is recorded, how far back, and how to export it.