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 — and who may release a fix at each risk tier is stated in Approval policy → Who decides.
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
| 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.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 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.