Roles and permissions

Helios has two layers of access control. An organization role says what you can create. A resource role says what you can do to a specific project, workflow, chat, or integration.

Access in Helios has two layers, and it helps to keep them apart.

Organization role - what you can create in the organization.
Resource role - what you can do to a specific project, workflow, chat, integration, database connection, MCP server, or Library folder.

Organization roles

Every member of an organization carries exactly one organization role.

Role	What it means
`admin`	Everything `member` can do, plus manage members, billing, SSO, SCIM, and groups.
`member`	Can create projects and service accounts.
`viewer`	Can see the organization's groups and service accounts, but creates nothing.

The last admin in an organization cannot be demoted or removed.

An organization role never grants access to a resource by itself. Access to a resource always comes from a grant, either on the resource or on the project it belongs to.

Resource roles

Access to each resource is granted by a resource role. The roles are cumulative. Each one includes everything below it.

Role	Allows
`viewer`	See the resource. For a workflow, that includes its runs and their transcripts.
`operator`	Use it. Trigger a workflow, cancel a run, send a message in a chat, or let an agent act through an integration.
`editor`	Change it. Edit a prompt, create workflows in a project, update or delete the resource.
`admin`	Full control. Read its credential and manage the service accounts that act as it.

Concretely, for a workflow, a viewer can read it and see its runs. An operator can also trigger it and cancel runs. An editor can also edit the prompt and delete the workflow.

The share dialog shows these roles as Can view, Can run, Can edit, and Full access.

Grants

A grant gives a role on a resource to a principal. A principal is one of:

a person,
a group of people and service accounts,
a service account, the identity a workflow runs as,
or everyone in the organization.

A grant can expire. When you share a resource, choose no expiry, one day, one week, or a custom date.

Sharing is not a separate role. Anyone holding a grant on a resource can share it, but never above their own role. A viewer can only pass on viewer.

You cannot lower or remove your own access. Ask another admin of the resource to do it.

Workflows, integrations, MCP servers, and database connections belong to a project and inherit its grants. Grant someone editor on a project and they can edit every workflow in it, without a per-workflow grant. A grant on the resource itself adds to what the project gives.

This is why the project is the right unit to think about when granting access.

Chats do not inherit. The person who started a chat has full access to it. A chat inside a shared project is not readable by everyone with access to the project.

Visibility

Every resource is either:

Restricted - reachable only through explicit grants, or through the project it belongs to.
Organization - everyone in the organization holds a role on it. You choose which role.

Making a resource organization-visible is how you share it with the whole team. See projects and sharing.

API keys

API keys authenticate machines and the Helios CLI. Create them under Settings → API keys. A key is shown once, at creation. Afterwards only its last four characters are visible.

Keys can be personal or owned by the organization. A key's owner, or an organization admin, can rename, disable, set an expiry, or delete it. To rotate a key, create a new one and delete the old.

Projects and sharing - organizing and granting access.
SSO and SCIM - federating identity and provisioning users.
Variables and secrets - who can read what.