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.

The recommended pattern puts that Resource between the agent and the Connections vault, so the Resource fetches third-party credentials at runtime and the agent never holds them. See Keep Credentials off the Agent for more details. Policies govern access to both Resources and Connections.

Where Descope Fits

Descope covers both external agents, your customers' agents reaching what you build, and internal agents, your employees' agents reaching company and third-party tools. Across both, Descope does three jobs, each covered in Use Cases:

• Protecting the APIs you build, whether agents call them as MCP servers or REST APIs
• Protecting third-party APIs that your employees' agents use
• Building agents that authenticate and get the tokens their tools need

All three run on the same Descope project, with 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, so nothing is configured twice.

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 and the full lifecycle map, see Auth Patterns.

Core Components

The Hub is built from a small set of components. Every use case above combines the same pieces.

Guides

The guides below put those components together for a specific job.