How should organisations govern MCP servers in identity programmes?

Organisations should inventory MCP servers like any other machine-facing access layer, then recertify exposed capabilities, remove unused tools, and keep state-changing actions tightly scoped. The goal is to reduce what an agent can even see as callable. That is a governance control, not just a software design preference.

Why This Matters for Security Teams

MCP servers are not just integration plumbing. In agentic environments, they become a machine-facing access layer that can expose tools, data, and state-changing actions to autonomous software. That makes them part of identity governance, because the question is not only who can authenticate, but what an agent is allowed to call, in what context, and with what blast radius. Current guidance suggests treating this as a Zero Trust and non-human identity problem, not a developer convenience issue, which aligns with NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs.

The risk is compounded by how often MCP deployments overexpose capability. Astrix Security’s The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions. That means most environments still rely on trust in the server implementation rather than explicit governance over callable actions. In practice, many security teams discover this only after an agent has already been granted broad tool access, rather than through intentional identity design.

How It Works in Practice

Governing MCP servers starts with inventory and classification. Each server should be registered as a machine-to-machine access surface, with owners, business purpose, exposed tools, data sensitivity, and whether any tool changes state. From there, security teams should remove unused tools, separate read-only from write-capable actions, and tie every remaining capability to a named business justification. That is where OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 become useful operational references: they both reinforce least privilege, change control, and continuous verification.

For agentic workloads, static RBAC is usually too blunt. Agents do not follow fixed human job patterns, and they may chain tools in ways no role designer anticipated. Best practice is evolving toward intent-based authorisation, where policy is evaluated at request time using the agent’s goal, the task context, the target resource, and the risk of the action. JIT credential provisioning also matters: credentials should be issued per task, short-lived, and revoked automatically on completion. That is a better fit than long-lived secrets in config files, especially when an autonomous agent can retry, pivot, or escalate unexpectedly.

• Inventory every MCP server and map it to an owner, system boundary, and data domain.
• Recertify exposed tools, not just accounts, because tool exposure is the real privilege surface.
• Use workload identity and short-lived secrets for machine authentication, not embedded tokens.
• Separate read, write, and admin-like tools so state changes require explicit approval or policy checks.
• Log tool invocation context to support audit, incident response, and behavioural review.

NHIMG’s Ultimate Guide to NHIs is useful for lifecycle and rotation practices, while the OWASP Agentic Applications Top 10 helps frame the tool-calling risk as an application security issue, not just an IAM one. These controls tend to break down when MCP servers are shared across teams with no single owner, because entitlements drift faster than recertification can keep up.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations have to balance reduced blast radius against developer friction and runtime latency. There is no universal standard for this yet, especially where agent workflows are experimental or rapidly changing, so current guidance is to start with the highest-risk tools and expand control coverage iteratively rather than forcing a big-bang redesign.

One common edge case is the internal platform MCP server that serves many teams. In that model, coarse RBAC can look efficient but still allow broad callable surface area. A better pattern is to keep the server itself stable while using per-agent policy, ephemeral credentials, and tool-level scoping to narrow what each workflow can do. Another edge case is the state-changing tool that is technically necessary, such as deployment, ticket closure, or financial action. Those tools often need step-up approval, dual control, or PAM-style gating even when read-only actions do not.

For governance programmes, the practical question is whether an MCP server expands the identity attack surface or narrows it. If the answer is unclear, recertification should default to removal. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both show the same pattern: excess capability, poor visibility, and weak lifecycle control turn machine identities into incident multipliers.

Related resources from NHI Mgmt Group

• How should organisations govern identity risk across human, NHI, and automated access?
• How should organisations govern eSignature platforms in IAM programmes?
• Should organisations use the same identity controls for patients and clinicians?
• Why do identity programmes matter so much in audit readiness?