Skip to main content
Each scope pairs a resource area with an access level, like connectors:read or settings:write (the full list is below). Grant a client the least it needs. These are not the conduit:* permissions an interactive MCP client requests when a person authorizes it — those attenuate a signed-in user’s own access, while an API client’s scopes are its entire access. Each scope maps to one area of workspace settings. read grants viewing it; write grants changing it.
connectors:write can run code on members’ machinesA stdio connector launches a command on each workspace member’s own machine (through the conduit CLI), not on the server. Because connectors:write lets a client create or re-point any connector, granting it is effectively granting the ability to run code on your members’ machines — so grant it only to automation you trust to that degree, and grant connectors:read alone where a client only needs to inspect connectors. This is the same trust boundary that makes connector management a workspace-admin operation.
Identity inventory is read-only: sso:read and provisioning:read can inspect sanitized settings and mappings, but no API-client scope can create or modify identity providers, SCIM tokens, or provisioning rules. Those writes govern who can sign in or be provisioned as a human. Invites, API-client management itself, changing member roles, and workspace telemetry configuration are likewise not on the API-client surface in this release. An API client’s token works only for the API described here. It cannot connect to the /mcp endpoint or call connector tools — a machine token is bound to the API audience and is rejected at /mcp. Headless MCP access for API clients is a planned follow-up.