Skip to content
Sencai.docs

Roles & permissions

Every member of an organization has exactly one role in that organization. Roles are per-organization - the same person can be an Admin in one organization and a Viewer in another.

The role hierarchy

Section titled “The role hierarchy”

From highest to lowest:

Owner > Admin > Member > Auditor > Viewer

Role What it grants
Owner Full control - invite/remove members, change roles, manage billing, delete the organization. There must always be at least one Owner.
Admin Delegated management - invite members, manage instances and resources, most of what an Owner can do - but cannot delete the organization.
Member Standard working access - use and manage the organization’s instances and shared resources. Cannot invite members or change organization-wide settings.
Auditor Read-oriented access, scoped toward audit and compliance visibility. Sits below Member, above Viewer - not an elevated role, and not a synonym for “compliance admin”. Available only in a paid organization - see below.
Viewer Read-only access to the organization’s resources.

Auditor is easy to misread as a step up because of what it’s for (oversight), but its actual position in the hierarchy is between Member and Viewer. Don’t grant it expecting Admin-like reach.

In a paid organization, the Auditor role is a full option in both the Invite member dialog and the member role dropdown on the organization’s Members tab - you don’t need to go through your account team to assign it. Two of the three ways to assign it end with someone actually holding the role today:

  • Inviting someone straight into Auditor when you have billing access - which, by default, means any Owner or Admin sending the invite - shows you the price before it takes effect, and the invitation goes out once you confirm it.
  • Switching an existing member to Auditor from the dropdown works the same way: a price to confirm, then the role change applies.
  • Inviting someone straight into Auditor when you don’t have billing access files a real, stored access request for your organization’s billing owners, carrying the invite’s own email and role. Approving it shows the approver the price, and once they confirm it the invitation is created - but only where the approval step can be reached at all, which today is Sencai’s own development environment. Being introduced: there’s no screen in the app to review a request yet, and everywhere else the API that would approve it isn’t switched on, so it answers as if the request did not exist.

If you don’t have billing access yourself, ask an Owner or Admin who does to send the Auditor invitation directly rather than relying on the request queue.

Auditor is a paid-plan role, and it adds a line to your invoice

Section titled “Auditor is a paid-plan role, and it adds a line to your invoice”

The Auditor role, and the audit log it exists to read, belong to paid organizations. For the role this is enforced everywhere today: in a free organization, inviting someone as Auditor, switching a member or a pending invitation to Auditor, accepting an Auditor invitation, and approving a request for one are all refused with a message that the organization needs a paid plan - before any price is shown. For the audit log itself the restriction is rolling out gradually and isn’t switched on everywhere yet - where it isn’t, a free organization can still read and export it like a paid one. See Organization plans for the full list of what’s paid-only.

Assigning Auditor to a member of a paid organization adds a per-auditor monthly add-on to that organization’s invoice for as long as they hold the role, prorated daily - the same way an extra seat would. See sencai.space/pricing for the current amount. Whoever assigns the role sees that price and confirms it before it takes effect, the same way a plan change or a new paid seat asks for one - see the list above for where that works today, depending on whether you hold billing access yourself. Being introduced: the price is shown and has to be confirmed everywhere, but the add-on isn’t billed yet outside Sencai’s own development environment - it’s recorded, and doesn’t reach an invoice. See Organization plans for how price-impacting changes are confirmed elsewhere.

Which role should I give someone

Section titled “Which role should I give someone”
If they need to… Give them
Own billing, delete the org, have no restrictions Owner
Manage members, instances, and settings day to day Admin
Do their own work - provision, configure, deploy Member
Review activity and compliance evidence, nothing more Auditor
Just look around - dashboards, reports, nothing they can change Viewer

When in doubt, start narrower (Member or Viewer) and raise the role later rather than starting with Admin. Every role change is recorded in the organization’s audit trail either way.

Billing owners

Section titled “Billing owners”

Owner and Admin aren’t quite the same thing as “who gets billed.” Your organization’s billing owners are the accepted members who currently have billing management access - by default, that’s every Owner and Admin, but not one whose access to billing has been turned down to read-only or none (see the per-resource overrides below).

Not every notice reaches all of them yet, though. A payment receipt, a failed charge, or a plan change through checkout goes to every contactable billing owner. The day-11 trial reminder and the follow-up reminders while an unpaid subscription heads toward suspension currently reach only one billing owner - whichever one the platform finds a working email address for first - not all of them. A fourth kind, warning an organization it’s approaching a usage limit, is built but not switched on yet, so it doesn’t reach anyone today.

An organization always keeps at least one billing owner - the platform won’t let you remove billing access from the last person who has it, the same way it won’t let you remove the last Owner. If you restrict billing access for an Admin, make sure someone else still has it.

Per-resource access overrides

Section titled “Per-resource access overrides”

On top of the role hierarchy, an organization can further restrict what a specific member can touch within their role, resource by resource. Five resource areas can be individually set to no access, read-only, or full access: billing, AI features, cloud instances, the audit log, and fleet management. A handful of named presets cover common cases - for example, a “billing manager” preset grants full billing access with read-only visibility into AI usage and instances, and no audit-log or fleet access at all - or you can customize each area individually.

This is an additional restriction layered on top of a member’s role, not a way to grant more than their role already allows. A Viewer given “full access” to billing still can’t do anything a Viewer’s role otherwise forbids elsewhere; the override can only take away access within what the role already grants, never add capability the role itself doesn’t have. A member with no override configured for them is unrestricted within their role, exactly as if this feature didn’t exist for them.

Custom roles and finer-grained permissions (rolling out gradually)

Section titled “Custom roles and finer-grained permissions (rolling out gradually)”

The five roles above, plus the five-area overrides just described, are everything self-service today. Behind the scenes we’re building a broader permission model - dozens of specific permissions grouped by area (members, billing, compute, fleet, security, and more, each with its own read/create/update/delete-style actions) instead of five fixed overrides - so an organization can eventually build a role that’s exactly “can restart instances and read fleet inventory, nothing else,” rather than picking the closest preset.

That catalog is documented in Permissions in depth so you know the shape it’s heading toward, but none of it replaces anything on this page yet: apart from the five Admin Center areas, whose keys are listed there, no area of the platform is governed by it today, custom roles aren’t available to create, and the standing roles and five-area overrides above remain the actual, enforced access model for every organization. This page - and that one - will say plainly when a given area starts being configurable, area by area, rather than all at once.

Two rules already guide how it will work once areas do turn on, because they’re basic anti-escalation properties rather than a feature that gets switched on later:

  • Nobody can hand out more access than they themselves have. A grant to another member can never exceed the granting member’s own effective access, and an Owner is the only role that can assign the Owner role.
  • Nobody can change their own role or access. Raising, lowering, or restricting your own permissions - including for a platform-level administrator acting on your organization - always has to come from someone else.

Access requests

Section titled “Access requests”

When a change would cost money - assigning Auditor, adding a seat, or crossing into a paid configuration - and the person making it doesn’t hold billing access, the platform doesn’t silently block it or silently charge the organization. It’s meant to create an access request and notify your organization’s billing owners (see above), who can approve or reject it - that’s the eventual shape, and it’s what the broader permission catalog in Permissions in depth will use once non-billing areas come online too.

Today it’s a mix, and worth knowing which part you’re hitting:

  • Requesting a higher seat tier for yourself, and inviting someone straight into Auditor without billing access yourself, both do create a real, stored request. Nobody is notified about either one by email or in-app yet. For the Auditor invite, the request carries the invitee’s email and role, and approving it in a paid organization asks the approver to confirm the add-on price (Being introduced: shown and confirmed, but not billed yet outside Sencai’s own development environment) and then creates the invitation - in a free organization the approval is refused, because Auditor needs a paid plan (see above). Being introduced: there’s no screen anywhere in the app to review or act on a request yet, and outside of Sencai’s own development environment the API that would approve or reject one isn’t switched on either, so it answers as if the request did not exist. Until then this is the one Auditor-assignment path that doesn’t get you there - see Organization plans for the two other cases (an invite sent by someone who does hold billing access, and moving an existing member into Auditor from the role dropdown), which work.
  • Crossing from the free configuration into a paid one this way isn’t live yet either; that still falls back to the plain over-limit response described on Organization plans.

Platform-level access

Section titled “Platform-level access”

Separately from any organization’s own roles, Sencai staff can hold platform-level administrative access that spans across organizations - used for support and platform operations, not something any customer role grants. It’s entirely independent of your organization’s own Owner/Admin roles and isn’t something you can grant to a teammate.

What’s next

Section titled “What’s next”