MCP for identity governance: what AI-ready governance changes

At a glance

What this is: Omada’s MCP Developer Reference frames MCP as a governed integration path for AI systems to access identity data through auditable channels.

Why it matters: It matters because IAM, IGA, NHI, and autonomous governance teams need a model for connecting intelligent systems to identity data without collapsing policy, auditability, or accountability.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Omada Identity's blog on the MCP initiative for AI-ready governance

Context

MCP, or Model Context Protocol, is becoming the connective tissue between AI systems and enterprise identity platforms. The issue is not connectivity alone, but whether those connections preserve governance intent when AI agents begin querying, combining, and acting on identity data. For teams already struggling with fragmented controls, the question is whether the identity layer can remain the trust anchor as AI participation expands.

Omada’s framing matters because it places MCP inside an IGA control model rather than outside it. That is the right analytical starting point for AI-ready governance: the integration layer can move data, but policy still has to decide what is visible, what is actionable, and what is auditable. For teams looking for a broader NHI baseline, the Ultimate Guide to NHIs remains the most useful reference point for governance, lifecycle, and oversight patterns.

Key questions

Q: How should security teams govern AI systems that access identity data through MCP?

A: Treat MCP as a governed transport path, not a trust grant. Security teams should require policy enforcement, request logging, and output traceability for every AI interaction with identity data. The key decision is whether the AI is merely querying governed information or is being allowed to trigger identity actions that need separate approval and revocation controls.

Q: Why does MCP create new governance challenges for IAM and IGA teams?

A: MCP reduces integration friction, but it also increases the number of systems that can consume identity context. That matters because governance is no longer about one application talking to one directory. Teams must now control what identity data AI systems can see, how long they can use it, and whether any action they take is separately authorised.

Q: What breaks when AI tools can query identity data without strong auditability?

A: Accountability breaks first, followed by policy assurance. If teams cannot reconstruct which identity attributes were exposed, who requested them, and what action followed, then governance becomes difficult to prove and harder to enforce. In practice, lack of auditability turns AI-assisted identity work into an opaque control path.

Q: What is the difference between AI for IGA and IGA for AI?

A: AI for IGA uses machine intelligence to improve governance tasks such as analysis, routing, and recommendation. IGA for AI governs the AI system itself, setting boundaries on what it may request, infer, and execute. Teams need both models, but they should not assume that assistance controls are enough to govern delegated or autonomous behaviour.

Technical breakdown

How MCP creates a governed access path for AI systems

MCP standardizes how an AI system or enterprise application requests data and tools from external services. In identity governance terms, that means it can become a policy-aware transport layer rather than an uncontrolled integration shortcut. The critical distinction is that MCP does not replace governance logic. It only defines how the system asks for context and how responses are delivered. If the underlying IGA controls are weak, MCP simply makes those weaknesses easier to operationalize across more AI-enabled workflows.

Practical implication: Treat MCP as an integration protocol that must sit behind existing authorization, logging, and policy enforcement controls.

Why auditable channels matter when AI touches identity data

Auditable channels preserve traceability across requests, responses, and downstream actions. In practice, this is what separates governed AI usage from opaque automation. If an AI system can read identity records, entitlements, or certification data without a durable audit trail, security teams lose the ability to explain decisions, reconstruct access paths, or prove policy enforcement. For IGA, the technical requirement is not just access control. It is linkage between query, approval, data exposure, and any subsequent action.

Practical implication: Require end-to-end audit correlation so every AI-driven identity interaction can be traced back to a policy decision.

AI for IGA versus IGA for AI

AI for IGA uses machine intelligence to improve identity governance tasks such as analysis, routing, and recommendation. IGA for AI is the harder problem because it governs the AI system itself, not just the humans and accounts around it. That means defining what the AI may request, what it may infer, and which actions remain off-limits even if the integration is technically possible. The transition matters because governance patterns that work for assistance do not automatically work for delegated action.

Practical implication: Separate AI-assisted governance from governance of AI behavior, and design controls for both layers independently.

Threat narrative

Attacker objective: The attacker objective is to use AI-enabled integration paths to obtain identity context or influence identity-related actions without preserving clear governance oversight.

1. Entry occurs when AI systems gain access to identity data through a standardized MCP interface rather than a bespoke, heavily reviewed integration.
2. Escalation happens if the integration layer exposes more identity context than the AI workflow actually needs, turning convenience into over-broad access.
3. Impact follows when opaque AI-driven queries or actions bypass the governance intent behind the identity platform and create weak accountability for access decisions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

MCP is becoming a governance boundary, not just an integration standard. The article correctly treats MCP as the layer that connects AI systems to enterprise identity data, but the real significance is that it now sits inside the identity trust model. Once AI agents can query governed identity data through a standard protocol, the security question shifts from connectivity to policy enforcement, traceability, and scope control. Practitioners should treat MCP as part of the control plane, not a neutral transport mechanism.

Auditable access is the minimum condition for letting AI touch identity data. Identity governance loses value when the query path is invisible, even if the output is technically correct. The article points to auditable channels, which is exactly the right control concept for AI-mediated governance because accountability depends on reconstructable request and response paths. For practitioners, the issue is not whether AI can help with governance tasks, but whether every interaction remains explainable under review.

AI for IGA and IGA for AI are different operating models. The first uses AI to improve governance work, while the second governs the behaviour of AI systems themselves. Those models should not be collapsed into one roadmap because the control objectives differ: assistance can be measured by efficiency, but delegated action requires constraints, authorisation boundaries, and revocation logic. Practitioners should separate these tracks early, or they will overestimate the control they actually have.

Identity data is becoming the trust substrate for human, machine, and agentic interactions. That is a broader shift than MCP alone, and it means identity teams will increasingly be asked to broker context across actors with different levels of autonomy. The governance challenge is to keep policy consistent while the consumers of identity data become more diverse. Practitioners should assume the identity platform will be asked to serve as a trust anchor across more than one actor type.

Governance for AI systems will fail if it borrows human-era assumptions unchanged. Access review processes were designed for access that persists long enough to be observed, certified, and revoked. That assumption weakens when AI systems participate in dynamic, context-rich workflows because the system can request, combine, and act on data faster than human governance cycles can validate it. The implication is that governance design must move from periodic review logic to runtime policy boundaries.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to the State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly integration layers can become exposure points.
• For a broader control baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle and oversight patterns that help constrain machine-access pathways.

What this signals

MCP will push identity teams toward policy-aware integration design. The practical change is that application connectivity can no longer be separated from access governance. If AI systems are going to consume identity context, teams need an explicit decision model for what can be queried, what can be inferred, and what action requires human approval. That is the shift from integration convenience to governed interoperability.

Policy-controlled pathway: this is the emerging pattern that separates safe AI enablement from accidental overexposure. If the protocol can reach identity data but cannot independently authorize broader action, the control plane remains intact. Teams should evaluate whether their current architecture can keep audit, authorisation, and revocation aligned when AI sits inside the workflow.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per the State of MCP Server Security 2025, the lesson for practitioners is straightforward: exposure often happens at the integration boundary before it appears in the governance layer.

For practitioners

• Define MCP as a governed integration layer Classify every MCP connection as a policy-controlled pathway and require the same approval, logging, and oversight standards used for other identity data integrations.
• Bind every AI query to an audit record Capture who or what initiated the request, which identity objects were exposed, and what downstream action followed so the record can survive review and investigation.
• Separate AI assistance from delegated authority Allow AI to assist with governance analysis, but keep approval, entitlement changes, and lifecycle actions behind explicit policy gates that cannot be bypassed by the protocol layer.
• Map MCP use cases to identity actor type Document whether each workflow involves human identities, NHI workloads, or autonomous systems so the governance model matches the actor actually consuming the data.

Key takeaways

• MCP becomes risky when teams treat it as plumbing instead of a governed access path for identity data.
• The core operational challenge is not AI connectivity, but keeping policy, auditability, and accountability intact when AI systems query identity context.
• Practitioners should separate AI-assisted governance from governance of AI behaviour before MCP-enabled workflows expand beyond review and into action.

Key terms

• Model Context Protocol: A standard that lets AI systems and applications request context, tools, and data from external services in a structured way. In identity governance, it matters because the protocol can become the path by which AI consumes sensitive identity data, so its value depends on the controls wrapped around it, not the transport alone.
• Auditable Channel: A communication path where requests, responses, and actions can be traced back to a specific actor and policy decision. For identity and AI governance, an auditable channel is what makes accountability possible when AI systems query identity records or trigger downstream actions that need to be explained later.
• AI for IGA: The use of machine intelligence to make identity governance work faster, smarter, or more adaptive. This usually means analysis, recommendation, routing, or automation support. It improves the governance process, but it does not by itself grant AI authority to make or execute identity decisions.
• 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.

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Omada Identity: Omada Advances AI-Ready Governance with the Model Context Protocol Initiative. Read the original.