Agent Authorization

Policies are allow rules that control who can access which Resources and Connections, and with which scopes.

See our Policies doc for the full guide: subjects, targets, grant types, and how to author rules in the Console.

For agents specifically, policies answer two questions at runtime:

• Resource targets: Which scopes can this agent receive on a backend API or MCP server access token?
• Connection targets: Can this agent retrieve a third-party Connection token from the Vault, and with which scopes?

How Policies Are Enforced for Agents

See How Policies Are Enforced for grant-type behavior across all applications. For agents, evaluation differs by target:

Resource Targets

The access token a policy governs here is the one your MCP server or backend API validates at runtime.

User access (authorization code): the flow most user-delegated agents use:

1. Scope request: The client calls /authorize with requested scopes. Descope confirms the client configuration allows those scopes.
2. Policy filtering: Descope evaluates matching policies (user.roles, user.tenantIds, client.tags, JWT claims, and other condition keys). Scopes that no policy permits are removed and do not appear on the consent screen.
3. User consent: The user authenticates and approves the remaining scopes. The user can only consent within what an admin has allowed via policy.
4. Token issuance: Descope issues an access token carrying the intersection of client-allowed scopes, policy-permitted scopes, and user-consented scopes.
5. Runtime enforcement: The Resource validates the token on each request. An MCP server does this when tools are invoked.

Delegated access (token exchange) and M2M (client_credentials) skip consent. Descope evaluates the policy during the token request and returns only the scopes the policy permits.

Connection Targets

Connection policies are enforced when a Descope JWT is exchanged for a Connection token from the Vault. This is always a token exchange, with no consent screen:

1. Token exchange request: An agent presents a Descope access token and requests a Connection token.
2. Policy evaluation: Descope checks whether the subject may retrieve a token for the requested Connection and which scopes it may carry.
3. Connection token issuance: If a matching policy permits the exchange, Descope returns a scoped Connection token. Otherwise the exchange is denied.
4. Runtime enforcement: The downstream service enforces scopes when the agent calls its API.

Recommended Policy Patterns

Common agent patterns use user.roles and user.tenantIds from SSO group mapping - see SSO User and Group Mapping for setup details.

Resource Targets

Internal MCP: Corporate Tenant Isolation

Restricts access to users in finance and operations tenants using internal agents:

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-Only Access

Read-only calendar access for 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

Verified agents receive read/write calendar and invoice scopes:

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

Backend API: Read-Only for Delegated Agents

Agents acting on a user's behalf via token exchange receive read-only Orders API access:

Rule name: Orders API - Delegated Read Only
Conditions:
client.tags CONTAINS "verified-agent"
Allowed Resource: orders-api
Allowed Scopes:
* orders.read
Grant types: Delegated access (token exchange)

Tenant-Scoped Scheduler (SSO groups → roles)

Users mapped from an IdP "Schedulers" group to a Descope role, scoped to specific tenants:

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

Connection Targets

Read-Only Calendar Access for Standard Users

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

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

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

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