Notifications
Clear all
Topic starter
25/06/2026 12:02 am
TL;DR: Omada’s MCP Developer Reference shows how AI systems can interact with governed identity data through auditable channels, positioning MCP as the integration layer while IGA remains the policy and oversight layer, according to Omada Identity. The governance question is no longer whether AI can connect to identity systems, but whether access, accountability, and policy enforcement stay intact when intelligent systems become part of the control plane.
NHIMG editorial — based on content published by Omada Identity: Omada Advances AI-Ready Governance with the Model Context Protocol Initiative
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
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.
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.
Q: What breaks when AI tools can query identity data without strong auditability?
A: Accountability breaks first, followed by policy assurance.
Practitioner guidance
- 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.
What's in the full article
Omada Identity's full blog covers the operational detail this post intentionally leaves for the source:
- Developer reference examples for connecting AI systems to governed identity data through MCP.
- Configuration templates and early-access materials for experimenting with policy-aware identity workflows.
- Implementation context for aligning Omada IGA controls with AI-assisted access patterns.
- The source article's own framing of the transition from AI for IGA to IGA for AI.
👉 Read Omada Identity's blog on the MCP initiative for AI-ready governance →
MCP and identity governance: are your controls ready for AI?
Explore further
25/06/2026 8:49 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP for identity governance: what AI-ready governance changes
