Skip to main content
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: 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 and 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; 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 — marked SCIM in the UI, and reconciled back to the directory on every sync,
  • filled by provisioning rules at sign-in.

​
Access policies

Which tools a person’s AI client sees — and may call — is the intersection of two things:

​
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), 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 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 with an address at one of its domains, by accepting an invite, or through 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; 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 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.