> ## 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.

# Scopes

> The scopes an API client can hold, what each grants, and what no API client can do.

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](/docs/conduit/use/mcp-authorization#scopes-limit-each-client)
— 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.

| Scope | Grants |
| - | - |
| `connectors:read` / `connectors:write` | View connector configuration and live tool catalogs / manage connectors and Pipedream configuration |
| `policies:read` / `policies:write` | View policies, configured connector grants, groups, group-hierarchy access, and per-user effective access / manage policies, groups, and group membership |
| `members:read` | List the workspace's members |
| `sso:read` | View the workspace's identity-provider configuration (`ListIdentityProviders`); client secrets and DNS domain-verification challenges are never returned |
| `provisioning:read` | View SCIM token metadata, provisioning rules, and SCIM-to-Conduit user/group mappings; bearer secrets are never returned |
| `settings:write` | Change general workspace settings — the workspace's name and logo |
| `audit:read` | Read the workspace audit log — the supported way to pull events into a SIEM using time-range filters and pagination |

<Warning>
  **`connectors:write` can run code on members' machines**

  A `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.
</Warning>

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.