MCP makes identity governance conversational, but not autonomous

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Nexis's blog post: MCP is being used to expose identity governance data through natural-language questions, but the governance model still depends on controlled authorization and trusted identity data.

Why it matters: IAM and IGA teams need to distinguish conversational access to identity data from autonomous decision-making, because the governance risk sits in data quality, authorization scope and accountability, not the chat interface itself.

👉 Read Nexis's analysis of MCP, AI assistants and identity governance

Context

MCP adds a new access pattern to identity governance: a conversational interface that can query identity data, policies and governance context on demand. The control question is no longer only who can see a report, but what an AI assistant can retrieve, infer and present when it is allowed to query the platform.

That matters because identity programmes already struggle with fragmented data, inconsistent ownership and stale access records. If the underlying dataset is incomplete or contradictory, natural-language access can make the inconsistency easier to consume rather than easier to fix. identity visibility and threat detection becomes the baseline for deciding whether conversational access is trustworthy.

Key questions

Q: How should teams govern MCP access when multiple tenants share the same user identity?

A: Treat tenant selection as an authorization decision, not a convenience step. The flow should determine which organisation is active before token issuance, then place that choice into a trustworthy tenant claim so the MCP server can apply the correct tools, SSO path, and role boundaries.

Q: Why does conversational access to identity data create governance risk?

A: Conversational access to identity data creates governance risk because natural-language queries can expose fragmented or inaccurate identity data, bypass approved reports, and return sensitive entitlements or ownership details to the wrong user. Controls such as role-scoped queries, logged prompts and responses, data minimisation, and approval gates reduce overexposure and misinterpretation.

Q: How do AI assistants affect access review and certification workflows?

A: AI assistants can speed up access review and certification workflows by pre-populating entitlements, grouping similar access, and highlighting anomalies for reviewers. They also raise governance risk if recommendations are not explainable, if reviewers rubber-stamp suggestions, or if the assistant uses stale joiner-mover-leaver data to certify access.

Q: What is the difference between conversational access and autonomous access?

A: Conversational access lets a person ask for identity or access information in natural language and receive a response, usually with human approval and no direct execution. Autonomous access lets an agent decide and act at runtime, such as requesting tokens, changing entitlements, or invoking tools, within delegated scope and oversight controls.

Technical breakdown

How MCP exposes identity data to AI assistants

Model Context Protocol is a standard way for an assistant to call tools and retrieve data from external systems during a conversation. In an identity platform context, that means the assistant is not guessing about roles, permissions or governance status. It is querying live identity data, then turning that result into a natural-language response. The technical risk is not the protocol itself, but the fact that retrieval, authorization and response generation become part of the same runtime path. That makes the trust boundary much tighter than a normal dashboard or export flow. See the Identity Visibility and Intelligence Platforms (IVIP) Guide.

Practical implication: Scope every MCP-connected identity data source as a governed API surface, not as a harmless user interface.

Why authorization must stay separate from language generation

When an LLM sits behind a governed tool layer, the model should not become the policy decision point. Authorization needs to happen before the assistant can retrieve sensitive identity data, and the response should be constrained to what the user or workflow is already permitted to know. Otherwise, the assistant can become an amplification layer for overbroad visibility, leaking entitlement detail, ownership data or governance findings across roles that should not see them. That separation is especially important when the same interface serves analysts, auditors and operational users. See the IAM and IGA Basics.

Practical implication: Keep policy enforcement outside the model and verify that every retrieval path is explicitly authorized.

How AI assistants change ownership and SoD analysis

An assistant that can surface access, account and role relationships makes identity analytics more interactive, but it does not solve accountability. Ownership gaps and segregation of duties conflicts still exist in the data, and the assistant simply makes them easier to discover when the data is already there. The useful architectural shift is to treat the assistant as a query and explanation layer over governed identity records, not as a system that resolves governance disputes on its own. That distinction matters when humans and AI agents appear in the same entitlement graph. See the Access Reviews and Certification Guide.

Practical implication: Use conversational access to accelerate review workflows, but keep ownership decisions and SoD remediation in the governance process.

Threat narrative

Attacker objective: The attacker or misconfigured assistant reaches governed identity data that should remain limited to approved users and workflows.

1. Entry occurs when an AI assistant is granted MCP access to identity governance data, including roles, permissions and account records.
2. Escalation appears when the assistant can combine multiple identity datasets and surface governance context that a user may not have pulled together manually.
3. Impact follows if overbroad retrieval or weak authorization lets the assistant expose sensitive access details, ownership gaps or SoD conflicts to the wrong audience.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

NHI Mgmt Group analysis

MCP is an interface pattern, not an identity control. The protocol changes how identity data is consumed, but it does not change who owns the data or who is accountable for it. That means the governance model still lives in authorization, inventory and data quality, not in the assistant layer. Practitioners should treat MCP as a new query surface that inherits existing governance strengths or weaknesses, not as a replacement for them.

Conversational access exposes the condition of the identity dataset. If role data, account ownership or permissions are inconsistent, natural-language access makes the inconsistency easier to surface, not easier to resolve. The value of the interface depends on the quality of the underlying identity records. That pushes identity programmes toward cleaner lineage, stronger reconciliation and clearer ownership before they expose the data to an assistant.

Runtime governance must follow the query path. The important question is not whether an assistant can answer an access question, but whether it can answer only the questions the requester is entitled to ask. Access reviews and certification remain relevant, but the governance control point shifts closer to issuance and retrieval time. Practitioners need policy-backed access to the answer layer, not just to the source system.

Agent access and human access cannot be governed as separate universes. The same identity graph increasingly contains people, service identities and AI agents, which means ownership and SoD analysis has to span all three. Once an assistant can query the graph directly, the governance model has to explain who may see combined access paths and who is responsible when the assistant reveals a conflict. The practical conclusion is that identity analytics now sits at the boundary of human IAM, NHI governance and agent oversight.

Language is becoming a delivery channel for control evidence. That creates value for analysts and auditors, but it also raises the stakes for false confidence if the data layer is weak. The named concept here is the identity query surface: a conversational path that can compress reporting, review and triage into a single interaction. Practitioners should assume that whatever is exposed through that surface becomes part of the operational control plane.

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.
• Read next: Identity Visibility, Posture and Threat Detection Guide

What this signals

The next governance question is not whether AI can talk to identity systems, but whether the query path itself has enough control to prevent disclosure across roles. Conversational interfaces compress access, evidence and explanation into one step, so programme owners need tighter retrieval boundaries and clearer logging than they used for static reports.

Identity query surface: once an assistant can answer access questions in plain language, the answer path becomes part of the control plane. That raises the value of data lineage, request logging and entitlement reconciliation, because a fast answer built on weak records can create operational confidence where governance should still be cautious.

MCP-related exposure risk is not abstract: 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. As more assistants depend on configuration and tool access, hidden secrets and loose retrieval paths become a practical governance problem.

For practitioners

• Define MCP retrieval boundaries Classify which identity records, entitlements and governance documents an assistant may query, then restrict each path to the minimum necessary dataset. See the IAM and IGA Basics.
• Separate authorization from response generation Enforce policy decisions before the assistant receives data, and do not let the model infer permission from context or conversational history.
• Validate identity data quality before exposing chat access Reconcile ownership, role membership and account status so the assistant does not become a faster way to distribute bad identity data.
• Extend review workflows to AI-assisted queries Track which access questions were asked, which identity records were returned and which governance decisions depended on the result.

Key takeaways

• MCP turns identity governance data into a conversational surface, which changes how quickly access evidence can be retrieved and shared.
• The main risk is not autonomy by itself but weak authorization, poor identity data quality and overbroad disclosure through the query path.
• Practitioners need to govern the assistant as a retrieval layer, with the same discipline they apply to access reviews, ownership and entitlement evidence.

Related NHI Mgmt Group resources: Identity Visibility, Posture and Threat Detection Guide · Access Reviews and Certification Guide · IAM and IGA Basics · NHI Lifecycle Management Guide

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Nexis's full blog post covers the operational detail this post intentionally leaves for the source:

• A practical walkthrough of MCP-connected identity queries inside the NEXIS platform
• A live implementation example showing how natural-language questions map to identity and authorization data
• The vendor's explanation of how governance remains controlled while AI assistants interact with the platform
• Context from the FI-TS implementation that shows how the approach is used in practice

👉 The full Nexis post shows how MCP is used in practice with identity and authorization data.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.