Use Cases
The Agentic Identity Hub covers three common jobs. Pick the one that matches what you are building; many projects use more than one.
| You are… | Start here |
|---|---|
| Building an MCP server | MCP Auth — consent, OAuth 2.1, agentic identities, Connections, Bring Your Own Auth, and more |
| Building agents | Agent Auth SDK and Clients, plus Resources and/or Connections |
| Governing agents internally | Enterprise-Managed Authorization — XAA or a gateway, based on features and protocol support |
Building an MCP Server
You are exposing tools over MCP and need authentication and authorization in front of them. Use MCP Auth (Descope as the OAuth 2.1 authorization server for your MCP server).
That gives you a full product surface, including:
- Consent management — users approve what an MCP client may do, with scopes and consent flows
- Bring Your Own Auth — keep your existing identity system and still protect the MCP server with Descope
- First-class agentic identities with OAuth 2.1 — clients register via CIMD or DCR, and every agent that connects is a managed identity
- Connections — vault third-party service tokens and API keys your tools need downstream
- Policies, tenant isolation, and the rest of the Hub shared with agents you run yourself
Start with the MCP overview and the MCP server guide. If other enterprises will connect their agents to your server using their workforce IdP, also see Let customers manage their agents.
Building Agents
You are writing the agent (or agent runtime) yourself. You will typically use:
- The Agent Auth SDK — sign the agent in to Descope and obtain the credentials its tools need
- Clients — register the agent as an OAuth client (pre-registration, workload identity support, and related OAuth functionality)
Then choose how the agent reaches what it calls:
| Target | What to use |
|---|---|
| APIs or MCP servers you protect with Descope | Resources — Descope mints short-lived tokens for that audience; your Resource validates them |
| Third-party services you do not protect | Connections — vault OAuth tokens and API keys; fetch them at runtime instead of embedding secrets in the agent |
You do not need Enterprise-Managed Authorization (XAA / gateway) for this path unless you also want the same governance story you use for pre-built clients. For how tokens move between Resources and Connections, see Auth patterns.
Governing Agents Internally
You need to decide which agents inside your company may reach which third-party MCP servers and APIs — especially when the client is something you do not control (Claude Code, VS Code, Cursor) and the tool is something you do not protect with Descope (HubSpot, Asana, and so on).
That is Enterprise-Managed Authorization. There are two main ways to connect, and the choice depends on what features you need and whether the client and third-party resource support XAA:
| Approach | When it fits |
|---|---|
| Cross App Access (XAA) | The client and the third-party resource support XAA / ID-JAG. Descope mints a short-lived assertion; nothing sits between the agent and the tool. |
| Gateway | The target does not support XAA, or you need gateway-only capabilities (prompt-injection detection, central inspection of tool calls, unified audit, tenant-scoped credential routing, and so on). |
Many enterprises use both. Full setup: Manage agents in your enterprise. Protocol detail: How XAA and ID-JAG work.
XAA is also useful when a client like Claude talks to an MCP server you built: Descope can be both the issuer (for the client) and the validator (for your MCP Resource). See Manage agents together with MCP Auth.