Notifications
Clear all
Topic starter
22/07/2026 4:36 pm
TL;DR: Opal’s rebuilt MCP servers keep access data inside customer boundaries, split end-user, provisioning, and auditing duties, and add approval handling inside the conversation flow, according to Opal Security. The governance question is no longer whether agents can act, but whether access decisions remain scoped, auditable, and reviewable at runtime.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should teams govern AI agent access when approvals happen inside a conversation?
A: Treat the conversation as a control surface, not the control itself.
Q: Why do scoped MCP servers matter for IAM and PAM teams?
A: Scoped servers reduce tool sprawl and make it easier to map each function to a distinct privilege domain.
Q: What breaks when MCP tools are exposed through one shared server?
A: Shared exposure collapses role separation.
Practitioner guidance
- Define the MCP trust boundary Map where identity data, request context, and approvals are stored, processed, and logged, then decide whether any third party sits inside that path.
- Split agent tools into separate privilege domains Do not expose provisioning, auditing, and end-user functions through one broad tool set.
- Require durable approval evidence Confirm that every approval made inside a conversation creates a record that can support audit review, recertification, and incident reconstruction.
What's in the full announcement
Opal Security's full product post covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for the end-user, provisioning, and auditing MCP servers across supported clients
- Exact command examples for Claude Code, Cursor, and Gemini CLI deployments
- Documentation on self-hosted setup, including how to swap in your own domain and API token flow
- The full tool list for each server and how Opal maps them to specific access workflows
👉 Read Opal Security’s update on self-hosted, scoped MCP servers for access governance →
Opal’s MCP servers: what changes for IAM teams and AI agents?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
22/07/2026 4:40 pm
Conversation-native access is becoming an identity control surface, not just a usability feature. When agents can request, approve, and query access in the same flow, the control point shifts from a traditional portal to the interaction layer itself. That means IAM, IGA, and PAM teams have to decide whether the conversation is merely a front end or the actual enforcement point. Practitioners should treat MCP workflows as identity infrastructure, not chat enhancements.
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.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, which means the control problem starts before runtime policy even matters.
A question worth separating out:
Q: Who should own MCP credential governance in an IAM programme?
A: Ownership should sit with the identity or security team that governs other non-human credentials, not with tooling admins alone. These tokens authorize API access and should be treated as part of the organisation’s NHI inventory, scope management, and offboarding process.
👉 Read our full editorial: Opal’s MCP server redesign reframes identity governance for agents
