Roles & permissions

Everyone belongs to an organization through a membership, which carries one role and two optional allowlists. The role decides what a person may do. The allowlists decide what they may reach.

There is no custom-role builder. These three are the whole model, which is what makes the rules below short enough to hold in your head.

In the tables that follow, ● means the role has that capability, ▲ means it needs someone else's approval first, and — means it does not have it at all.

Team and people

Promoting to owner is deliberately owner-only. An admin can build out the team but cannot mint a peer who outranks them, and cannot strip an existing owner's role.

Workspaces

Connectors

A member never connects a connector themselves. They file a request that names one owner or admin, who approves it by email. See Approvals & 2FA.

Deleting a connector additionally requires a one-time code emailed to the actor, on top of the role check.

Workspace content

Skills are served to every client connected to that workspace's MCP, so authoring one is a management action rather than a personal preference. Boards are the exception to the pattern: anyone can create one and owns what they create.

Organization settings

Anything that changes what the organization pays or who can reach it — plan, billing, IP allowlisting, account deletion and data export — is owner-only, with no admin equivalent.

The two allowlists

A membership carries two independent allowlists. Both are stored on the membership and both are re-evaluated on every request.

Two rules govern both:

• Empty means all, not none. A membership with no restrictions set is unrestricted. This keeps existing members working when a new allowlist is introduced.
• OWNER bypasses both. Admins and members are equally bound by them — being an admin does not widen your reach, it only widens what you can do within it.

The connector allowlist is applied after the workspace allowlist, so a connector in a workspace you cannot reach is unreachable regardless of what the connector list says.

Per-member connector access modes

An owner or admin can override a connector's access mode for one member, in the workspace Members panel. This is a third layer, below the two allowlists.

A newly granted connector defaults to least-privilege READ_ONLY for that member even when the instance itself is set to full access. See Access modes & tool catalogs.

Guardrails that apply to everyone

Some rules are not about role at all. They hold no matter who is calling.

• You cannot change your own role.
• You cannot remove yourself from the organization.
• The last OWNER cannot be removed or demoted. An organization always has one.
• A workspace from a different organization is not reachable at any role. That boundary is checked before the role is even consulted.

Invitations

Owners and admins issue invite links from /settings/team. A link can target a specific email address and carries the role the invitee will receive. Links expire after 14 days and are single-use.

Someone who signs in on your corporate domain without an invitation lands on /join and waits — they do not silently join the team.

How this reaches the AI client

When a client runs the OAuth flow, the consent screen shows a three-level tree of team, workspace and connector, listing every verified connector that user may access. The user ticks which ones to grant.

Nothing about that grant is frozen. Permissions are not baked into the access token — on every request the gateway re-reads the role and both allowlists as they stand at that moment, and re-checks that the connection is still active and its credential still verified.

That has one consequence worth planning around:

• Removing a member drops their connections within one request.
• Narrowing an allowlist takes effect on the next call, not at the next login.
• Demoting someone takes away what their old role allowed, immediately.

There is no window in which a stale token still works, and no "revoke and wait for expiry" step.