MCP for identity governance: what AI-ready governance changes

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Omada Identity's blog post: MCP can connect AI systems to identity data through auditable channels while IGA remains the policy and oversight layer.

Why it matters: It matters because IAM and IGA teams now have to govern machine and AI access paths without confusing integration convenience with actual control.

Context

MCP gives AI systems a standard way to talk to tools and data sources, but that does not make those interactions governed by default. The identity governance problem is not connectivity itself. It is whether policy, approval, and auditability survive once AI systems start querying and acting on identity data.

For IAM and IGA teams, the key shift is that integration and control are no longer the same layer. AI for IGA can improve workflow efficiency, but IGA for AI introduces a different question: how do you govern systems that consume identity data and influence access decisions without weakening accountability?

Omada Identity frames its MCP reference as an early step toward that model. The operational reality for practitioners is that any protocol layer supporting AI access to identity systems has to be treated as part of the governance boundary, not as a neutral pipe.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do standard protocols create governance risk when AI systems use them?

A: Standard protocols reduce integration friction, which makes it easier for AI systems to reach identity data quickly and at scale. The risk is that standardisation can hide scope creep: once the connection feels routine, teams may under-control what the AI can request, infer, or trigger. Governance has to limit authority, not just permit access.

Q: What breaks when AI-assisted IGA is treated as the same thing as IGA for AI?

A: The programme loses a critical distinction between using AI to improve governance work and governing the AI system itself. That confusion can leave strong automation in place while the organisation still lacks controls over what the AI may see, decide, or change. Assistance without supervision creates the appearance of maturity without accountability.

Q: What should teams review before connecting AI agents to identity systems?

A: Teams should review the data scope, request authority, audit trail, and accountability model before enabling AI agents to interact with identity systems. The key question is whether the agent can only retrieve information or whether it can also influence decisions and workflows. If that line is unclear, the control model is incomplete.

Technical breakdown

Why MCP changes the identity governance boundary

MCP is a protocol layer that standardises how AI systems and applications request data or actions from connected services. In identity governance terms, that matters because the protocol can make access look routine and safe while still bypassing the assumptions built into traditional human-centric workflows. The control question is not whether the protocol can connect tools. It is whether the identity platform can still enforce policy, logging, and approval semantics when the requester is an AI system rather than a person. That distinction matters even more when the AI system is operating through a delegated integration path.

Practical implication: Treat MCP as part of the governance surface and verify that policy checks happen at request time, not only at integration setup.

AI for IGA versus IGA for AI

AI for IGA uses automation to improve governance tasks such as triage, enrichment, and workflow routing. IGA for AI is different because governance starts to supervise the behaviour of AI systems themselves, including what data they can access and how their actions are attributed. This shift moves the programme from supporting human decision-makers to regulating machine participation in governance processes. If the organisation does not separate these two models, it can end up with efficient automation but weak accountability. The governance model has to distinguish assisting the workflow from governing the actor.

Practical implication: Map which identity processes are being accelerated by AI and which are now being influenced by AI as a governed actor.

Auditable channels do not equal governed decisions

An auditable channel records what happened, but it does not by itself prove that the underlying decision was properly authorised. In AI-enabled identity workflows, this difference is critical because a system can leave logs while still over-querying data, combining context in unsafe ways, or acting beyond intended scope. Governance therefore has to sit above the transport layer and define what the system may ask for, what it may infer, and what actions it may trigger. The risk is that organisations confuse visibility with control and audit with approval.

Practical implication: Separate logging requirements from authorisation requirements so AI access remains policy-bound, not merely observable.

Threat narrative

Attacker objective: The objective is to turn a governed integration path into a broader source of identity data and influence without equivalent control over scope and accountability.

1. Entry occurs when an AI system connects to identity data through a standardised protocol interface that appears trusted because it is auditable and policy-aware.
2. Escalation happens if the AI requester can query more identity context than its task requires, combining governed data into broader access decisions or workflow actions.
3. Impact follows when the access path becomes a de facto control plane for identity operations, expanding the blast radius of a mis-scoped AI integration.

Breaches seen in the wild

• 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 becoming the governance boundary, not just the integration layer: once AI systems use standard protocols to reach identity data, the control question shifts from connection design to authority design. Identity teams have to decide whether the protocol is simply moving data or also moving decision power. The practitioner implication is that MCP belongs inside the governance model, not outside it.

AI for IGA and IGA for AI are not the same programme: AI for IGA improves how identity work gets done, while IGA for AI governs what intelligent systems may see and do. Collapsing those two layers creates a false sense of maturity because the organisation may automate governance tasks without governing the AI participant. Practitioners should separate assistance from supervision in their operating model.

Auditable access is not the same as compliant access: logs show activity, but governance requires pre-authorised scope, policy enforcement, and clear accountability for every request. That distinction matters when AI agents become part of the identity control path because observability alone does not stop overreach. The implication is that audit evidence cannot be the only control story.

Identity governance assumptions built for human-paced workflows start to weaken when intelligent systems participate: policy review, attribution, and exception handling all assume a stable requester and a human-readable decision trail. When AI systems broker or shape access decisions, those assumptions become less reliable even if the protocol is standards-based. Practitioners need to re-test where their governance model depends on human interpretation.

Standardisation will accelerate adoption, but it will also expose weak governance models faster: a common protocol reduces friction, which means organisations will connect AI to identity data sooner and at greater scale. That will surface any programme that still treats AI access as an edge-case integration. The field is moving toward governed interoperability, and teams that lack clear boundaries will feel the pressure first.

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: Access Reviews and Certification Guide

What this signals

Governed interoperability is now the real design problem: once AI systems can reach identity platforms through standard protocols, teams have to distinguish between a controlled connection and a controlled decision. That means policy enforcement, attribution, and auditability need to be evaluated at the AI request layer, not only in the identity platform itself.

Protocol standardisation will expose weak operating models quickly: the easier it becomes to connect AI to identity data, the less tolerant the environment becomes of vague authority boundaries. Teams that cannot state what AI may query, what it may infer, and what it may change will find that integration scale turns into governance debt very quickly.

For practitioners

• Define MCP as a governed access path Classify every MCP connection to identity data as part of the control boundary, with explicit policy, logging, and approval ownership.
• Separate AI assistance from AI supervision Document which workflows use AI to assist IGA and which workflows require governance over AI behaviour itself, then assign different controls to each.
• Validate request-time authorisation Check that access decisions are evaluated at the moment of each AI request, not just when the integration is onboarded or the connector is approved.
• Limit identity context exposed to AI Restrict the attributes, entitlements, and identity records available to AI systems so the protocol cannot become a broad discovery channel.
• Test accountability for delegated actions Trace who is responsible when an AI system queries identity data, recommends an access change, or triggers a workflow action on behalf of a user.

Key takeaways

• MCP can make AI access to identity data more consistent, but consistency is not the same as governance.
• The central risk is not the connector itself, but the way standardised AI access can blur policy boundaries and accountability.
• IAM and IGA teams should classify MCP as part of the control boundary and validate request-time authorisation before expanding use.

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.
• AI for IGA: The use of AI to make identity governance work more efficient, such as improving routing, enrichment, or workflow support. The key distinction is that AI assists the governance process, but the organisation still governs human and machine access through existing policy and control structures.
• IGA for AI: A governance model that focuses on the behaviour of AI systems themselves, not just the humans or accounts around them. It defines what the AI may request, infer, or do, and it becomes necessary when AI moves from assisting governance to participating in identity-related decisions or actions.
• Governed access path: A controlled route by which a system can reach identity data while remaining subject to policy, logging, and accountability. The term matters because a connection can be technical and auditable without yet being sufficiently governed for enterprise use.

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.