Descope’s agentic identity hub raises the stakes for MCP governance

At a glance

What this is: This is an analysis of Descope’s agentic identity approach for MCP and AI agents, with the core finding that OAuth-based delegation now has to be governed as a living lifecycle rather than a one-time integration.

Why it matters: IAM, PAM, and NHI teams need to treat agent authorization, consent, and revocation as runtime governance problems because MCP-connected agents can expand access far beyond traditional human login patterns.

Context

Agentic identity for MCP servers is the problem of governing how AI agents and remote MCP endpoints authenticate, request scope, receive consent, and lose access over time. The article argues that OAuth 2.1 and PKCE are appropriate building blocks, but the governance burden shifts from initial setup to ongoing control of delegation, revocation, and lifecycle.

For identity teams, the key question is not whether agents can use OAuth, but how their access is inventoried, bounded, audited, and removed when the surrounding workflow changes. That makes MCP authorization part of the wider NHI lifecycle problem, especially where external SaaS integrations and tenant-scoped policies are involved.

Key questions

Q: What breaks when MCP agents are given OAuth access without lifecycle governance?

A: Consent, token issuance, and client registration can remain technically valid after the original workflow has changed, which leaves an active agent connection that nobody is clearly responsible for removing. The practical failure is not authentication itself, but lingering delegated access that cannot be cleanly retired across every connected tool.

Q: Why do agentic identity controls change the way teams think about risk and accountability?

A: Because the access decision is no longer a one-time human login, the real risk shifts to who can approve, review, and revoke agent connections over time. Accountability has to include the identity owner, the policy owner, and the team that can actually terminate the delegation chain.

Q: How should teams detect when agent access is broader than intended?

A: Look for agents that connect to multiple SaaS tools, re-register repeatedly, or carry scopes that are consistent across very different tasks and tenants. Those patterns usually show that delegation is being reused as a convenience layer rather than governed as a bounded identity state.

Q: What should security teams do when an MCP server sits behind multiple downstream tools?

A: Treat the MCP server as part of the identity surface, not just a protocol endpoint, and require separate authorization, audit, and revocation paths for each downstream tool it can reach. Otherwise one approved connection can become a shared access path across the rest of the environment.

Technical breakdown

How OAuth 2.1 and PKCE map to MCP authorization

MCP server authorization commonly uses OAuth 2.1 with PKCE because the agent or client is not a confidential browser session and cannot safely hold a static client secret. PKCE adds proof of possession at the authorization-code step, while authorization server metadata and protected resource metadata let clients discover how to authenticate and what scopes exist. Dynamic client registration extends that model so an agent can register at runtime instead of relying on manual onboarding. The mechanism is sound, but it shifts trust into token issuance, scope definition, and revocation discipline.

Practical implication: treat MCP auth as a standards implementation problem first, then verify the governance controls around registration, scopes, and token lifetime.

Why agentic identity changes consent and revocation

In human IAM, consent and access changes are often episodic: a user approves once, then access is reviewed later. Agentic identity breaks that rhythm because the agent may connect to multiple tools, refresh tokens, and re-register across sessions as workflows evolve. That creates a lifecycle problem, not just an authentication problem. If consent history, token state, and client registration records are not tied together, revocation can be partial and temporary. The result is an identity that remains functionally active even after the original use case has changed.

Practical implication: tie consent, registration, and revocation records together so agent access can actually be terminated across every connected tool.

What policy-based control planes change for NHI governance

A policy-based agentic control plane adds an enforcement layer above raw OAuth flows by applying roles, claims, scopes, audit events, and lifecycle actions to agent identities. That matters because remote MCP servers and outbound SaaS integrations create a wider attack surface than a single app-to-app integration. The control plane becomes the place where human-administered policy is translated into machine-enforced scope and identity state. Without that layer, enterprises end up with a collection of technically valid connections that are operationally hard to govern.

Practical implication: centralize policy, audit, and lifecycle decisions for agent identities instead of letting each MCP integration manage itself.

Threat narrative

Attacker objective: The attacker objective is to preserve valid delegated access long enough to move through connected tools and data flows without triggering timely revocation.

1. Entry occurs when an AI agent or remote MCP client obtains OAuth-based access to a protected resource through a registration or consent flow.
2. Credential exposure or abuse can follow when tokens, client registrations, or delegated scopes persist beyond the original workflow boundary.
3. Impact emerges when the agent continues to call downstream tools or APIs with valid delegated access after governance visibility has degraded.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth for agents is not the governance problem. Lifecycle control is. The article is right to treat OAuth 2.1, PKCE, and dynamic client registration as valid primitives for MCP access. The hard part is that those primitives only prove the session boundary, not whether the delegated identity should still exist tomorrow. Practitioner implication: the governance model has to move from login assurance to continuous delegation oversight.

Agentic identity creates revocation debt: access decisions are made quickly, but the cleanup burden accumulates across consent, token issuance, registration, and downstream SaaS connections. That is a structural NHI problem because the identity state can multiply faster than admins can inspect it. Practitioner implication: treat every agent connection as an object with a defined offboarding path, not as a one-time integration.

Ephemeral consent does not equal ephemeral risk. An agent can request narrow scopes and still create a broad blast radius if those scopes are replicated across multiple tools or tenants. The agent may look least-privileged at issuance while remaining overexposed in aggregate. Practitioner implication: scope design has to be evaluated across the full delegation chain, not inside a single authorization screen.

Agentic identity hub: the article sharpens the idea that identity governance for agents is a hub problem, not a point control problem. Registration, consent, audit, and revocation need to converge in one operating model because MCP access spans multiple systems and trust boundaries. Practitioner implication: evaluate whether your current identity architecture can enforce one governance state across all agent touchpoints.

WorkOS and Descope are converging on the same market truth: MCP authorization is becoming part of enterprise identity infrastructure, not a side feature. That signals a category shift where developers can no longer separate application auth from machine identity governance. Practitioner implication: identity teams should plan for MCP in the same programme scope as external IAM and NHI lifecycle management.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.

What this signals

Agentic identity hub: the market is moving toward centralised governance for AI agents, not ad hoc OAuth wiring. That matters because identity teams will be expected to manage registration, consent, audit, and revocation as one operational model across MCP and SaaS integrations.

MCP makes machine identity behave more like a living service relationship than a static application credential. Organisations that keep treating agent access as a point-in-time configuration will miss the ongoing control state that actually determines exposure.

For practitioners

• Map every MCP client to an explicit identity owner Assign an accountable business or platform owner to each agent, client registration, and protected resource relationship so revocation and audit have a clear source of truth.
• Require lifecycle state for every agent connection Track registration, consent, token state, and decommissioning together so a valid login does not outlive the business use case.
• Scope delegated access by tool and tenant Separate scopes for each SaaS tool and customer tenant so an agent cannot inherit broad access simply because one connection was approved.
• Log consent, refresh, and blocked requests centrally Use central audit events to correlate when an agent was approved, what scopes were issued, and when access was denied or removed.
• Review MAU economics for machine-driven usage Model how agent identities and machine-to-machine traffic affect pricing tiers, tenant limits, and platform expansion before broad rollout.

Key takeaways

• Agentic identity for MCP servers turns delegation, consent, and revocation into a lifecycle problem that traditional login-centric IAM processes do not fully cover.
• OAuth 2.1 and PKCE remain useful building blocks, but they do not by themselves solve ownership, offboarding, or cross-tool scope control for agents.
• The practical control gap is not whether an agent can authenticate, but whether the organisation can reliably retire every delegated path when the workflow changes.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.