Agentic Identity Hub

The Agentic Identity Hub is Descope's system for managing authentication, authorization, and external credentials for AI agents and MCP servers.

It provides a centralized control plane to define who an agent is, what it is authorized to do, and under whose authority it acts.

What Is an Agentic Identity?

An agentic identity represents a software agent that can act autonomously or on behalf of a user or tenant. Unlike traditional service accounts or static machine credentials, agentic identities are designed for runtime decision-making systems that require:

• Non-interactive and machine-to-machine authentication
• Fine-grained, capability-based authorization
• Just-in-time creation and decommissioning
• Short-lived credentials by default
• Explicit delegation and traceability

Agents are treated as first-class identities, either operating independently or acting on behalf of a human user through explicit delegation.

Why Agentic Identity Is Needed

Traditional IAM systems are built for people—they assume interactive logins, long-lived users, and static roles. Agents operate differently: they authenticate programmatically, may exist only for a single task, require narrowly scoped access, and their actions must be attributable independently of users.

The Agentic Identity Hub is built specifically to support these patterns, preventing agents from reusing human tokens, preserving delegation chains, enforcing authorization policies, and ensuring complete auditability.

Core Components

The Agentic Identity Hub consists of four main components:

Agentic Identity

The Agentic Identity section provides a centralized view of all agentic identities in your system. You can view, filter, and manage agents, inspect their attributes (ID, name, tags, associated user, tenant, MCP server connections), and see which scopes they've been granted.

Agents can represent dynamically registered MCP clients (via CIMD or DCR) or manually registered agents.

MCP Servers

MCP servers expose tools and capabilities to agents. The Agentic Identity Hub secures MCP servers by enforcing OAuth 2.1 authentication, applying per-agent and per-tool authorization scopes, isolating tenants and execution contexts, evaluating authorization policies on every request, and auditing all tool execution and access decisions.

Each MCP server acts as an independent OAuth provider with its own discovery endpoint, authorization server, and client registration capabilities.

Connections

Connections store external credentials (OAuth tokens and API keys) that agents use to access third-party systems. They abstract credential handling away from agents and application code, providing secure storage, automatic token refresh, encryption, and rotation.

Connections can be scoped per agent, user, or tenant, and agents never store or manage raw credentials directly. Connections are commonly used within MCP servers as a token vault for external service tokens required to execute MCP tools.

Learn how to create connections, store connection tokens, and fetch connection tokens.

Policies

Policies define authorization rules for MCP servers, controlling who can access your MCP server and which tool-level scopes they are allowed to invoke. Policies are allow policies that take effect automatically as soon as they are created.

During token issuance, policies evaluate conditions based on user roles, tenant IDs, permissions, JWT claims, and client tags/names. Policies then filter the requested scopes, ensuring that tokens for specific agents only include scopes that are allowed by matching policies.

How It Works

The Agentic Identity Hub manages the complete authentication, authorization, and credential management for MCP servers and AI agents that connect to your MCP servers. The following diagram illustrates a complete example using all components of the Agentic Identity Hub:

Step-by-Step Flow

1. Client Registration: The MCP client discovers the MCP server's OAuth authorization server metadata and registers dynamically with Descope using Dynamic Client Registration (DCR) or Client ID Metadata Documents (CIMD). The client receives credentials from Descope.

2. User Authorization: The MCP client initiates an authorization request, opening a browser for the user to authenticate. Descope runs the User Consent Flow, which may include SSO, MFA, and other authentication steps.

3. External Service Connection (optional): If the MCP tool needs to access third-party APIs, the user can connect to external OAuth providers during the consent flow using Connections via Adaptive Connect or Connection actions in Descope Flows. Descope stores the external service's access and refresh tokens in the Connection vault for future use.

4. Token Issuance: After user consent, Descope issues an access token to the MCP client. This token includes:

   • Approved scopes (filtered by Policies)
   • The aud claim (bound to the MCP server URL)
   • User and tenant context

5. Tool Execution: The MCP client invokes a tool on the MCP server, sending the Descope access token. The MCP server validates the token, checks the aud claim, and verifies required scopes.

6. External Credential Retrieval (if needed): If the tool needs to call a third-party API, the MCP server retrieves the previously stored external service token from Descope Connections. The MCP server uses the same Descope access token to request the external service token, and Descope evaluates access control policies before returning the appropriate token.

7. API Call & Response: The MCP server uses the external service token to call the third-party API, executes the tool logic, and returns the result to the MCP client.

Throughout this flow, all actions—client registration, user authentication, token issuance, policy evaluation, credential access, and tool execution—are logged for complete auditability.

For detailed information on each component, see the documentation links above.