Roles and permissions

Roles govern what a person can do in the Console. Scopes govern what a token can do through the API. They are separate systems, and the gap between them is deliberate.

The roles

Role	Read inventory	Create renewals	Approve renewals	Manage connectors, sensors, domains	Manage members	Tenant settings
owner	✓	✓	✓	✓	✓	✓
admin	✓	✓	✓	✓	✓
operator	✓	✓		✓
approver	✓	✓	✓
viewer	✓

Roles are granted per organisation, so someone can be admin of one subsidiary and viewer elsewhere in the same tenant.

approver exists to separate spending from operating

operator can do the day-to-day work - configure connectors, manage sensors, create renewals - but cannot approve. approver can authorise spending but cannot reconfigure the platform.

That split is the point. Ordering certificates from a commercial CA costs money, so the person who can change where certificates are ordered from should not automatically be the person who authorises the orders.

No token can approve

There is no scope that approves a renewal. certs:renew opens one in pending_approval; approval happens in the Console, by a person holding approver, admin or owner.

This holds however much you trust your automation, and it is what makes it safe to give an agent or a CI job a renewal token: the worst outcome is a queue of requests somebody declines.

It also means a fully unattended renewal pipeline is not possible by design. If that is a problem for your operation, the answer is auto-renewal plus a person who reviews the queue - not a way around approval.

Mapping to API scopes

Role	Equivalent token scopes
viewer	certs:read
operator	certs:read, certs:renew
approver	no token equivalent for approval

Tokens cannot be restricted to a single organisation in v1. Where an endpoint accepts org_id it filters, but the token still carries tenant-wide reach - if you need hard organisational isolation for an integration today, use separate tenants.