Roles and permissions
Helios has two layers of access control: an organization role that every member carries, and per-resource roles that grant access to specific projects, workflows, chats, and integrations.
Roles and permissions
Access in Helios has two layers, and it helps to keep them apart.
- Organization role - what you are in the company's account.
- Resource role - what you can do to a specific project, workflow, chat, integration, database connection, or MCP server.
Organization roles
Every member of an organization carries exactly one organization role.
| Role | What it means |
|---|---|
admin | Full control of the organization: members, billing, SSO, SCIM, API keys. |
member | A normal user of the product. |
viewer | Read-only at the account layer. |
Administrators are protected from lockout: the last admin in an organization cannot be demoted or removed.
Resource roles
Inside Helios, access to each resource is granted by a resource role.
| Role | Typically allows |
|---|---|
user | Read the resource, list its runs, and trigger it. |
editor | Everything user can do, plus create, update, and delete. |
admin | Everything editor can do, plus view and change who has access. |
Concretely, for a workflow: a user can read it, see its runs, and trigger it; an
editor can also edit the prompt, cancel runs, and delete it; an admin can also manage its
permissions.
How the layers connect
When you access a resource, Helios resolves your role by walking from that resource outward: an explicit grant on the resource itself, then a grant inherited from its project, and finally your organization role.
Your organization role maps in as the baseline:
- Organization
admin→ resourceadmin. - Organization
memberorviewer→ resourceuser.
The organization viewer role is read-only at the account layer, but inside Helios it resolves to
the user resource role - which permits triggering a workflow. If a person must not be able to
run agents, don't grant them access to those workflows.
Nobody is an editor by default. The editor role is only ever obtained by an explicit grant on a
project or an individual resource.
Visibility
Every resource is either:
- Restricted - reachable only by users with an explicit grant, or through the project it belongs to. A restricted resource must always have at least one explicit admin.
- Organization - everyone in the organization gets a role on it. You choose which role.
Making a resource organization-visible is how you share it; see projects and sharing.
Visibility is managed today for projects and integrations. Workflows and chats inherit access from the project they live in.
Inheritance through projects
Resources belong to a project, and by default they inherit their
access from it. Grant someone editor on a project and they can edit every workflow in it, without a
per-workflow grant.
This is why the project is the right unit to think about when granting access.
API keys
API keys authenticate machines rather than people. Create them in your account settings, scoped to a
product - helios, ci, or cache. 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 admin of its organization, can rename, disable, set an expiry, or delete it. To rotate a key, create a new one and delete the old.
Related
- Projects and sharing - organizing and granting access.
- SSO and SCIM - federating identity and provisioning users.
- Variables and secrets - who can read what.
Last updated on