Policies

The Policies view in the Agentic Identity Hub allows you to craft authorization rules for your MCP servers. From this page, you can define who can access your MCP server and which tool-level scopes they are allowed to invoke.

MCP servers secured with Descope follow OAuth 2.1, where access is governed using scopes, token claims, and RBAC policies.

Policy Evaluation & Enforcement

Policies are allow policies that take effect automatically as soon as they are created. Access follows a least-privilege model by default—scopes are only granted if explicitly permitted by a matching policy.

To remove a policy's effect, simply delete the policy and it will no longer be evaluated.

Authorization Code Flow

When using the authorization code flow to obtain an access token, policies work as follows:

1. Scope Request: When an MCP client initiates an /authorize request with requested scopes, Descope evaluates:

   • Client Configuration: The client must be allowed to request those scopes. If the client configuration doesn't allow a scope at all, you'll receive an error during the /authorize request.

2. User Consent Flow: The user authenticates and is presented with a consent screen showing the requested scopes. The user grants consent to the scopes they approve.

3. Policy Evaluation: After the User Consent Flow is completed, Descope evaluates applicable policies to determine which consented scopes are allowed to be issued to the user. Policies filter the scopes based on user attributes, tenant context, client tags, and other conditions.

4. Token Issuance: An access token gets issued with all scopes that are allowed by the client configuration and permitted by applicable policies and consented to by the user.

5. Runtime Scope Validation: The MCP server validates and enforces scopes at runtime when tools are executed, ensuring only authorized tools can be invoked with the issued token.

Note that these policies only apply to authorization code flow access tokens. They do not apply to tokens issued via client_credentials flow.

For manually provisioned agents that use the client_credentials flow to connect to your MCP servers, you must use the MCP server client configuration to control what scopes they have access to.

Creating Policies

Policies are authored in three logical steps:

1. Who This Applies To (Conditions)

Use conditions to define which users or clients are affected by the policy. You may include multiple conditions per policy, all of which are evaluated using logical AND.

Supported condition keys

Supported operators

Using SSO Groups with Policies

To use SSO groups (from providers like Okta or Azure AD) to control which scopes agents associated with specific internal corporate users have access to, you must first map those SSO groups to Descope roles. Once mapped, you can then use the user.roles condition key in your policies to control access based on those roles.

Step 1: Map SSO Groups to Descope Roles

1. Navigate to your tenant's SSO configuration in the Descope Console
2. Configure group mapping to map your IdP groups (e.g., "Schedulers", "Finance Team") to corresponding Descope roles
3. When users authenticate via SSO, their group membership will automatically be mapped to Descope roles

For detailed instructions on configuring group mapping, see the SSO User and Group Mapping guide.

Step 2: Use user.roles in Policy Conditions

Once SSO groups are mapped to Descope roles, you can create policies that reference those roles using the user.roles condition key.

For example:

Rule name: Scheduler Access to Calendar MCP
Conditions:
user.roles CONTAINS "Scheduler"
user.tenantIds IN ["tenant-a", "tenant-b"]
Allowed Scopes:
* mcp:calendar.write
* mcp:calendar.readonly

This policy will grant calendar write access to any user whose SSO group has been mapped to the "scheduler" role, who is part of Tenant-A or Tenant-B, and who uses Claude as their MCP client.

2. Select MCP Server(s)

Choose one or more MCP servers this policy will govern. Then define which tool-level OAuth scopes (MCP permissions) matching identities are allowed to invoke.

For example:

If agents satisfy the conditions, they will receive mcp:schedule_meetings scope access and be able to schedule meetings. Otherwise, the MCP server will deny write operations.

3. View & Define Rule Metadata

In the final step, provide a rule name and description to document the policy's purpose and validate the effective authorization result.

Recommended MCP Policy Patterns

Below are practical policy templates commonly used for internal and external MCP servers:

Internal MCP — Corporate Tenant Isolation

This policy restricts access to only users in specific corporate tenants (finance and operations) who are using internal agents, allowing them to create invoices and read calendar events.

Rule name: Internal MCP Corporate Tenants Only
Conditions:
user.tenantIds IN ["corp_finance", "corp_ops"]
tags CONTAINS "internal-agent"
Allowed Scopes:
* mcp:invoice.create
* mcp:calendar.read

External MCP — Read and Write Access

This policy grants read-only calendar access to users with the "calendar_editor" role.

Rule name: External MCP — Read Only Default
Conditions:
user.roles CONTAINS "calendar_editor"
Allowed Scopes:
* mcp:calendar.read

Access Only if Using Verified Agentic Identity

This policy allows verified agents to read and write calendar events and create invoices.

Rule name: Verified Agent MCP Access
Conditions:
tags CONTAINS "verified-agent"
Allowed Scopes:
* mcp:calendar.read
* mcp:calendar.write
* mcp:invoice.create