Roles and permissions
Workspace roles and service roles are independent, and service roles add up. A workspace Administrator is not automatically a service Developer, and a service Administrator is not a workspace Administrator. Helmhive grants operations through explicit capabilities, never through a role name; the console hides what you cannot do, and the server denies it regardless.
Authority matrix
Section titled “Authority matrix”| Role | Granted | Explicitly not granted |
|---|---|---|
| Workspace Member | Enter and read the workspace | Settings, access management, deployment approval, or any service without a service role |
| Workspace Administrator | Invite members, assign service roles, manage settings and repository sources, create services, approve deployment and rollback plans, read and export audit | Changing workspace roles, suspending members, implementation-plan approval, merge, release |
| Workspace Owner | Everything an Administrator can, plus changing workspace roles, suspending and restoring members, and ownership management | Automatic Developer authority on services, merge, release |
| Service Requester | Read the service; create and clarify requests; confirm their own criteria; prepare plans; see safe lifecycle and pull-request state | Model- or repository-derived text, plan approval, implementation start, repository writes, deployment |
| Service Developer | Everything a Requester can, plus approve or reject an exact plan and start or cancel implementation | Workspace settings, the pull-request bot credential, merge, release, deployment |
| Service Administrator | Read the service and hold delegated service responsibility | Requester or Developer capabilities unless separately assigned; workspace administration |
| Platform operator | Nothing by default | Any customer access without a named, expiring support grant |
The exact capability names behind each row are listed in Roles and capabilities.
Approvals stay separate
Section titled “Approvals stay separate”- Approving an implementation plan belongs to a service Developer.
- Approving a deployment plan belongs to a workspace Administrator or Owner.
- Approving a rollback plan is a separate capability, evaluated on its own.
Adding a generic administrator role never grants implementation approval. Every approval records the exact plan hash, decision maker, and expiry it was bound to.
Support grants
Section titled “Support grants”Platform operators have no standing authority inside a workspace. A workspace Administrator or Owner issues a named grant with a scope (read audit or workspace administration), a reason, and an expiry; the console offers one, four, or twenty-four hours. Operators cannot create or extend their own grants, and grants remain visible after they end.
Invitations
Section titled “Invitations”Workspace and service invitations are verified-email grants with a seven-day default expiry. Submitting the same email and role again replaces a pending invitation; revoked, expired, and accepted invitations stay visible and cannot be reused.