Access Control Plane

Descope's Access Control Plane enables real-time, identity-based authorization for every outbound token request made by your MCP server. It allows you to create fine-grained access control policies that determine which users or apps can access which outbound scopes or tools, based on the access token presented with the request.

This system especially powerful when your MCP server fetches outbound tokens from Descope on every request, allowing the access control logic to be enforced dynamically and consistently—without requiring additional backend logic in your MCP server to manage the access control.

What Are Access Control Policies?

Access control policies are rules you define per Outbound App that:

Dynamically evaluate the inbound app token used in the request
Determine whether the request is allowed
Return an appropriate outbound token (or block access) based on the configured conditions

These policies let you:

Restrict access to tools or scopes based on user identity, claims, or organization
Map user roles to a specific subset of outbound scopes—allowing granular permission control
Block or force re-consent in real-time if the access no longer satisfies the defined policy

Unlike traditional permission systems, these policies do not require a separate management API key or any additional setup.

You simply pass the inbound user's token to our Outbound App retrieval endpoint, and we take care of the rest.

As an example, let's look at how we can use the Access Control Plane within the context of an MCP server.

Example Use Case with MCP

Let's say you're using SSO with Azure AD in your inbound app consent flow. This inbound app is being used to protect your remote MCP server with OAuth 2.1.

A user signs in and grants consent to use tools in your MCP server. Based on their Azure AD group membership, their token includes the role Viewer.

You set up an access control policy in Descope that says:

If the user has the role Viewer, only allow access to the scopes calendar.readonly and crm.readonly.

Later, when your MCP server tries to request a token to write a calendar event, Descope checks the policy. Since the user only has read-only access, the request is blocked.

This setup gives you centralized, real-time control over what your users can do—without needing to manually manage scopes or roles for each external service.

Creating an Access Control Policy

To create an access control policy:

Go to your Outbound App in the Descope Console.
Click the Access Control tab (next to Token Management).
Click Create Policy.

Once you've created an access control policy, you can then begin to define the policy conditions as described below.

Name

Give your policy a clear and descriptive name (e.g., "Project Manager Rule").

Policy Conditions

You can define one or more conditions based on:

userRoles: Match user roles assigned in Descope
jwtClaims: Match any custom claim from the inbound app token (e.g., tenant, department, acr, etc.)

Each condition supports:

equals / not equals
in / not in
contains (for arrays)

You can combine multiple conditions using AND logic, as you can see in this examples below:

Accessible Scopes

If a user satisfies the conditions above, you can choose what outbound scopes they're allowed to access:

Select specific scopes (e.g., calendar.readonly, contacts.readonly)
Or choose All Scopes (commonly used for API keys or admin users)

Here's an example of a policy with specific accessible scopes:

If the user does not meet the conditions, Descope will block the request and return a 403 Forbidden (or require re-consent, depending on configuration).

Using with API Keys

For outbound apps that use API keys (instead of OAuth):

Set the Accessible Scopes to All Scopes
The policy conditions will determine whether the user has access to the token at all

Since the API key already encodes the permissions at the provider level, the access control policy only decides whether the token can be issued or not.

Next Steps

Was this helpful?

On this page