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.

Resources and Connections

Two nouns anchor everything in the Hub, and they are easy to mix up:

• A Resource is what an agent connects to: an API or MCP server you protect with Descope, identified by an audience (its URL) and a catalog of scopes. When an agent asks Descope for a token, it names that audience: a standardized way of saying "this is what I am trying to access." Every access token, and every ID-JAG, is issued for a Resource.
• A Connection is where Descope stores the tokens and API keys an agent uses on a user's or tenant's behalf, such as a Google or Slack OAuth token a tool needs downstream. A Connection is a credential vault, not a target an agent authenticates into.

The working model

Define a Resource for each thing an agent should be able to reach. That can be one Resource per internal service, or a single Resource for a gateway you run that fronts many downstream MCP servers and APIs. Either way, the Resource's audience is what the agent's token is minted for, and Descope is the authorization server that protects it.

Keep long-lived credentials off the agent. An agent can fetch a Connection token directly, but the recommended pattern puts a Resource, an MCP server or gateway, between the agent and the Connections vault. The agent authenticates to the Resource and gets a short-lived, scoped token; the Resource pulls the API key or external OAuth token from Connections at runtime and calls the downstream service. The agent never holds the third-party secret, which is often long-lived.

Policies govern access to both Resources and Connections.

Where Descope Fits

Descope serves three jobs in the Agentic Identity Hub. Each is covered in full on Use cases.

• Building an MCP server: Descope is the OAuth 2.1 authorization server for your MCP server (MCP Auth) — consent, agentic identities, Connections, Bring Your Own Auth, and more.
• Building agents: Use the Agent Auth SDK and Clients, with Resources to protect what you own and Connections as a token vault for third-party services.
• Governing agents internally: Use XAA or a gateway so pre-built clients in your enterprise reach third-party tools under one IdP — choice depends on features you need and XAA support.

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

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 which of the three jobs fits your project, see Use cases. 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