Opal’s MCP server redesign reframes identity governance for agents

At a glance

What this is: Opal Security says its MCP server redesign keeps access data within customer boundaries, scopes tool access by role, and lets approvers handle requests inside the agent conversation.

Why it matters: That matters because IAM teams now have to govern agent-mediated access requests, auditability, and approval workflows without assuming a human user interface as the control point.

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.

👉 Read Opal Security’s update on self-hosted, scoped MCP servers for access governance

Context

Model Context Protocol, or MCP, is becoming a control plane for AI agents that need to reach identity data, request workflows, and operational systems. The identity problem is not simply that agents can use tools, but that those tools inherit the trust and privilege model behind them, which is where access scope and approval boundaries start to matter.

Opal Security’s redesign is positioned around that governance gap: host the servers inside the customer boundary, separate duties by role, and reduce the friction between request, approval, and audit. For IAM, IGA, and PAM teams, the practical question is whether conversation-native access management strengthens control or hides weak boundaries inside a smoother interface.

Key questions

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. Every approval needs a durable record, a clear approver identity, and evidence that the requested action stayed within the role’s scope. If the workflow cannot survive audit review after the session ends, it is not a governable access process.

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. That matters because broad tool exposure turns a single agent workflow into an implicit super-user path. Splitting request, provisioning, and audit actions makes least privilege operational instead of aspirational.

Q: What breaks when MCP tools are exposed through one shared server?

A: Shared exposure collapses role separation. A requester, approver, and auditor may all inherit more capability than they need, which makes it harder to prove who did what and why. The result is weaker accountability, more difficult recertification, and a larger blast radius if the server is misused.

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.

How it works in practice

MCP server hosting and the trust boundary for identity data

MCP servers sit between the agent and the systems it needs to query or operate. When that server is hosted by a third party, identity data, request context, and access metadata leave the customer boundary unless strong compartmentalisation exists. Self-hosting shifts that trust boundary inward, but it does not remove the need for policy enforcement, logging, and tool-level constraint. The real architecture question is where the server terminates trust and where it forwards requests, because that determines who controls the sensitive path between intent and action.

Practical implication: map every MCP deployment to its trust boundary and decide whether the server or the client owns the policy decision.

Scoped tool permissions and role-separated MCP servers

A single MCP server that exposes all tools to every caller creates unnecessary privilege overlap. Splitting end-user, provisioning, and auditing functions into distinct servers narrows the available action set and reduces accidental overreach. This mirrors least-privilege design in IAM, but applied to tool invocation rather than just account entitlements. The technical value is not the number of servers, but the reduction in reachable functions for each role and the clearer separation of request, modify, and inspect paths.

Practical implication: treat tool partitioning as an entitlement design problem and review each server as a separate privilege domain.

Conversation-native approvals and audit trails in agent workflows

Approval inside the conversation keeps the workflow continuous, but it also changes how controls are observed. An approver can see context and grant access without switching systems, yet the underlying governance still depends on whether the approval event is durable, attributable, and fully logged. This is where many agent-facing workflows fail: the control exists in the conversation but not in a defensible record. For identity teams, the test is whether the same approval can be reviewed later with the same evidence a dashboard would have produced.

Practical implication: verify that conversation-based approvals write immutable evidence into your existing audit and recertification processes.

NHI Mgmt Group analysis

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.

Role-scoped MCP servers create a more intelligible privilege model than monolithic tool exposure. Separating end-user, provisioning, and auditing functions reduces tool sprawl and makes access decisions easier to reason about. The named concept here is conversation-bound privilege partitioning: the idea that each agent-facing function should expose only the tools needed for that workflow. That model is easier to govern than broad agent access, and it gives teams a clearer path to review and certify what each role can do.

Access data staying inside the customer boundary is a governance requirement, not a comfort feature. Identity data used in agent workflows carries the same sensitivity as any other privileged request context. If that data exits the environment, the organisation inherits a new trust chain across hosting, logging, and retention. The practical conclusion is that data residency, auditability, and tool access scope need to be evaluated together, not as separate product checkboxes.

Approval in the flow only helps if the approval remains externally defensible. A faster request-and-approve experience can improve operator discipline, but it can also obscure whether a request was reviewed with sufficient context and whether the evidence survives later scrutiny. That is where governance programmes need to distinguish convenience from control. Practitioners should judge the workflow by its replayable evidence, not by how little friction it introduces.

The market signal is clear: MCP governance is converging with NHI and access orchestration. Once agents start using MCP to touch access and audit functions, identity teams cannot leave it to engineering teams alone. The governance model has to cover the server, the tools, the approval trail, and the access data in one policy domain. That makes MCP a control-plane issue for identity leaders, not a niche protocol question.

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.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, which means the control problem starts before runtime policy even matters.
• MCP governance belongs in the same planning cycle as secret management and access review, as shown in our Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

With only 18% of MCP server deployments implementing access scoping, the governance gap is not theoretical. Identity teams should expect MCP to become a routine attachment point for AI agents, which means access reviews, audit evidence, and tool entitlements need to be designed for conversation-native workflows, not retrofitted after adoption.

Conversation-bound privilege partitioning: the practical pattern is to separate request, approve, and audit functions so each agent-facing workflow has a narrower control surface. That makes it easier to map MCP activity back into existing IAM, PAM, and recertification processes, especially when the same agent is bridging multiple systems.

Teams should also watch for the split between usability and assurance. If approvals become easier but evidence becomes harder to reconstruct, the programme has improved convenience while weakening governance. The right benchmark is whether the same access decision can be explained later through the audit trail, not whether the interaction felt seamless.

For practitioners

• 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. If the answer is yes, document which data elements cross the boundary and under what policy conditions.
• Split agent tools into separate privilege domains Do not expose provisioning, auditing, and end-user functions through one broad tool set. Use separate MCP servers or equivalent boundaries so each workflow has a narrower reachable action set and a distinct review path.
• Require durable approval evidence Confirm that every approval made inside a conversation creates a record that can support audit review, recertification, and incident reconstruction. The approval must be traceable after the chat ends, not only visible during the session.
• Test agent workflows against least privilege Validate that an agent cannot invoke a tool the human role would not already be allowed to use, and that tool availability matches the role definition rather than the convenience of the interface.

Key takeaways

• Opal’s MCP redesign shows that agent access is becoming an identity governance problem, not just a protocol integration task.
• Scoped tool exposure and durable approvals matter more than conversational convenience because they determine whether access remains reviewable and auditable.
• Identity teams should evaluate MCP deployments as privilege domains, because control quality depends on where the trust boundary is drawn.

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.
• Conversation-bound privilege partitioning: A control pattern where agent-facing functions are split into narrower roles such as request, provision, and audit. The goal is to stop one conversational interface from becoming a single high-privilege channel and to make review, certification, and accountability easier to prove.
• Approval evidence: The durable record that shows who approved access, when the decision was made, and what request was approved. Strong approval evidence supports audit, recertification, and exception review. Weak evidence forces teams to rely on tickets, email, or memory.

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

👉 Opal Security’s full post covers the server setup, command examples, and tool mapping details.

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.