Policies

The Policies page is where you create and manage authorization rules that govern what agents and users can access across your MCP servers and Connections. From here you can:

• Create policies that define which users or clients can request specific scopes, based on roles, tenant membership, JWT claims, and client tags
• View all active policies and understand which rules are currently in effect across your project
• Delete policies to immediately remove their effect — there is no disable state; a policy is either active or gone

There are two types of policies, each enforced at a different point in the agentic identity lifecycle:

Both policy types follow an allow model with least-privilege defaults. Scopes are only granted if explicitly permitted by a matching policy, and policies take effect automatically as soon as they are created. Deleting a policy removes its effect immediately.

Conditions and operators are shared across both policy types, so the authoring experience is consistent.

MCP Server Policies

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

MCP Server Policies determine which tool-level scopes a user can consent to and receive on their access token.

Policy Evaluation & Enforcement

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

1. Scope request: The MCP client initiates an /authorize request with requested scopes. Descope confirms the client configuration permits those scopes. If a scope is not allowed by the client configuration, the request returns an error.

2. User consent: The user authenticates and is shown a consent screen listing the requested scopes. They approve or deny each one.

3. Policy evaluation: Descope evaluates applicable MCP Server Policies to determine which consented scopes can be issued. Policies filter scopes based on user attributes, tenant context, client tags, and JWT claims.

4. Token issuance: An access token is issued with the intersection of: scopes allowed by the client configuration, scopes permitted by applicable policies, and scopes consented to by the user.

5. Runtime enforcement: The MCP server validates the access token and enforces scopes when tools are invoked.

Creating MCP Server Policies

Policies are authored in three logical steps.

At this time, the Policies page is the only available place to manage policies in the Agentic Identity Hub. Policies cannot be managed with Terraform or via APIs at this time.

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 and who is part of Tenant-A or Tenant-B.

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 Server 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"]
client.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:
client.tags CONTAINS "verified-agent"
Allowed Scopes:
* mcp:calendar.read
* mcp:calendar.write
* mcp:invoice.create

Connections Policies

Connections let agents retrieve downstream third-party tokens (for example, Google, Slack, GitHub) from the Descope Connections Vault by exchanging a Descope user access token.

Connections Policies govern that exchange: which Connections the agent can access on behalf of its user or tenant, and which scopes the resulting Connection token is permitted to carry.

Policy Evaluation & Enforcement

The exchange flow works as follows:

1. Token Exchange Request: An agent presents a Descope user access token and requests a Connection token for a specific Connection.

2. Policy Evaluation: Descope evaluates applicable Connections Policies against the user attributes, tenant context, and JWT claims on the inbound access token to determine:

   • Whether the associated user is allowed to retrieve a token for the requested Connection
   • Which scopes the issued Connection token is allowed to carry

3. Connection Token Issuance: If a matching policy permits the exchange, Descope returns a Connection token scoped to the allowed permissions. If no policy matches, the exchange is denied.

4. Runtime Scope Enforcement: The downstream third-party service enforces the scopes on the Connection token when the agent calls its API.

Creating Connections Policies

Connections Policies are authored using the same three-step structure as MCP Server Policies, with the same condition keys and operators.

1. Who This Applies To (Conditions)

Connections Policies support the full set of condition keys documented in the MCP Server Policies section. Operators (Equal, Not equal, In, Not in, Contains) are also identical.

This means SSO-group-to-role mapping and tenant-based isolation work the same way for Connections as they do for MCP servers.

2. Select Connection(s) and Allowed Scopes

Choose one or more Connections this policy will govern, and define which scopes matching identities are allowed to receive on the Connection token.

For example, a policy could permit the Google Calendar Connection but restrict the issued token to read-only scopes for one set of users, while issuing read-write scopes for another.

3. View & Define Rule Metadata

Provide a rule name and description to document the policy's purpose and validate the effective authorization result.

Recommended Connections Policy Patterns

Read-Only Calendar Access for Standard Users

This policy permits standard users to retrieve a Google Calendar Connection token, but restricts it to read scopes only.

Rule name: Calendar Read-Only — Standard Users
Conditions:
user.roles CONTAINS "user"
Allowed Connections:
* google-calendar
Allowed Scopes:
* https://www.googleapis.com/auth/calendar.readonly

Read-Write Calendar Access for Schedulers

This policy permits users with the "scheduler" role to receive read-write Google Calendar tokens.

Rule name: Calendar Read-Write — Schedulers
Conditions:
user.roles CONTAINS "scheduler"
Allowed Connections:
* google-calendar
Allowed Scopes:
* https://www.googleapis.com/auth/calendar

Tenant-Scoped Slack Access

This policy permits Slack Connection access only for users in specific corporate tenants.

Rule name: Slack Access — Corporate Tenants
Conditions:
user.tenantIds IN ["corp_finance", "corp_ops"]
Allowed Connections:
* slack
Allowed Scopes:
* chat:write
* channels:read

Verified Agent Access to GitHub

This policy permits only agents tagged as verified to retrieve GitHub Connection tokens.

Rule name: GitHub Access — Verified Agents Only
Conditions:
client.tags CONTAINS "verified-agent"
Allowed Connections:
* github
Allowed Scopes:
* repo
* read:org