> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/administer-and-govern/control/members/roles-and-permissions.md).

# Roles and Permissions

Understand the current project roles and how organisation ownership changes effective access across projects.

Lleverage currently has three Project roles for new access decisions: **Owner, Builder and Operator**.

![The Project role picker with the current product definitions for Owner, Builder and Operator.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fzy4eE2ZMFpuHexbjiYBe%2Fcontrol-project-roles.png?alt=media)

The role picker describes them as:

* **Owner** — full access; manage members, build and publish workflows.
* **Builder** — create, edit and publish workflows; manage tables and knowledge bases.
* **Operator** — run published apps, view sessions, and manage project files.

These labels are useful summaries, not an exhaustive entitlement matrix. Some Control surfaces use organisation membership or organisation ownership as an additional enforcement boundary, so check the page for the capability you are administering.

### Owner

Use Owner for people responsible for Project administration and membership. Owners can manage Project members and the configuration reserved to Project owners.

### Builder

Use Builder for people who create and improve operational capabilities. Builders can create and publish Workflows and manage builder surfaces such as Skills, Tables and Knowledge.

Do not assume every Control page is Builder-gated. For example, the current Secrets, Variables and Project API Token routes are organisation-member scoped rather than Project-role scoped; their own pages document those current boundaries.

### Operator

Use Operator for people doing the operational work. Operators use surfaces such as the Agent, Workflow apps and Requests. The current navigation hides the **entire Control section** from Operators rather than showing read-only Control pages.

### Organisation Owner

Organisation ownership is separate from Project membership. Organisation Owners are treated as effective Project owners in several current Control surfaces and can therefore appear in a Project as **Owner (via organisation)** without a direct Project membership row.

Do not interpret a missing Project membership row as proof that an organisation Owner lacks Project administration rights.

### Legacy Member rows

`Member` still exists for organisation membership and in legacy Project data, but it is retired as a Project role. New Project-access guidance should use Owner, Builder and Operator.

## SSO and directory-managed access

Enterprise SSO authenticates users through your identity provider. What access it produces depends on whether a directory is connected:

* **Without a directory**, anyone who signs in through an active SSO domain joins the Organisation as a Member with Operator access to the default Project. Higher roles and other Projects are assigned separately.
* **With directory access**, SSO authenticates the user while mapped directory groups and Everyone grants determine their access. Members of a mapped group receive its role and directory-sourced access is removed when the directory says it should be removed, subject to the configured sync behaviour.

Direct grants and directory grants can coexist. The highest effective role wins, and removing a directory mapping does not remove a direct grant.

See [Enterprise SSO Setup](/administer-and-govern/control/members/sso-setup.md) and [Directory access](/administer-and-govern/control/members/directory-access.md).

RBAC continues to evolve. These docs describe current deployed behaviour rather than a future permission model.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lleverage.ai/administer-and-govern/control/members/roles-and-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.