Organizations and access
Hosted and self-host group people into organizations. An organization owns its accounts, apps and deployments, and each member holds one role.
An organization is the boundary that owns accounts, apps and deployments on hosted and self-host. Everything you connect or deploy belongs to one. Local Executor has no organizations; it is one person on one machine.
Members and roles
Every person in an organization is a member with one role:
| Role | Can do |
|---|---|
member |
Create apps, connect accounts, use their own apps and what is shared with them, and manage what they created. |
admin |
A member’s rights, plus invite and remove people, manage groups, publish apps, and manage every app and shared account. |
owner |
An admin’s rights, plus delete the organization on Cloud. |
Roles decide who manages things, not who uses them. Using an app, including calling its tools through MCP, follows the app’s audience:
- Only me, the default for a new app: only the person who created it.
- Everyone in the organization.
- Groups: the members of the groups it is shared with. A member can share only with groups they belong to; admins and owners can pick any group.
Shared accounts follow the same rule. A personal account is used and managed only by the person who connected it.
Managing does not grant use. An admin or owner can see, edit, deploy, share and delete another person’s private app, but cannot call its tools unless it is shared with them. Each call also runs with the caller’s own profile, so nobody runs with another person’s account choices. A scoped connection can narrow an agent’s access further.
People join by invitation. On hosted you can also be admitted by your identity provider when one is configured.
Slugs
An organization has a slug: lowercase letters, numbers and hyphens, up to 80
characters. Dashboard URLs are built from it, as /org/<slug>/.... If the slug
you want is taken, Executor adds a short random suffix. Changing a slug does not
leave a redirect behind, so old links stop working.
Access is never implicit
Being in an organization is what grants access. There is no ambient “current organization” that decides it: the organization you are looking at in the dashboard is a display preference and nothing more.
That matters most for agents. An MCP connection is approved for one organization, and the grant records it. Switching organization in the dashboard afterwards does not retarget the connection, including after the token refreshes. To reach a second organization, connect again and approve it separately. An API call whose URL names a different organization than the grant is refused, even when you belong to both.
Every request revalidates your membership. Losing it stops the connection working immediately.
Signing in
- Hosted supports Google, GitHub, passkeys and a verified email code.
- Self-host uses a password. The first person to finish setup becomes the owner, and there is one organization. After that, people join by invitation. You can add an OIDC identity provider and restrict it to your email domains. Self-host does not offer the hosted Google and GitHub buttons.
A login is not an account. Signing in with Google does not create a Google account an app can use, and no tool ever receives your login token. See Providers and accounts.
What is coming later
- Workspaces: a grouping inside an organization for installing apps and sharing accounts with a smaller set of people.