Projects and sharing
A project groups related workflows, chats, integrations, and variables, and is the unit of access control in Helios.
Projects and sharing
A project groups related work: workflows, chats, integrations, variables and secrets.
More importantly, a project is the unit of access control. Resources inside it inherit their access from it, so granting a teammate access to a project grants them access to everything in it — which is almost always what you want.
Your personal project
Every user gets a Personal project in each organization they belong to. It is restricted to you and it's where ad-hoc chats land. Use it to try things; move work into a shared project when it matters to someone other than you.
Creating a project
Any member can create a project. The creator becomes its admin.
Give it a name that describes the work rather than the team — "support triage" ages better than "support team's stuff".
Sharing a project
Open the project's permissions to control who can reach it. There are two dials.
Visibility decides the baseline:
- Restricted — only people you grant access to, explicitly.
- Organization — everyone in the organization gets access, at a role you choose.
Per-user roles grant specific people a specific role on the
project: user, editor, or admin. An explicit grant beats the baseline.
The common shape is an organization-visible project at the user role — everyone can see the agents
and run them — with editor granted to the handful of people who maintain the prompts.
A restricted project must always keep at least one explicit admin. Helios won't let you remove the last one.
Sharing integrations
Integrations have their own visibility, managed the same way. Connect GitHub once at organization visibility and every project's agents can use it, rather than making each team connect their own.
Credentials are never exposed by sharing an integration. Users of a shared integration can have agents act through it; they cannot read the token behind it.
Sharing a chat transcript
Sharing a chat is a different thing entirely — it produces a public link to a read-only transcript, up to a message you choose. It doesn't grant access to Helios, and anyone with the link can read it. Use it to show a colleague what an agent did, not to collaborate.
What sharing does not cover
Database connections cannot be shared per-resource today. They are reachable by agents in the organization that created them.
Related
- Roles and permissions — what each role can do.
- SSO and SCIM — provisioning people into the organization.
Last updated on
MCP servers
Connect any remote MCP server so Helios agents can call its tools, and expose Helios itself over MCP to your own agents.
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.