Use Cases

The Agentic Identity Hub covers agents on both sides of your company's boundary:

• External agents: Your customers' agents. They call the MCP servers and APIs you ship as a product, on behalf of users who sign in to your product: consumers with no tenant, or business users whose company is usually set up as a tenant
• Internal agents: Your employees' agents, such as Claude Code, Cursor, or agents your teams build. Identity comes from your workforce identity provider through SSO

The same building blocks serve both sides: Resources, Clients, Policies, and Connections. Whether agents call an API as an MCP server or as a plain REST API, you define it in Descope as a Resource, Descope acts as the OAuth authorization server that issues tokens for it, and the API validates those tokens before serving a request.

A gateway in front is optional on either side. With one, the gateway is the Resource agents connect to, and it exchanges their token for each API's own token.

Select a row to see what Descope does and jump to that section.

External Agents

Whether your customers are consumers or companies, Descope gives their agents the same three things:

• A way to identify themselves: The agent finds your MCP server's authorization details through its discovery endpoint, then registers as a client through CIMD or DCR, so it gets an agentic identity of its own
• A way to sign in the user they act for: The user signs in with any method your product supports and approves the agent's scopes on a consent screen
• A token your backend can trust: Your API gets an access token for its own audience that says which user the agent acts for, which agent is calling, and which scopes the user approved and policies allowed

What changes between consumer and business customers is how users sign in and how their data is kept apart.

Protecting the APIs You Build

For MCP servers, MCP Auth handles discovery, registration, consent, and per-client policies for you. Start with the MCP server guide. For REST APIs, define an API Resource with scopes mapped to roles.

Consumer products have no tenant. Users sign in to your MCP server the same way they sign in to your app, such as with passkeys or social login, and land on their existing user record, so your API sees the same user ID it already knows. Policies still decide which agents get which tools, for example keeping booking tools away from clients you haven't verified. The Travel Booking MCP Server example builds this end to end.

Business customers are usually tenants, and their users often sign in through their company's SSO, though any sign-in method works. When a user picks their company on the consent screen, Descope puts that tenant in the token's dct claim. Your API filters tools and data by dct, and policies decide which scopes each tenant can be granted, so one MCP server can serve every customer without separate infrastructure. The Multi-Tenant MCP Server example builds this end to end. If a customer's workforce identity provider supports Cross App Access (XAA), you can also accept their XAA tokens on that customer's tenant, so their employees skip your login and consent screen.

In both cases, if your product already has its own login, homegrown or from another vendor, Bring Your Own Auth keeps it as the source of truth: users sign in with your system, and Descope issues the tokens your API checks.

When your API calls third-party services on a user's behalf, like reading their Google Calendar or a business customer's HubSpot, Connections hold those credentials, and your API fetches them at runtime instead of storing secrets. For business customers, Connections can belong to a tenant, so each customer's OAuth app, API key, or base URL stays separate. See Per-Tenant Connections to set them up.

When to Add an External Gateway

You don't need a gateway to serve many customers, because the token and policies already keep users and tenants apart. An external gateway is an architecture choice, for example to give each customer their own endpoint in front of the same servers, or to add routing, token exchange, and rate limits without changing servers you've already built. When to Use a Gateway goes through each reason, for internal and external gateways alike.

For MCP-specific layouts, such as one MCP server per customer behind a shared gateway, see Shared or Per-Customer MCP Servers.

Internal Agents

Inside your company, the goal is different. Every agent your employees run should reach your APIs and the third-party tools they use with access that follows your workforce identity, and you should be able to change that access in one place.

Protecting Your Company's APIs

Employees authorize their agents through your workforce identity provider with SSO, and policies can key off the roles and groups the provider sends.

With SSO alone, each server an agent connects to runs its own consent step. If the agent's client supports Cross App Access (XAA), Descope can issue the XAA token and also validate it at your MCP server, so an employee signs in once and their agent reaches every XAA-enabled server without another prompt. See Issue XAA Tokens for Your Agents for the setup.

Your internal APIs can also sit behind the same internal gateway you use for third-party APIs, without changing how they validate Descope tokens.

Protecting Third-Party APIs Internally

Your employees' agents also call third-party services like HubSpot, Asana, or Notion, often through clients you don't control, such as Claude Code or Cursor. You can't add Descope to a third-party service, so Descope protects those APIs from the outside: it sits as a layer between the agents and the third-party APIs, and stores the credentials for them in Connections, its credential vault.

The layer is usually an internal gateway, with Descope as its identity provider and policy decision point. Agents hold a token only for the gateway. When an agent calls a third-party tool, the gateway uses that token to fetch the employee's stored credential from Connections, so the agent never holds a third-party token or API key. Every call goes through the gateway, so you revoke an agent's access, or tighten what a group of employees can do, in one set of policies instead of in each MCP client's config.

The gateway can front your own servers and third-party ones at the same time. In the setup below, the gateway fetches a Connection token to reach a third-party MCP server, and exchanges for a Resource token to reach your internal MCP server, which then gets its own tokens for your APIs and Connections:

For what this looks like with remote MCP servers such as Notion or Linear, see Locking Down Your Own Agents' Traffic.

Employees connect their own accounts to Connections once, for example from the Admin Portal, and Descopers can add organization-owned API keys as tenant-level tokens. See Storing Connection Tokens for all the ways to connect accounts.

Gateway or XAA

Some third-party tools support Cross App Access (XAA). For those tools, Descope manages which agents can reach which tools and enforces those policies when it mints each XAA token, with nothing in the request path and no stored credential.

• XAA without a gateway: Fits when every tool supports XAA and you don't need controls in the request path
• A gateway: Fits when some tools don't support XAA, or when you want controls XAA doesn't provide, such as inspecting tool calls in one place
• Both: The gateway uses XAA for the tools that support it and Connections for the rest

Building Agents

When you write the agent yourself, whether it runs inside your company or ships in your product, Descope gives the agent its connectivity: a way to authenticate, and a way to get the tokens its tools need. The Agent Auth SDK handles both from the agent's side.

You register the agent as a client, including with workload identity when it runs on AWS or GCP, and the agent signs in to Descope to get a token of its own.

For third-party services, the recommended pattern puts a gateway or API you build between the agent and the stored credentials. The agent gets a short-lived token for your gateway or API, which you define as a Resource. Your gateway or API then fetches the third-party OAuth token or API key from Connections at runtime and makes the call, so the agent never holds a long-lived credential. See Keep credentials off the agent for more details.

How the agent reaches each service depends on who protects the service:

See Auth Patterns for how tokens move between agents, Resources, and Connections.

Agents That Act on Their Own

Not every agent has a user behind it. A scheduled job, a background worker, or a pipeline step signs in with client credentials or workload identity and acts as itself. Descope gives that client a single agentic identity, and since no user is there to consent, policies alone decide which scopes it can get. The APIs it calls validate its tokens the same way they validate tokens issued for a user.

See Autonomous Access for more on agents without a user.

Seeing and Revoking Agent Access

Every use case on this page creates agentic identities: one per client for agents that act on their own, and one per user for agents acting on someone's behalf. The Agentic Identity view in the Console lists them with filters, and lets you revoke an agent's access, one at a time or in bulk, without deleting its client. You can do the same through the Management API.

The Agentic Activity Dashboard shows agent activity across your MCP servers and Connections, and every policy denial is written to the audit trail, with or without a gateway. A gateway adds one record of every call that went through it. See Auditing Every Call for what a gateway logs.