Skip to content
Sencai.docs

Permissions in depth

Roles & permissions covers what you can configure today: five standing roles and five broad per-resource overrides. This page describes the underlying model those are being rebuilt on top of - a catalog of specific permissions grouped by area, rather than a handful of fixed presets - and is explicit about which parts of it are live.

How a permission is named

Section titled “How a permission is named”

Each permission is a resource area, optionally with a more specific sub-area, and an action: area:action or area.sub-area:action - for example billing:manage, fleet.exec:execute, or audit:export. Nothing in the app surfaces these exact names to you yet - an API key today only ever picks between the coarse read and read/write scopes (see API tokens), not this catalog - but they’re the vocabulary whatever configures per-permission access will eventually use.

Actions come from one fixed list (create, read, update, delete, manage, assign, and similar) - not free text - so a permission name always means the same kind of thing wherever you see it.

The permission areas

Section titled “The permission areas”
Area Covers Included by default in
Organization & members Organization settings, structure, inviting and removing members, who can manage others’ access Admin and above
Billing Viewing and changing the plan, assigning paid seats and the Auditor add-on Admin and above (Member can view and request)
Compute & infrastructure Cloud instances, storage, networking, firewalls, DNS, inventory Member and above for day-to-day use; promoting or deleting inventory is Admin
Credentials & fleet Cloud provider credentials, cloud IAM, secrets, enrolled hosts, remote execution, automation and runbooks Admin for credentials and remote execution; Member for day-to-day fleet use
Governance Operations/incidents, security findings, compliance evidence, the audit log Member for operations; audit log read/export is Owner, Admin, or Auditor only
Services AI usage, third-party integrations, API keys, source repositories, the marketplace, support Varies by service - see that service’s own page
Admin Center The handbook, the password store (and its restricted tier), contacts and responsibilities, reminders See The Admin Center permissions below

This groups close to sixty resources and around 250 specific permissions - the exact, current list is generated from the platform’s own code rather than hand-maintained here, so treat the table above as an orientation, not a line-by-line reference. The Admin Center rows below are the exception, written out in full.

The Admin Center permissions

Section titled “The Admin Center permissions”

The Admin Center adds five areas to the catalog: the handbook, passwords, restricted passwords, contacts and reminders. The table lists every key, the lowest standing role that holds it by default, and what it allows. A role holds all keys of the roles above it in the chain Owner ⊇ Admin ⊇ Member ⊇ Viewer. Auditor is a separate branch and holds only the keys marked below.

Key Lowest role What it allows
handbook:read Viewer (also Auditor) Read pages, revisions and review dates. Also usable by an API token for read-only access, including a default read token
handbook:create Member Create a page
handbook:update Member Edit a page, mark it reviewed, see and restore from the trash
handbook:delete Admin Move a page to the trash
handbook:manage Admin Redact a revision, delete a page permanently
passwords:read Member See entry details (title, username, URL, dates), never a value
passwords:create Admin Create an entry
passwords:update Admin Edit details, set or rotate a value, mark reviewed
passwords:delete Admin Trash, restore or permanently delete an entry
passwords:reveal Admin Show or copy a value, generate a TOTP code, reveal a seed. Marked critical: every use is logged
passwords.restricted:read Admin See the name and details of entries in the restricted tier. Without it the entries are hidden entirely
passwords.restricted:update Owner Create, edit, set values of and delete restricted entries
passwords.restricted:reveal Owner Reveal a restricted entry’s value (a reason is required). Marked critical
contacts:read Member Read contacts, the responsibilities matrix and the emergency sheet. Personal data, so neither Viewer nor Auditor. Usable by an API token for read-only access, but only a token issued with this key ticked (or a read/write token): a default read token is capped at Viewer permissions and does not hold it
contacts:create Member Create a contact or a responsibility
contacts:update Member Edit contacts and the responsibilities matrix
contacts:delete Admin Delete a contact or a responsibility (permanent)
reminders:read Viewer (also Auditor) See the organization’s reminders
reminders:create Member Create a reminder
reminders:update Member Edit, snooze or complete a reminder
reminders:delete Member Delete a reminder

For reminders, the role floor is only the first test: the people allowed to change or delete an existing reminder are its creator and Admins and Owners, and a recipient may also complete or snooze it.

Things that are true of every key in these five areas:

  • No platform-administrator shortcut. Sencai’s own platform administrators can’t use any of them without a membership in your organization that you granted. This differs from many other areas, where a support person may act with a stated reason.
  • Password keys never work through API tokens. passwords:* and passwords.restricted:* can’t be given to a token. Only the read keys of the handbook and contacts can, and a token reaches nothing but read routes.
  • Write permissions are never elevation grants. Temporary elevation into another organization can’t be used to read passwords or change the handbook.
  • Reading the access history of the password store is part of reading the audit log (Owner, Admin and Auditor), not of the password keys. An Auditor therefore sees who revealed what, but not the entries’ details.
  • Restricted entries are hidden, not refused. Without passwords.restricted:read (Member and below) an entry in that tier doesn’t show up and is reported as not found. An Admin holds the read key, so sees the entry’s name and details, but only an Owner holds passwords.restricted:reveal and passwords.restricted:update.
  • Per-entry two-factor authentication. An entry marked Require two-factor authentication needs a fresh authenticator code for every reveal, copy and TOTP code, on top of passwords:reveal (or passwords.restricted:reveal). Restricted entries always require it.

Per-person access works the way it does for the rest of the catalog: with a custom role or a per-member deny. For example, give a “helpdesk” role passwords:read and passwords:reveal only, or deny passwords:reveal for one Admin.

These keys are enforced: what the table lists as a role’s default is what that role can do in these five areas. The roles on Roles & permissions are, underneath, these same bundles.

What a role or a future custom role would be built from

Section titled “What a role or a future custom role would be built from”

A standing role (Owner, Admin, Member, Auditor, Viewer) is a fixed bundle of permissions from the catalog above - this is how the roles on Roles & permissions are actually defined underneath, not a separate, looser description of them. Two properties that already hold today, because they’re what makes the role hierarchy mean what it says:

  • Owner ⊇ Admin ⊇ Member ⊇ Viewer, and Admin ⊇ Auditor ⊇ Viewer - every permission a lower role has, a higher one has too, along that chain.
  • The audit log’s read and export permissions exist only in Owner, Admin, and Auditor - never in Member or Viewer, and never in a future custom role either. That’s a hard boundary, not a configurable one, because it’s what keeps the Auditor add-on price from being something a cheaper, read-only custom role could quietly route around.

Being introduced: custom roles are built but switched off, so no organization can create one yet (see the note at the top). Once custom roles are available, an organization will be able to build a role from an explicit list of permissions instead of a preset, always starting from a base of Viewer, Member, or Admin and only adding permissions that base is already allowed to hold. A custom role will never be able to read or export the audit log, and will never carry the Auditor add-on’s billing class - those stay anchored to the standing Auditor role specifically, for the same reason above.

Requests instead of silent denial or silent charges

Section titled “Requests instead of silent denial or silent charges”

Two situations that don’t just fail with a plain “no”:

  • A change has a price impact you’re not authorized to approve (for example, inviting someone straight into the Auditor add-on) - the platform creates an access request to your organization’s billing owners if you can’t approve it yourself, or shows you a price confirmation if you can. The confirmation path works for both a new Auditor invite and an existing member’s role change. A request for the Auditor invite is filed and stored, carrying the invite itself, and approving it asks for the same price confirmation before the invitation is created. Being introduced: there’s no screen anywhere in the app to act on a request yet, and outside of Sencai’s own development environment the API that would approve it isn’t switched on either, so the request path doesn’t get you there today. If you can’t approve the price yourself, ask an Owner or Admin who can to send the invitation directly - see Roles & permissions for the current state of all three paths.
  • A change would grant access you don’t have permission to grant - refused outright, since nobody can hand out more than their own access (see Roles & permissions).

Both are visible, recorded events - never a silent no-op and never an automatic charge.

Just-in-time elevation

Section titled “Just-in-time elevation”

Temporary, time-boxed access into another organization you manage (for example, as an agency or MSP) is a separate, already-live mechanism, not part of this catalog’s rollout - see Access management for how it works today.

What’s next

Section titled “What’s next”