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

At a glance

What this is: Descope’s agentic identity stack extends OAuth-based authentication and authorization to AI agents and MCP servers, with the key finding that agentic access now needs lifecycle and policy controls, not just login plumbing.

Why it matters: IAM teams now have to govern machine-like identities that request scopes, connect to tools, and inherit tenant-specific policy, which changes how NHI, autonomous, and human access programmes are designed.

By the numbers:

• Descope has raised a total of $88M in seed funding to expand into agentic identity for AI agents and MCP ecosystems.
• Descope’s free tier supports up to 7,500 MAUs or 50 tenants.
• 99.99% uptime for covered enterprise services., prise services.

👉 Read WorkOS's analysis of Descope's Agentic Identity Hub and MCP auth

Context

Primary keyword focus: agentic identity for MCP servers and AI agents is moving from theory to implementation, and that changes the identity model practitioners must use. OAuth 2.1, PKCE, and dynamic client registration can be valid building blocks, but they do not remove the governance burden around consent, scope, token handling, and revocation.

The governance gap is not authentication alone, but how quickly delegated access becomes operational identity debt when agents connect to external tools and remote resources. For B2B SaaS and enterprise teams, the practical question is whether an external IAM stack can support agentic access without creating a second, hard-to-audit identity plane.

Key questions

Q: How should security teams govern AI agents that connect to multiple SaaS tools?

A: Security teams should govern each agent as a distinct non-human identity with its own owner, scopes, lifecycle state, and revocation path. The important control is not just authentication, but whether each tool connection can be reviewed, logged, and withdrawn independently when the agent’s role changes or its behaviour drifts.

Q: What breaks when AI agent access is treated like a normal app integration?

A: What breaks is accountability. Agent access can spread across multiple tools, tenants, and token stores, so a single onboarding event does not describe real authority in production. Without separate review for each connection, teams lose visibility into what the agent can do, what it actually does, and how to remove access cleanly.

Q: How do organisations know if agentic identity controls are actually working?

A: They should look for auditable consent histories, fast revocation, accurate scope logging, and blocked-request telemetry that matches policy. If an agent can connect new tools without a review trail, or if revocation does not remove effective access quickly, the control model is failing even if authentication succeeds.

Q: Should teams unify CIAM, B2B auth, and MCP access under one platform?

A: Only if the platform can keep human users, customer tenants, service-style integrations, and agentic access clearly separated in policy and audit. Unification can reduce operational sprawl, but it also concentrates failure if lifecycle ownership and permission boundaries are blurred across identity types.

Technical breakdown

OAuth 2.1 for AI agents and MCP servers

Descope’s model treats agents and remote MCP servers as OAuth clients and protected resources, using OAuth 2.1 with PKCE, authorization server metadata, protected resource metadata, and optional dynamic client registration. That is structurally sound for delegated access, but it still depends on clear scope design and durable token governance. In practice, the security model is not “agent authentication” in the abstract, but whether the authorization server can express narrow consent, revoke access cleanly, and keep token issuance aligned to tenant policy.

Practical implication: validate how consent, scope, and revocation behave across every tool path before you allow production agent traffic.

Inbound and outbound agent identity patterns

Inbound Apps make an application act as an OAuth provider so agents can call it with scoped consent. Outbound Apps let agents connect to third-party SaaS tools using prebuilt OAuth integrations, which removes custom token plumbing but expands the trust boundary to many external services. The security issue is that outbound agent access often looks like a simple integration until you map the number of permissions, refresh tokens, and downstream systems that inherit the agent’s authority.

Practical implication: inventory every downstream SaaS integration as a separate access path, not as a single agent permission.

Lifecycle control plane for agent identities

The Agentic Identity Control Plane adds policy guardrails, audit events, and lifecycle control over registrations, consents, and revocations. That is a governance layer, not just an auth feature, because agents can accumulate access over time across multiple tools and tenants. The architectural point is that lifecycle state becomes part of the security model: if consent history, blocked requests, and revocation are not machine-readable, you lose the evidence needed for access review and incident reconstruction.

Practical implication: require auditable lifecycle events for every agent, tool connection, and revocation path before scaling deployments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic identity is an NHI governance problem first and an auth problem second. The article is really about how AI agents, MCP servers, and delegated SaaS access collapse into one identity plane. OAuth 2.1 and PKCE are necessary mechanics, but they do not answer who owns the lifecycle, who certifies the scopes, or how consent is revoked when an agent outlives its original task. Practitioners should treat agentic identity as governed NHI, not as a product feature category.

Scope-based access is becoming too dynamic for static onboarding assumptions. Traditional external IAM assumes the party being onboarded remains relatively stable, but agents can connect to new tools, register new clients, and expand their operational footprint quickly. That creates what we can call agentic scope drift: permissions that appear bounded at setup but widen as integrations, tenants, and tool paths accumulate. The implication is that entitlement review must move closer to runtime usage patterns.

Consent history is now an identity control, not just an audit artifact. The article’s emphasis on streaming audit events, blocked requests, and revocation history shows that the governance surface has shifted from login success to behavioural evidence. That matters because enterprise teams need to know not only whether an agent authenticated, but what it was authorised to do, what it attempted, and how quickly those permissions can be withdrawn. Practitioners should build review processes around consent lineage, not just access lists.

Enterprise AI programmes will force IAM teams to reconcile CIAM, B2B auth, and MCP governance in one operating model. The market is moving toward unified external identity platforms that can support humans, workloads, and agents side by side. That may simplify vendor sprawl, but it also increases the blast radius of design mistakes because one policy layer may now govern customer users, service integrations, and autonomous tool access together. Practitioners should re-evaluate whether their identity stack can separate these governance needs without fragmenting visibility.

Workload-style controls are now the baseline for agent access, but they are not the finish line. The article shows why OAuth, metadata discovery, and token handling matter, yet the harder problem is lifecycle ownership across tenants and tools. Agentic identity inherits the same non-human identity patterns that have long challenged service accounts, only with faster connection churn and more opaque execution paths. Practitioners should assume agent governance will fail where lifecycle and policy ownership are unclear.

From our research:

• Descope has raised a total of $88M in seed funding to expand into agentic identity for AI agents and MCP ecosystems, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For a broader NHI governance lens, see Ultimate Guide to NHIs for lifecycle, rotation, and offboarding patterns that still matter when identities become agentic.

What this signals

Agentic scope drift: once an AI agent can connect to multiple tools, the governance problem is no longer whether authentication works, but whether every connection is still justified, visible, and revocable. In practice, this means identity teams need a review model that tracks consent lineage and downstream tool access, not just application login status.

The article’s emphasis on agentic identity control planes suggests the market is converging on policy, audit, and lifecycle features as core requirements rather than add-ons. For practitioners, that means evaluating whether current IAM and NHI processes can distinguish between human users, service-style integrations, and agentic actors without collapsing them into one entitlement review workflow.

Only 44% of organisations have implemented policies to govern AI agents, according to SailPoint research on the new attack surface, which is why the next phase of adoption will be judged by operating discipline rather than feature breadth. Teams that can map ownership, consent, and revocation across tool chains will be better positioned to scale safely.

For practitioners

• Map every agent to an accountable owner Assign a named business and technical owner for each agent, MCP server, and outbound integration. Tie that owner to revocation authority, incident response duties, and periodic access review so no agent sits outside a clear governance chain.
• Separate onboarding from runtime authority Treat initial consent as the start of governance, not the end. Record which scopes were requested, which were approved, and which permissions are actually exercised in production so drift can be detected before it becomes normalised.
• Review agent-to-tool relationships individually Do not certify an agent as a single identity if it has multiple third-party connections. Evaluate each SaaS path, each refresh token, and each MCP server as a distinct access surface with its own expiry, logging, and revocation requirements.
• Build revocation tests into change management Test whether access can be withdrawn cleanly from each agent path without breaking unrelated workloads. Confirm that token revocation, consent removal, and blocked-request logging all behave as expected before broad deployment.

Key takeaways

• Agentic identity combines authentication, consent, and lifecycle governance into one NHI problem that existing IAM programmes often split apart.
• As agents connect to more tools, scope drift and consent sprawl become the practical failure modes that matter most.
• Teams need auditable ownership and revocation paths for every agent-to-tool connection before they scale production use.

Key terms

• Agentic Identity: Agentic identity is the set of authentication, authorization, and governance controls used for AI agents that can act on external systems. It extends NHI management because the identity can request scopes, connect tools, and trigger actions at runtime, so ownership and revocation matter as much as login.
• MCP Authorization: MCP authorization is the access control layer used for Model Context Protocol clients and servers. In practice, it usually relies on OAuth 2.1, metadata discovery, and scoped consent so an agent or tool can discover how to authenticate without hardcoding credentials or bypassing tenant policy.
• Consent Lineage: Consent lineage is the traceable history of which permissions were requested, approved, exercised, and revoked for a non-human identity. It matters because agentic access can expand across tools and tenants over time, and review processes fail if they cannot reconstruct that path.
• Agentic Scope Drift: Agentic scope drift is the gradual expansion of an AI agent’s effective authority after initial approval. The agent may stay authenticated while its real-world access grows through new integrations, reused tokens, or additional tool registrations, which makes the original consent record incomplete.

Deepen your knowledge

Agentic identity for MCP servers and AI agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for delegated access across tools and tenants, it is worth exploring.

This post draws on content published by WorkOS: Descope for AI Agent Security: Features, Pricing, and Alternatives. Read the original.