Topic starter
19/08/2026 3:29 pm
TL;DR: MCP changes the governance boundary because assistant sessions can move from reading identity data to invoking write-capable actions, according to Descope. Identity teams now have to scope, log, and track each tool path if they want tenant-level accountability.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “The Descope MCP Server Is Available On Claude and ChatGPT”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Glossary terms: MCP, Tool Catalogue, Consent flow, Read-only By Default
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
19/08/2026 4:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude and ChatGPT access to MCP identity tools changes governance