# Permissions

> The sixteen permission keys, what each unlocks, which builtin role holds which, and the navigation and action permissions per destination.

_Reference · Updated 2026-10-24 · Describes release 0.1.164_

This page lists the sixteen permission keys once: what each unlocks, which builtin role holds which, and what each destination needs to open and to change. Roles are named sets of these keys — see [Members and roles → Create a custom role](/help/members-and-roles.md#create-a-custom-role) — and who may release a fix at each risk tier is stated in [Approval policy → Who decides](/help/approval-policy.md#roles).

**Permission key.** Access is a set of 16 dotted permission keys, not a rank. Each API operation checks its required permissions. A caller who is not a member at all gets a 404 (the tenant's existence is not revealed); a member missing a required key gets a 403.

## The permission matrix {#the-permission-matrix}

| Permission key | owner | operator | approver | viewer | executive |
| --- | --- | --- | --- | --- | --- |
| `incidents.view` | yes | yes | yes | yes | yes |
| `incidents.act` | yes | yes | — | — | — |
| `approvals.decide` | yes | — | yes | — | yes |
| `datasources.view` | yes | yes | yes | yes | yes |
| `datasources.manage` | yes | yes | — | — | — |
| `knowledge.view` | yes | yes | yes | yes | yes |
| `knowledge.manage` | yes | yes | — | — | — |
| `feedback.submit` | yes | yes | yes | — | — |
| `skills.approve` | yes | yes | — | — | — |
| `benchmark.view` | yes | yes | yes | yes | yes |
| `benchmark.manage` | yes | yes | — | — | — |
| `report.view` | yes | yes | yes | yes | yes |
| `members.manage` | yes | — | — | — | — |
| `pillars.manage` | yes | — | — | — | — |
| `chat.ask` | yes | yes | yes | — | yes |
| `chat.estate` | yes | yes | — | — | — |

What each key unlocks:

- `incidents.view` — alerts, incidents, investigations, root cause analysis (RCA) text, artifacts, the live investigation stream, **and escalation**. Escalating is the andon cord: any member who can see an incident may call for a human, viewer included, and the audit row records who.
- `incidents.act` — raise a concern, request approval of a fix, release a non-emergency standard fix made standard by a matched runbook at a one-approver tier, request pre-approval of a validated typed fix for next time, mark resolved, request a suppression or another risk decision (it takes effect once an approver approves it), export an RCA, trigger an investigation, call the OpenAI-compatible agent API, **and edit a pillar agent's prompt, model, schedule and enabled state**.
- `chat.estate` — lets chat answer from the tenant's **live** read-only connectors ("how many clusters do we run, what is deployed on them") instead of platform records alone. High-trust by design: the credential still reads production systems, so only owner and operator hold it by default. Every mutating call is refused before it executes and write-role credentials stay invisible — see [Security and data handling](/help/security-and-data.md).
- `approvals.decide` — approve, deny or edit a proposed write action, release (apply) a reviewed fix or change at any risk tier — L3 needs two distinct holders — approve or reject a suppression or other risk decision someone requested (an approver other than the requester, unless no one else can approve), and revoke a live decision.
- `datasources.view` / `datasources.manage` — read connectors and estate x-ray scans / create, patch, delete, test them, launch scans, apply drafts, edit the web-fetch allowlist, manage lakehouse collection specs, declare or remove service dependencies. A dependency can fold one service's alerts into another's incident and widens that incident's blast radius, which can raise its priority and make a fix L3, needing two approvers.
- `knowledge.view` / `knowledge.manage` — read / write the knowledge base.
- `feedback.submit` — score an RCA 1-10 and send corrections.
- `skills.approve` — promote, reject or retire skill proposals.
- `benchmark.view` / `benchmark.manage` — read results / run, import and manage golden sets.
- `report.view` — the executive report, feedback aggregates **and the audit log**.
- `members.manage` — members, roles, SSO, tenant settings, appearance, guardrail overrides (cost cap and extra PII patterns), lakehouse erasure.
- `pillars.manage` — the approval-gate configuration (a pillar's extra gates and its toolsets), model tiers, the gateway model list, webhook token minting.

Two deliberate splits are worth knowing. `pillars.manage` is separate from both `approvals.decide` and `incidents.act`, so that neither the person who signs off actions nor the person who tunes an agent's prompt can quietly widen what that agent is allowed to execute without a signature. And `approvals.decide` is separate from `incidents.act`: the operator normally requests approval; only a non-emergency standard prepared fix made standard by a matched runbook, at a one-approver tier, can be released by that operator. `executive` reads everything, runs no analyses and signs off — it can use **Chat**, as can the approver role; neither role carries live-estate chat access by default.

### Navigation and action permissions {#navigation-and-action-permissions}

Navigation exposes the pages your role can use. Reading a page and changing its records may require different permissions; the page keeps its actions aligned with that distinction.

| Destination | Navigation/read access | Changes |
| --- | --- | --- |
| **Operate → Incidents, Service correlation, Needs you** | `incidents.view` | Paused tool decisions and certification need `approvals.decide`; `incidents.act` may request pre-approval of a validated fix and release a non-emergency matched-runbook standard prepared fix at L1/L2. Other releases retain their approvers and quorum. Service dependency edits need `datasources.manage`. |
| **Security posture → Posture** (and **Vulnerabilities**, **Patching**, **Backup**) | `incidents.view` | The same incident actions and permissions; requesting a suppression of a flagged resource needs `incidents.act` or `approvals.decide`, approving it `approvals.decide`; Scanner sync shows with `report.view` or `pillars.manage`, **Sync now** needs `pillars.manage`, and **Pull from scanners automatically** needs `members.manage`; **Export period** on Posture trend needs `report.view`; connection names for accounts require `datasources.view` |
| **Security posture → Audit & coverage** | `report.view` | Revoking a risk decision needs `approvals.decide`; attestations and control overrides need `pillars.manage`; running a scan needs `incidents.act` |
| **Settings · Data in → Data sources** | `datasources.view` | `datasources.manage` |
| **Insights → Estate x-ray** | `datasources.view` | Launch/cancel/delete need `datasources.manage`; reviewed context needs `knowledge.manage` |
| **Insights → Estate map** | `datasources.view` | **Harvest now** needs `datasources.manage`; the blast-radius picker lists change records, which needs `incidents.view` |
| **Agent quality → Knowledge base → Knowledge** | `knowledge.view` | `knowledge.manage` |
| **Insights → Report**, **Agent quality → Feedback** | `report.view` | Submitting a rating needs `feedback.submit` |
| **Agent quality → Test Lab** | `benchmark.view` or `pillars.manage` | Creating the lab workspace needs `members.manage`; connecting, validating, provisioning, guards and teardown need `datasources.manage`; runs and replays need `benchmark.manage` |
| **Settings · Agents → Agent behaviour** | `incidents.act` or `pillars.manage` | Prompt/model/schedule/enablement need `incidents.act`; extra gates and toolsets need `pillars.manage` |
| **Settings · Agents → AI models** | `pillars.manage` | `pillars.manage` |
| **Settings · Agents → Guardrails & cost** | `pillars.manage` or `members.manage` | Each policy group states its required permission |
| **Settings · Account → Members & roles, Appearance** | `members.manage` | `members.manage` |
| **Settings · Account → Audit log** | `report.view` | Audit records are append-only; **Verify chain** and **Export** need `report.view` |

Direct links remain useful bookmarks, but do not bypass authorization. The API checks membership, permissions and workspace status on every request. If a recent role or feature change has not reached navigation, refresh the page.

## Limits and gotchas

- **Client-side permission checks only steer the UI.** The API is the enforcement boundary; a hidden nav entry is not a security control.


## Next steps

- Next: [Architecture — AIOps Control Deck](/help/architecture.md)
- [All Reference pages](/help/reference/llms.txt)
- [Documentation home](/help/)