Why do MCP deployments create governance risk when access is only controlled at the server level?

Because server-level controls answer only whether a caller can reach the server, not what actions they can perform inside it. That creates unnecessary privilege at the tool layer. Production governance needs the ability to separate read, write, delete, and export actions within the same server.

Why This Matters for Security Teams

Server-level access control on an MCP deployment is not enough because it answers the wrong question. It can confirm that a caller is allowed to reach the server, but not whether that caller should be able to read, write, delete, or export within a specific tool or context. That gap turns the mcp server into a broad privilege gateway, which is exactly where governance becomes fragile.

This risk is amplified in agentic environments because the caller is often not a person but an AI agent chaining tools, switching tasks, and acting at machine speed. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 treats overbroad tool access as a core failure mode, not an edge case. NIST also reinforces that access decisions should be tied to defined risk and control outcomes, not just network reach.

NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and credential exposure. In practice, many security teams only discover this after an agent has already used a tool in a way the server-level policy never explicitly prevented.

How It Works in Practice

Production governance for MCP needs to operate at the tool and action layer, not just at the server boundary. A secure pattern starts with workload identity for the agent, then applies runtime authorisation to each request based on intent, context, and the specific tool operation being attempted. That means the policy decision should distinguish between actions such as retrieve, update, execute, delete, and export, even when they are exposed by the same MCP server.

In practice, teams are moving toward short-lived credentials and just-in-time access grants rather than static server tokens. The reason is simple: if an autonomous agent is compromised, misaligned, or prompted into a bad chain of actions, long-lived credentials widen the blast radius. A better model is to issue ephemeral credentials per task, evaluate policy at request time, and revoke access when the task ends. That approach aligns with the direction of NIST Cybersecurity Framework 2.0 and the control discipline described in OWASP Non-Human Identity Top 10.

For MCP specifically, useful governance patterns include:

• Separate read-only, write, admin, and export capabilities instead of exposing a single all-purpose server token.
• Bind each request to workload identity and policy-as-code, so the decision is made from live context rather than a static allowlist.
• Log tool invocation, data scope, and downstream side effects for audit and incident response.
• Use short TTL secrets and automatic revocation after task completion or anomaly detection.

NHIMG’s Ultimate Guide to NHIs frames lifecycle control as essential because issuance, use, and retirement are inseparable in non-human identity governance. These controls tend to break down when MCP servers are used as shared orchestration layers across many agents and tool types because server-level permissions cannot express per-action business intent.

Common Variations and Edge Cases

Tighter action-level control often increases implementation overhead, requiring organisations to balance operational simplicity against the need for narrower privilege. That tradeoff is real, especially where multiple agents share the same MCP server or where a legacy tool only supports coarse permissions.

Current guidance suggests treating that limitation as a governance gap, not as a reason to accept broad access. Where fine-grained enforcement is not available natively, teams can place an authorisation proxy in front of the server, split high-risk functions into separate services, or restrict the server to read-only use until granular controls exist. The best practice is evolving, but the principle is stable: if the policy cannot tell the difference between safe and destructive actions, the deployment is over-permissioned by design.

Another common edge case is human-in-the-loop approval. Approval does not fix weak MCP design if the underlying server still exposes more privilege than the approved task requires. The safer pattern is to approve the specific action, not merely the server session. That matters most in environments handling customer data, code execution, secrets retrieval, or bulk export.

For teams formalising this work, Ultimate Guide to NHIs and Top 10 NHI Issues are useful references for auditability and lifecycle control. In the current state of the market, MCP governance fails fastest in high-trust internal deployments where server-level access is mistaken for sufficient control.

Related resources from NHI Mgmt Group

• When does MCP create more governance risk than it removes?
• When does JIT access create more risk than it reduces?
• Why do API tokens create more governance risk in MCP deployments?
• What frameworks help with MCP server governance and least privilege?