RBAC, approvals & audit

This is the page for whoever has to answer "who can change production, and how do we prove what they did?" OrcaMonitor answers both from the same place: permissions decide what is possible, and the audit trail records what actually happened — including the requests that were refused.

Users and roles

Access is role-based. A user holds roles, roles hold permissions, and nothing grants access implicitly — there is no "staff users can see everything" shortcut that quietly widens over time.

The permission catalogue

Permissions are organised into a tree that mirrors the sidebar, so a permission's place in the tree tells you where in the product it applies. The catalogue is complete by construction: every permission row must appear in exactly one place, and a permission that no page claims fails a build check rather than vanishing silently.

The role list is the entry point: each card shows the role's identity, how many members hold it, and how much of the platform it reaches — pages and permissions counted against the whole catalogue. A role is edited from the card's own control, so the counts and the grants are read in the same place.

• Page gates — each page has its own permission, including each settings page.
• Action gates — actions within a page are separately grantable.
• Not-enforced badge — a permission that nothing reads is labelled, so the editor does not imply control it does not have.
• Aliases — a page that is genuinely the same thing as another is marked as an alias instead of being granted twice.

Approval policy

Approval is what separates a diagnosis engine from an autonomous one. Mutating actions require a human decision, and the policy is configurable so you can tune what counts as risky for your environment rather than accepting ours.

• Read-only operations run without a gate — investigation should never need permission.
• Configuration changes require approval, with the exact command list shown before the decision.
• Destructive actions are marked as such, and stay marked in the audit trail.
• An approval can be revoked only by stopping the run, before execution completes.

The audit trail

The audit trail records both successful actions and refused ones. A denial is evidence in its own right — "who tried to do this and was stopped" is exactly the question an access review asks, and it is unanswerable if only successes are logged.

Tamper-evident history

For environments where an audit log must survive the platform itself, history can be mirrored to a git-backed immutable store. Each entry is committed, so an edit is visible as a change rather than being invisible by default.

• Every audited event becomes a commit with its own identity.
• History is therefore diffable and verifiable rather than a mutable table.
• Falls back to a local store when the git backend is unavailable, so auditing degrades rather than stops.

Runtime guardrails

A component and configuration scanner runs against the platform's own surface to catch drift — an exposed endpoint, a weakened setting, an unexpected component. Findings are surfaced like any other security finding and can be tracked to resolution.

• Component scanning for unexpected or vulnerable components.
• Runtime guardrails that classify and block risky command patterns before execution.
• Findings carry an audit event, so a detection is itself auditable.
• Modes let you observe before enforcing — see what would have been blocked during rollout.