Claude and ChatGPT access to MCP identity tools changes governance

At a glance

What this is: This is a Descope update about its MCP Server becoming available as a Claude Connector and ChatGPT Plugin, with 23 identity tools exposed to AI assistants for supervised access.

Why it matters: It matters because identity teams now have to govern what an AI assistant can read, change, and escalate inside identity infrastructure, not just what a human admin can do.

Context

MCP identity tools are now part of the governance surface for teams using AI assistants to operate identity infrastructure. When a hosted MCP server can read documentation, inspect configuration, manage users and tenants, and change authentication flows, the access model is no longer just human admin plus application role. The control question becomes how those tool calls are scoped, consented, and reviewed.

This change matters because the trust boundary shifts from an interface to an action path. Claude and ChatGPT are not merely reading data here; they can request elevation, move from read to write, and operate across identity objects that affect authentication, authorization, and auditability. That creates a governance problem that sits between NHI controls, IAM policy, and agent oversight.

Key questions

Q: What breaks when an AI assistant can call identity admin tools through MCP?

A: The control model breaks if teams assume the interface is only conversational. Once the assistant can read configuration, manage users, and change authentication flows, the real boundary is the tool catalogue and its elevation rules. Identity teams need to govern each action path separately or they will lose sight of what changed, who approved it, and which tenant was affected.

Q: Why do AI connectors create identity risk when they have system privileges?

A: Because the connector behaves like a high-trust runtime principal rather than a simple plugin. If it can read files, access secrets, or invoke commands, it can be abused even when the model itself is not compromised. Identity teams should govern that connector as an NHI with least privilege, ownership, and revocation rules.

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Should organisations let AI assistants manage identity settings across tenants?

A: Only if tenant scope is explicit, recorded, and reversible. Cross-tenant administration increases the blast radius of any misconfiguration or overbroad grant, so the organisation needs clear ownership, approval, and audit evidence for each tenant relationship. If that record does not exist, the assistant should remain read-only.

How it works in practice

How MCP tool exposure changes identity governance

MCP, or Model Context Protocol, lets an AI client discover and invoke tools exposed by a server. In this case, the Descope MCP Server exposes identity operations as discrete functions, which means the security boundary is no longer the model alone but the exact tool catalogue, its permissions, and the approval path for write actions. Read and write separation matters because it creates a governance layer between observation and mutation. The practical issue is not whether the assistant can talk to the platform, but which identity operations it can invoke, under what tenant context, and with what escalation rules.

Practical implication: Define MCP tool access as an identity control plane, not a convenience integration.

Why native connectors matter for consent and tenant scoping

A native connector or plugin changes the operational path because the AI client can initiate the connection flow inside its own interface. That means consent, tenant selection, and privilege elevation are now part of the tool lifecycle rather than an external admin step. The key governance issue is that the assistant becomes a delegated actor that can request broader access without becoming the final authority. For identity teams, the risk is less about a single tool and more about how easily a user can move an AI session from read-only inspection into write-capable administration across tenants.

Practical implication: Treat consent prompts and tenant selection as enforcement points that need policy, logging, and review.

Tool granularity is the real control surface

The article’s 23 tools are structured around identity objects and functions such as sessions, projects, access control, auth keys, flows, tenants, connect, tests, users, and audits. That granularity is helpful because it makes authorisation visible at the action level, not just at the application level. But it also means policy needs to be expressed with equal precision. A broad allowance for the connector is too coarse when one tool can read audit data while another can rotate secrets or impersonate users. The control model should mirror the action catalogue, not the marketing category of the integration.

Practical implication: Map each MCP tool to a discrete allow, deny, or elevation rule before enabling organisation-wide use.

NHI Mgmt Group analysis

MCP turns identity administration into a tool-governed access problem, not a dashboard problem. Once Claude or ChatGPT can call identity operations directly, the governance unit becomes the tool and its execution context, not the visible UI. That changes the control design from user-centric permissions to action-centric permissions, with a stronger need for scoped elevation, audit fidelity, and tenant isolation. Practitioners should treat every exposed MCP function as an identity action that must be authorised explicitly.

Read-only defaults are necessary but not sufficient when the same session can escalate. The article shows a path from inspection to write access, which means the meaningful control is not the starting mode but the escalation boundary. If an assistant can ask for elevation inside the same interaction, then the review problem becomes how elevation requests are triggered, approved, and logged. The implication is that session-level governance matters as much as account-level provisioning.

Tool catalogues create a new form of privilege segmentation for NHI and agentic workflows. The exposed 23-tool model makes privilege boundaries legible in a way many identity platforms still do not. That is useful because it allows practitioners to separate documentation lookup, audit review, user management, and secret rotation into distinct control classes. The lesson for the market is that agent-facing identity products will increasingly be judged by how precisely they constrain tool reach, not by how many tasks they can perform.

MCP identity exposure belongs in OWASP-NHI and agentic governance discussions at the same time. The system is not autonomous in this article, but it is still a non-human actor using identity-bound access paths. That means conventional NHI concepts such as secret scope, offboarding, and least privilege still apply, while agent-aware review adds a second layer of scrutiny. Practitioners should stop thinking of these integrations as a UI convenience and start treating them as governed machine access.

Native integrations accelerate adoption, but they also compress accountability. When the same experience spans Claude, ChatGPT, and the identity platform, it becomes easier for teams to forget which actor initiated a change and under what consent. That creates a governance gap between intent, execution, and review. The practical conclusion is that identity programmes need explicit records for who granted the assistant access, which tenant was selected, and which tool call changed state.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

MCP-based identity administration is moving the control point from application UI into action-level authorisation. For practitioners, that means the question is no longer whether an assistant can help with identity work, but which exact operations it can invoke and under what consent model.

Tool-bound privilege: when identity functions are exposed as discrete MCP tools, governance needs to follow the action catalogue rather than the hosting app name. That is the practical bridge between NHI-style least privilege and agent-facing administration.

Teams should expect more pressure to justify elevation boundaries, tenant scoping, and auditable change histories for AI-assisted admin sessions. The programme risk is not theoretical integration complexity, but the silent expansion of who can trigger privileged identity changes.

For practitioners

• Model MCP tools as separate control objects Inventory each exposed tool and assign it an explicit permission class, approval path, and logging requirement based on whether it reads data, changes state, or escalates access.
• Separate read and write governance for assistants Keep documentation search, configuration inspection, and audit review in a lower-risk tier than user creation, flow changes, key rotation, or impersonation capabilities.
• Make tenant selection auditable Record which tenant the assistant was granted for, who approved the connection, and whether the same session later requested broader write permissions.
• Review escalation paths inside the chat flow Test how the connector asks for elevated permissions, what the user sees before approving, and whether those approvals are preserved in a way auditors can reconstruct later.

Key takeaways

• AI assistants connected through MCP change identity governance because the control boundary shifts to the specific tools they can invoke, not the chat interface they use.
• Read-only access is only the starting point. The real risk appears when the same assistant session can request elevation and cross into write-capable identity administration.
• Practitioners should manage MCP tool exposure as a privileged access problem with explicit scoping, logging, and tenant-level accountability.

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Tool Catalogue: A tool catalogue is the list of actions, connectors, or capabilities an AI client can discover through an MCP server. When exposed without authentication, it can reveal internal structure, system names, and possible targets, giving attackers reconnaissance value before any direct compromise occurs.
• Consent flow: A consent flow is the authorization journey that records and enforces what a user or agent is allowed to access. In multi-tenant MCP, different tenants may require different consent steps, scopes, or assurance levels, so consent becomes part of identity design rather than a UI detail.
• Read-only By Default: Read-only by default means a system allows inspection and analysis before it permits any state-changing action. For agentic identity workflows, this is a core containment pattern because it prevents an AI assistant from silently altering users, keys, or authentication settings during discovery.

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 building or maturing an IAM programme, it is worth exploring.