> ## Documentation Index > Fetch the complete documentation index at: https://pipedream.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Access Control > Roles govern who administers Conduit; groups and policies govern which tools each person's AI client can use. Conduit has two separate permission systems, and keeping them apart answers most access questions before they're asked: 1. **Roles** decide who may *administer* Conduit — configure providers, manage members, create connectors, read audit logs. 2. **Access policies** decide which connectors and tools each person's AI client may *use*. The two never overlap. A group named "Admins" on the policies page is just a group — putting someone in it grants tools, not console access — and holding an admin role grants no tools beyond what policy allows. When someone says "I was made an admin but I still can't call this tool" (or the reverse), this distinction is the answer. ## Roles ### Instance roles Every user is either a **user** or an **instance admin**. Instance admins operate the deployment: sign-in policy and identity providers, email and telemetry configuration, MCP client management, user and workspace administration, instance-wide usage and audit. Instance admins pass every workspace-level check in every workspace. ### Workspace roles Within a workspace, every member holds one of four fixed roles, in rank order — there are no custom roles: | Role | What it adds | | - | - | | **Viewer** | The lowest rank: can sign in and use whatever tools policy grants, without member-level workspace rights. | | **Member** | The default. Uses connectors, enables tools for themselves, connects their own accounts. | | **Admin** | Manages the workspace: members, groups and policies, connectors, workspace SSO, SCIM, provisioning rules, the workspace usage dashboard and audit log. | | **Owner** | Admin, plus the role that can never be removed out from under a workspace. | Rank is enforced on every membership change, by whoever makes it — the UI, the API, a built-in admin tool, or a SCIM push: * An admin cannot change the role of, or remove, someone who **outranks** them, and cannot grant a role above their own. * Nobody changes their **own** role. * A change that would leave the workspace with **no admin or owner** is refused. * **Instance admins cannot be renamed or removed from inside a workspace** — not by an owner, not by a SCIM push. Offboarding someone who operates the instance means removing their instance role first. ### Where roles are managed Workspace admins manage members and roles in **Settings → Members**. Members can also arrive and depart automatically — see [SCIM provisioning](/docs/conduit/configure/scim) and [user provisioning](#user-provisioning) below. Instance admins manage users, instance roles, and workspace rosters under **Settings → Users** and **Settings → Workspaces**, and can revoke any user's sessions there. ### Member names Anyone can change their own name from the account menu (**Edit profile**), except someone SCIM provisions: their directory owns their name, so they change it there. A person's name is shared by every workspace they belong to, so a workspace admin can rename a member in **Settings → Members** only when the workspace owns their account: the member signs in through one of the workspace's own identity providers, isn't provisioned by SCIM (the directory owns their name; change it there), and doesn't outrank the admin. Instance admins are out of reach, as above. The member menu says why a rename isn't available, and every rename is recorded in the audit log. A name set by the person or an admin is never replaced by a later SSO sign-in. ### Invites A workspace admin can invite people by email from **Settings → Members** (**Invite**), with a role of admin, member or viewer, no higher than their own; pending invites are listed below the members. The address must be at the admin's own email domain (when their address is confirmed and the domain isn't a public service such as gmail.com) or at a domain the workspace has verified. The invite's link goes only into the email Conduit sends, so invites need an instance admin to have [set up email](/docs/conduit/configure/email); nobody else ever sees the link, and holding it proves the invitee controls the address. The link works for 7 days; resending an invite sends a new link and stops the old one working, and admins can cancel an invite. Each resend of the same invite waits longer after the last send (1 minute, then 5 and 30 minutes, 2 hours, and a day from then on), so one invite can't flood an inbox. A workspace holds at most 200 invites, and sends are capped per admin and per workspace. The link opens the workspace's login page. The invitee signs in with the address the invite was sent to, one of the ways the workspace accepts, and confirms joining, signed in a way the workspace accepts. The account must be theirs: its address has to be confirmed (by a password account, a provider the instance trusts, or a workspace's own provider at a domain it verified), or the sign-in has to come through this workspace's own provider; a different or unconfirmed address is refused. Someone with no such account, invited to a workspace that accepts email and password, creates their account there with a password instead, confirmed by the invite, and joins as they do. Joining by invite gives the invite's role, but never more than the admin who last sent it could grant when it's accepted: an invite from an admin since demoted gives at most their new role, and one from an admin since removed no longer works until another admin resends it. Someone already a member is raised to the invite's role when it is higher. Removing a member, or changing their role, ends any invite they still hold to the workspace. Invites are for multi-workspace deployments: in a single-workspace one everyone who signs in joins. Every invite, resend, cancellation, redemption and failed send is in the audit log. An invited password account has no self-service password reset. ## Groups Groups are the unit policies attach to. They contain users and **nested groups** (membership resolves transitively; cycles are rejected at write time), and they come from three sources that coexist in one list: * created by hand in **Settings → Groups & Policies**, * pushed from your directory by [SCIM](/docs/conduit/configure/scim) — marked **SCIM** in the UI, and reconciled back to the directory on every sync, * filled by [provisioning rules](#user-provisioning) at sign-in. ## Access policies Which tools a person's AI client sees — and may call — is the intersection of two things: ``` effective access = (union of allow policies that apply to the user) ∩ the user's own enabled selection ``` ### Allow policies (admin-managed) An **allow policy** (**Settings → Groups & Policies**) grants connector entries to subjects: the **whole workspace**, a **group**, or an individual **user**. A user's allow set is the union of every policy that applies to them; a user no policy applies to has **no access**. Each entry names a connector and grants either: * **All tools** — including tools the upstream adds later, automatically. * **An explicit tool list** — new upstream tools stay unavailable until an admin adds them. Pick this for connectors where new tools should be reviewed, the "all tools" form for connectors you trust wholesale. Every kind of connector is governed the same way, at the same granularity — MCP servers (including local ones), OpenAPI and GraphQL connectors, Pipedream apps, and Conduit's own built-in tools. There is no connector type that bypasses policy. Every new workspace starts with a **Default** allow-all policy linked to the whole workspace, so a fresh deployment works before anyone designs a policy model. Deleting it is an intentional lockdown — Conduit will not quietly recreate it — after which access is exactly what your remaining policies grant. ### The user's own selection Each member chooses which of their *allowed* connectors and tools are actually on, from the **Connectors** page. Until they make a selection, only Conduit's built-in tools are active — an allowed connector or app waits for the person to switch it on. This keeps tool lists small by default (which agents handle better) and makes a new connector's appearance in a client a deliberate act. An admin allowing a connector and a member enabling it are therefore both required before a tool reaches a client. "Allowed but not enabled" shows up in the member's Connectors page as available to switch on. ### How enforcement works * Policy is enforced on **every tool listing and every tool call**. A tool absent from the list cannot be invoked by name — listing and calling consult the same resolution. * Changes take effect **immediately**: policy edits, group changes, membership changes, and a member's own toggles all notify connected AI clients over the live MCP connection, and their tool lists refresh without a reconnect. * Denied calls are recorded — in the audit log, in usage metrics (`denied` outcome), and in traces — so a policy that cut off something real is visible as a step change rather than silent breakage. ### Inspecting a member's access **Why does this user have this tool?** — or not have it — is answered without reconstructing policy in your head: the members page's effective-access view runs the real evaluator for any member and shows their transitively resolved groups, the allow policies that apply, and the resulting connector and tool grants. The same evaluation is exposed as a built-in admin tool (`get_effective_access`), so it can be asked from an AI client too. ### Patterns worth knowing * **Different tools for different populations.** Policies target groups, so running a vendor's own MCP connector for one team and the equivalent Pipedream app for another is two policies. Allowing both to the same person is legal but means their client sees both tool sets — there is no automatic dedup between overlapping connectors, and no percentage-based routing. * **OAuth scopes are a separate client ceiling.** A grant can narrow a client to connectors, personal tools, workspace-admin tools, or instance-admin tools. It never widens access: server-side policy and the caller's live role must still allow each listing and direct call. * **Built-in tools are role-gated *and* policy-governed.** Conduit's own tools come in three sets — for any user, for workspace admins, for instance admins — and a caller only ever sees the sets their role permits, subject to policy like everything else. ## User provisioning **Settings → User Provisioning** (workspace admins) automates what happens when someone signs in, so directory structure — not manual roster work — determines access. Rules run on **every sign-in** and are ordered by priority; each has conditions and actions: * **Conditions** match the sign-in: email domain or exact address, the authentication method, the identity provider's asserted domain or organization, an **ID-token claim** (e.g. a `groups` claim value your provider includes — see [Single Sign-On](/docs/conduit/configure/sso#what-conduit-reads-from-your-provider)), or everyone. * **Actions** place the user into a **group** or elevate their **workspace role**. So "members of the directory group *Data Platform* land in the Conduit group *analysts*, which a policy grants the warehouse connector" is two rules and a policy — nobody edits rosters when the team changes. Rules complement [SCIM](/docs/conduit/configure/scim) rather than competing with it: SCIM pushes users and groups from the directory ahead of first sign-in and removes them on departure, while rules react to sign-ins and can read ID-token claims that SCIM doesn't carry. Deployments with SCIM typically use it as the system of record for groups and keep rules for role elevation. Membership itself follows from authentication: in a single-workspace deployment every signed-in user belongs to the workspace. In a multi-workspace deployment people become members of a workspace in three ways: by signing in through its [SSO provider](/docs/conduit/configure/sso#who-joins-through-a-workspace-provider) with an address at one of its domains, by accepting an [invite](#invites), or through [SCIM](/docs/conduit/configure/scim). An invite reaches only an address at a domain the workspace has verified or at the inviting admin's own, and needs an instance admin to have [set up email](/docs/conduit/configure/email); people elsewhere, such as contractors at another company, join through SCIM. Every change described on this page — role changes, group and policy edits, provisioning-rule hits, denied calls — lands in the audit log with the actor who made it. Successful and failed tool calls are recorded in [usage](/docs/conduit/use/usage) instead, where each row identifies both the member and the OAuth client holding the token. Usage stores no tool arguments or results; a failed call keeps up to 512 bytes of its error message, visible to administrators.