Opal’s MCP server redesign reframes identity governance for agents

At a glance

What this is: Opal Security's MCP server redesign separates end-user, provisioning, and auditing functions while keeping access data within customer boundaries and approval handling inside the chat flow.

Why it matters: This matters because IAM teams need governance patterns that preserve policy, auditability, and approval context when AI agents operate through MCP-connected tools.

👉 Read Opal Security's analysis of its redesigned MCP servers for governed agent access

Context

Model Context Protocol servers sit between an AI client and the systems it can query or change. In this article, the governance gap is not whether MCP works, but where identity, approval, and audit controls live when agent requests move through an MCP layer.

Opal Security frames the redesign around self-hosting, role scoping, and approval handling in conversation. That makes the article relevant to NHI governance because MCP-connected agents behave like governed non-human actors only when access boundaries, request scopes, and evidence trails remain intact at runtime.

The starting point is typical for teams experimenting with agent access. The governance question is whether the protocol wrapper preserves IAM controls or quietly becomes a new control plane with weaker visibility.

Key questions

Q: How should security teams design MCP server access for AI agents?

A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints. Group related backend calls into workflows, expose known data as resources, and reserve tools for actions that truly change state. That keeps the agent oriented, reduces context churn, and makes the access surface easier to review and govern.

Q: What happens when MCP approvals happen outside the workflow?

A: Approvals outside the workflow tend to lose context, create delays, and weaken the evidence trail for later review. Keeping the decision inside the operational flow is useful only if the system still captures who approved what, against which request, and under which policy.

Q: When does an MCP server become an overprivileged access path?

A: An MCP server becomes an overprivileged access path when it exposes more tools or administrative functions than the underlying role should have. The risk is not the protocol itself, but a server design that collapses request, change, and review into one broad authority surface.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

How it works in practice

Why MCP server hosting changes the trust boundary

MCP servers mediate how an agent reaches tools and data sources, so hosting location matters. If a third party hosts the server, access requests, context, and responses pass through an external operational boundary. Self-hosting changes that boundary again by keeping the traffic inside the customer environment. That does not eliminate the need for policy, but it changes who controls the runtime path, where logs reside, and which environment is responsible for evidence retention. In identity terms, the server becomes part of the authorization surface, not just a transport layer.

Practical implication: treat MCP hosting choice as an access-control decision, not only an infrastructure preference.

Why role-scoped MCP servers reduce access sprawl

A single MCP server that exposes all functions tends to collapse different governance jobs into one surface. Separating end-user, provisioning, and auditing functions creates clearer policy domains, because each role needs different permissions, different evidence, and different change authority. End-user requests should not inherit provisioning powers, and auditing should not require write access. That kind of separation aligns with least privilege and reduces the chance that an agent or operator can move from request creation to administration without a distinct control boundary. The architecture is useful only if the scopes are enforced server-side, not just documented.

Practical implication: map each MCP tool set to a discrete role and verify that the server enforces those boundaries.

Why in-conversation approval handling matters for agent governance

Approvals lose value when they force users to leave the workflow, because people either delay decisions or approve without context. By moving approval handling into the same conversation flow, the server keeps context and decision together. That improves usability, but it also raises a governance requirement: the approval event must still be attributable, policy-bound, and logged as a distinct decision. Otherwise the chat layer becomes a convenience wrapper that obscures who approved what, under which policy, and against which request state. The core technical question is whether conversation convenience preserves governance evidence.

Practical implication: ensure conversational approvals produce durable audit records tied to the exact request state.

NHI Mgmt Group analysis

MCP access governance is becoming an identity boundary, not a transport detail. When an agent asks for data or takes action through MCP, the server is now part of the authorization path. That shifts the control question from connectivity to governance, because the server decides which identities, tools, and approval states can interact. Practitioners should treat MCP servers as governed access surfaces, not neutral plumbing.

Role-scoped MCP design is the right instinct because it restores separations IAM teams already understand. End-user request, provisioning, and auditing are not the same job, and combining them into one tool surface invites privilege creep. The article's design choice reflects a broader lesson for NHI governance: agent access becomes manageable when the system expresses distinct duties instead of a single omnipotent interface. Practitioners should preserve those separations in policy, not just in UI.

Approval inside the conversation flow reduces friction, but it does not remove accountability. The risk in conversational governance is that speed can hide the exact decision state at the moment of approval. An approver may see context, but the system still has to prove what was approved, when, and under which policy. Practitioners should insist that conversational convenience never substitutes for durable evidence and traceable authorization events.

Scope containment is the core design principle that now separates useful agent workflows from dangerous ones. If an MCP server can only do what the user could already do, the governance model remains intelligible. If it can expand access, chain tools, or bypass review states, the control model breaks. The named concept here is runtime authorization containment: the ability to keep agent actions inside the same policy envelope that governed the request. Practitioners should judge MCP implementations by whether that containment survives the full session.

The market signal is that agent governance is converging with classic IAM control design. The strongest patterns are not exotic new controls but cleaner separations of duty, tighter scoping, and auditability that survives runtime use. That suggests the category is moving away from open-ended agent enablement and toward governed execution surfaces. Practitioners should expect agent tooling to be evaluated increasingly on lifecycle control, not just protocol support.

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: MCP Security Guide

What this signals

Runtime authorization containment: The practical test for MCP governance is whether an agent can remain inside the same policy envelope from request to action. If the server can widen privilege, merge duties, or hide the approval state, the protocol has become an access broker rather than a control surface.

The stronger pattern is to align MCP design with familiar IAM separations of duty, then keep approvals, evidence, and request context bound to the same transaction. That preserves auditability even when the conversation interface makes the workflow feel simple.

MCP-related secret exposure is already showing up at scale, including 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That is a warning that protocol growth can outpace governance unless teams control hosting, scoping, and credential handling together.

For practitioners

• Define MCP trust boundaries before deployment Decide whether the server will be vendor-hosted, self-hosted, or split across environments, then map where access data, request context, and logs will reside.
• Split MCP capabilities by governance role Keep end-user access requests, admin provisioning, and auditing on separate server surfaces so each role has a different permission set and evidence path.
• Require server-side approval logging Make every approval or denial produce a durable record that binds the actor, policy decision, and exact request state at the time of approval.
• Review MCP tool scope against least privilege Check whether each exposed tool matches the minimum authority needed for the role and remove any write action that is not essential to the workflow.

Key takeaways

• MCP servers now function as governance surfaces, because they sit directly in the path between an AI client and the systems it can affect.
• Role separation across end-user, provisioning, and auditing functions is the main control pattern that keeps agent access comprehensible.
• The decisive question is whether approvals, scope, and audit evidence remain intact at runtime, not whether the interface is convenient.

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.
• Runtime Authorization: Runtime authorization is the act of checking whether an identity should keep access while it is actively operating, not just when it is created. It matters for agents and automated workloads because their behaviour can change after approval. This makes continuous verification more important than one-time provisioning.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Approval Evidence Trail: An approval evidence trail is the durable record that shows who approved a request, what state it was in, and which policy justified the decision. Without that record, conversational approvals may be convenient but they are not governable.

What's in the full announcement

Opal Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Command examples for configuring the end-user, provisioning, and auditing MCP servers
• Setup notes for self-hosted deployments, including environment and token handling
• Client-specific installation steps for Claude Code, Cursor, Gemini CLI, and other MCP clients
• The full tool list and documentation references for each server role

👉 Opal Security's full post covers the server setup, tool list, and client configuration 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.