Because local compliance does not prevent system-wide drift. Teams can each make reasonable choices while still creating inconsistent server inventories, mismatched permissions, and fragmented logs. When that happens, the organisation loses a reliable baseline for audit, incident response, and exception management.
Why This Matters for Security Teams
MCP rollouts look orderly when each team follows its own approval path, but governance breaks down when the organisation needs one defensible view of what exists, who can use it, and what data can flow through it. The risk is not just misconfiguration; it is uncontrolled variation across servers, tools, scopes, and logs. That creates a false sense of compliance while weakening auditability and incident response.
This is especially visible in agentic environments, where the same MCP server may be discovered by multiple agents, each with different tool calls and trust assumptions. Current guidance suggests treating MCP as part of the broader NHI and agent governance surface, not as an isolated integration layer. NHIMG research on Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both point to the same operational reality: inventory, identity, and monitoring must be governed consistently or the control plane fragments.
NHIMG’s AI Agents: The New Attack Surface report found that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a blind spot for compliance and breach investigation. In practice, many security teams discover this only after an exception has already become a pattern.
How It Works in Practice
MCP creates governance gaps because it standardises communication between agents and tools, but not the security outcomes around that communication. Teams may each approve their own servers, define their own scopes, and store logs in different systems. Individually those choices can be reasonable. Collectively they produce inconsistent identity boundaries, uneven authorization, and gaps in evidence retention.
The practical answer is to govern MCP as a shared control surface with common minimums:
- Maintain a central inventory of MCP servers, tool endpoints, and owners.
- Bind each server to a workload identity so the platform can verify what is calling it.
- Apply least privilege at the tool and scope level, not just at the team boundary.
- Normalize logs so session data, tool invocation, and approval events can be correlated.
- Review exceptions in one place so local decisions do not create hidden enterprise risk.
That approach aligns with the direction of the OWASP Agentic AI Top 10, which treats tool misuse, overbroad permissions, and weak trust boundaries as first-class risks. It also fits NHIMG’s Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs, which emphasizes that non-human identities must be governed across discovery, issuance, rotation, monitoring, and retirement, not just at onboarding.
Where teams get value from MCP, they often also create a second problem: every business unit can move at its own speed, but the organisation still needs one security baseline. These controls tend to break down when MCP servers are deployed locally by separate product teams because no shared inventory, policy engine, or log schema exists to reconcile them.
Common Variations and Edge Cases
Tighter MCP governance often increases integration overhead, requiring organisations to balance developer speed against evidence quality and cross-team consistency. There is no universal standard for this yet, so current guidance suggests prioritising control points that survive decentralised delivery rather than trying to centralise every implementation detail.
One common edge case is a pilot environment that later becomes production without a formal transition. Another is a team that uses one policy for access approval but a different standard for logging, which leaves the organisation unable to prove who accessed what. A third is shared infrastructure where multiple agents, services, and humans all touch the same MCP resources, making ownership unclear.
NHIMG’s AI Agents: The New Attack Surface report is useful here because it shows how quickly agent behaviour can outrun local assumptions. The better pattern is to treat each MCP rollout as an enterprise governance event, with a common control checklist, a single exception register, and review against the OWASP Top 10 for Agentic Applications 2026 and NIST Cybersecurity Framework 2.0.
Best practice is evolving, but the core lesson is stable: local policy compliance does not guarantee system-wide governance when the control surface is distributed. In mixed maturity environments, that gap usually appears first in investigations, not in design reviews.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | MCP can expand tool and trust-boundary abuse in agentic systems. |
| OWASP Non-Human Identity Top 10 | NHI-01 | MCP servers rely on non-human identities and shared governance gaps. |
| CSA MAESTRO | AIV-05 | Shared agent tooling needs lifecycle governance and runtime oversight. |
| NIST AI RMF | AI RMF addresses governance, transparency, and accountability gaps. | |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is the baseline missing when MCP deployments drift. |
Map MCP tools to agentic risk controls and restrict every tool call to explicit, reviewable purpose.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
