Scopes and Permissions
Scopes control what your application can do with a user's access token. You request scopes during OAuth authorization or when creating a Personal Access Token.
Available Scopes
| Scope | Description |
|---|---|
account |
Read account information and profile |
agents-all |
Full agent management — create, update, delete, and use agents |
agents-use |
Use existing agents (chat only, no management) |
llm-all |
Access LLM chat completions and model listing |
connections |
Manage connections to external services |
universal-mcp-read |
MCP tool discovery only (tools/list) |
universal-mcp-read-write |
MCP tool discovery and execution (tools/list + tools/call) |
user-data |
Access user data features |
providers |
List and view available connectors |
messaging-channels |
Manage messaging channels (Telegram, WhatsApp, Webchat) |
openid |
OpenID Connect — returns an ID token |
profile |
Access profile information (name, picture) |
email |
Access email address |
Scopes by Client Role
Not all scopes are available to all client roles. The scopes your app can request depend on its role:
| Scope | THIRD_PARTY | WHITELABEL_CUSTOMER |
|---|---|---|
account |
Yes | Yes |
agents-all |
No | Yes |
agents-use |
Yes | Yes |
llm-all |
Yes | Yes |
connections |
Yes | Yes |
universal-mcp-read |
Yes | Yes |
universal-mcp-read-write |
Yes | Yes |
user-data |
Yes | Yes |
providers |
Yes | Yes |
messaging-channels |
Yes | Yes |
openid |
Yes | Yes |
profile |
Yes | Yes |
email |
Yes | Yes |
Key difference: THIRD_PARTY clients cannot request agents-all. They can use agents (agents-use) but cannot create, update, or delete them.
How Scopes Are Resolved
When your app requests scopes during authorization:
- BlueNexus checks which scopes are allowed for your client's role
- Unknown or disallowed scopes are silently ignored
- The granted scopes are returned in the token response's
scopefield - The access token only permits operations within its granted scopes
If your client has the THIRD_PARTY role (restrictive), BlueNexus uses intersection mode — only scopes that the restrictive role permits are granted. WHITELABEL_CUSTOMER uses union mode — broader access.
Provider Permissions
In addition to API scopes, users can control per-provider access during authorization. This determines which connected services your app can interact with through MCP.
Provider permission levels:
read-write— Full access to the provider (read and write)read— Read-only accessdisabled— No access to this provider
Setting Provider Permissions
During the OAuth authorize request, use the provider_permissions parameter:
https://app.bluenexus.ai/oauth/authorize?
...
provider_permissions={"google":"read-write","slack":"read","github":"disabled"}
When creating a PAT:
{
"scopes": ["universal-mcp-read-write"],
"provider_permissions": {
"google": "read-write",
"slack": "read"
},
"default_provider_permission": "read"
}
Scope Descriptions (User-Facing)
On the consent screen, scopes are presented in user-friendly terms:
| Scope | User Sees |
|---|---|
universal-mcp-read-write |
"Access and use your connected services" |
agents-use |
"Chat with AI agents" |
llm-all |
"Use AI language models" |
connections |
"Manage your service connections" |
account |
"View your account information" |
openid / profile / email |
"View your identity information" |
Checking Granted Scopes
The token exchange response includes the granted scopes:
{
"token_type": "Bearer",
"access_token": "...",
"scope": "universal-mcp-read-write agents-use llm-all"
}
If a requested scope was denied (due to role restrictions or user choice), it won't appear in the scope field.
Listing All Available Scopes
curl https://api.bluenexus.ai/api/v1/auth-scopes \
-H "Authorization: Bearer ACCESS_TOKEN"
Returns the complete list of scopes with descriptions.
Agent and Knowledge Base Restrictions
Scopes and provider permissions are not the only authorization layer. A session can also carry restrictions on which agents and knowledge bases it may access, independently of what scopes it holds.
These restrictions are orthogonal to scopes:
- A token with the
agents-usescope but anallowedAgentIdsrestriction cannot call agents outside that list, even though the scope would normally permit it. - A token without an
allowedKnowledgeBaseIdsrestriction but missing theuniversal-mcp-read-writescope cannot use knowledge base tools regardless of the restriction being absent.
Both layers must permit an operation for it to succeed.
| Layer | Set via | Controls |
|---|---|---|
| Scopes | scope parameter / scopes field |
API capability categories |
| Provider permissions | provider_permissions |
Per-provider read/write/disabled |
| Agent restrictions | agent_ids |
Which agents the token can call |
| KB restrictions | knowledge_base_ids |
Which knowledge bases the token can access |
Restrictions are set when creating a PAT (POST /v1/auth/pat) or during the OAuth authorize request and carry through token refreshes for the lifetime of the session.
Next Steps
- OAuth for Your App — How to request scopes during auth
- White-Label — Role differences for WHITELABEL_CUSTOMER
- Token Lifecycle — How token scopes are enforced