Agentic Identity Hub

The Agentic Identity Hub is Descope's control plane for AI agent identity. It covers every agent that calls your APIs, every tool your agents use, and every credential those tools need.

Why Agents Need Different Identity Infrastructure

Traditional IAM assumes software follows a script. A user clicks a button, an application calls a known endpoint, a service account holds a credential that rarely changes. The access pattern is knowable at deploy time.

Agents do not work that way. They reason about a task, choose tools at runtime, chain calls across services, and adapt based on what each step returns. Three assumptions that hold for traditional software break with agents:

1. Access patterns can be assigned ahead of time. An agent reasoning about a task chooses its tools at runtime. You cannot enumerate those choices in a config file before deployment.
2. A human can approve every meaningful action. At agent speed, they cannot.
3. Long-lived credentials are safe enough. An agent holding broad, static secrets is a blast radius waiting to happen, especially one that chains calls across services.

Descope issues short-lived, scope-limited credentials at the moment an agent needs them, evaluates policy against runtime context, and produces an audit trail that connects every action back to the originating user.

Where Descope Fits

Descope serves three distinct roles depending on how you use agents. Each maps to a use case below.

• Open your product to agents: Descope acts as the OAuth 2.1 authorization server for your APIs and MCP servers. External agents—Claude, Cursor, or agents your customers build—authenticate against Descope and receive scoped tokens. Your servers validate those tokens against Descope's JWKs with no additional middleware.
• Govern the agents you run: Your workforce IdP (Okta, Entra ID) continues managing human users. Descope handles the primitives your IdP was never built for: agent registration, per-tool scope enforcement, credential brokering to downstream services, and a complete audit trail of every agent action.
• Connect agents to external services: Descope brokers credentials to those services through Connections, so your agents exchange tokens for what they need at the moment of use rather than holding long-lived secrets.

All three patterns run on the same Descope project, with the same policy engine, user records, and audit log.

Use Cases

Open Your Product to Agents

You want agents—Claude acting on a user's behalf, an MCP client your customer built, a third-party integration—to reach your APIs and MCP servers without handing them a master key.

Descope acts as the OAuth 2.1 authorization server for your product. You define the scopes that map to actions inside it, design the consent screen users see, and Descope handles agent registration, token issuance, and lifecycle management.

• Resources define the OAuth-protected API and MCP Server endpoints agents can request access to.
• MCP server protection adds OAuth 2.1 auth, per-tool scope enforcement, and tenant isolation to any MCP server you operate.
• CIMD (Client ID Metadata Documents) lets MCP clients register using a hosted metadata URL — the recommended approach for new deployments.
• DCR (Dynamic Client Registration) lets clients self-register at runtime when CIMD is not supported.
• Consent flows are built on Descope Flows. Design the screen, add step-up MFA where scopes warrant it, and update without redeploying.

Govern the Agents You Run

Every agent your organization operates touches data, needs credentials, and needs a clear owner. Without a registry, you accumulate shadow agents faster than you can audit them.

Descope layers agent governance on top of the identity providers you already use. Your workforce IdP (Okta, Entra ID, etc.) keeps managing human users; Descope handles the lifecycle primitives they were never built for — agent registration, per-tool scope enforcement, credential brokering, and audit.

• Agentic Identity gives security teams a single directory of every agent: what it can reach, who owns it, and what it has done.
• Connections store the OAuth tokens and API keys agents need for downstream services. Agents request credentials at the moment of use rather than holding them.
• Policies filter scopes at token issuance and exchange time, evaluated against user roles, tenant ID, JWT claims, and agent attributes.
• Step-up authentication surfaces the accountable user when an agent attempts a sensitive action, without blocking routine work.
• Audit logs capture every registration, token issuance, policy decision, and credential access, and stream to your SIEM.

Connect Agents to External Services

You build agents that call Salesforce, GitHub, internal APIs, or other third-party services — without embedding long-lived secrets in the agent itself.

Descope vaults downstream credentials in Connections and issues them on demand via token exchange (RFC 8693). The agent authenticates once with Descope; each tool call gets a narrow credential scoped to that service and action.

• Connections store OAuth tokens and API keys; agents fetch them at the moment of use rather than holding them.
• Policies control which connections and scopes an agent can exchange for at runtime.
• Auth patterns covers passthrough, resource-scoped exchange, and connection brokering in full.

How Agents Get Access

Every time an agent uses a tool, Descope does four things:

1. Identify: Descope recognizes the agent from its registered client record, a cloud workload OIDC token (AWS or GCP), or credentials issued at runtime via DCR or CIMD.
2. Authorize: Policies enforce what the agent can access. For client_credentials flows, policies control which scopes the client is permitted to request at the token endpoint. For authorization_code flows, policies control which scopes a user can consent to in the consent screen. Either way, the agent receives only what policy allows.
3. Protect: Resources validate Descope-issued tokens natively using your Descope project JWKs. No middleware required.
4. Broker: When a tool needs a different credential—a narrower scope, a different audience, or a third-party API key—Descope exchanges the base token at the token endpoint (RFC 8693) on demand. No re-authentication, nothing stored on the agent.

This loop runs for every agent in your system, whether it acts on behalf of a user, runs autonomously, or authenticates via a cloud workload identity provider.

For credential issuance patterns, integration architectures, and the full lifecycle map, see How the Agentic Identity Hub works.

All three patterns share one foundation in your Descope project: the same user records, policy engine, connections vault, and audit log. A user who authorized an MCP client is the same subject a policy evaluates when an internal agent acts on their behalf—nothing is configured twice.

Core Components