TL;DR: Organizations need curation, admission, runtime enforcement, and audit controls to manage a fast-growing server estate whose use is already outrunning inventory, policy, and evidence, according to Jozu. The governance gap is not the protocol itself but the assumption that local tool access can be trusted without provenance, policy, and tamper-evident records.
At a glance
What this is: This is a governance framework for MCP servers that separates approval, runtime control, content boundaries, and audit into distinct control layers.
Why it matters: It matters because MCP servers now sit inside real production workflows, so IAM, security, and compliance teams need defensible control over what runs, what it can do, and what evidence survives.
Context
MCP governance is the control layer that turns a fast-growing set of model-connected servers into a managed asset class rather than an unmanaged collection of local integrations. The core problem is not just adoption, but the lack of inventory, policy, and evidence around which MCP servers are in use and what they are allowed to do.
In practice, the governance gap shows up when developers and production agents connect to MCP servers from public sources with no curated registry, no runtime rules, and no audit trail. That leaves security teams unable to answer basic questions about provenance, access scope, and recorded activity.
Key questions
Q: What breaks when MCP servers are trusted without registry and admission controls?
A: A trusted MCP server can become a hidden execution path for data theft, unsafe actions or code execution. The failure is not just an inventory gap. It is a broken trust boundary where an agent can load and use a server that has not been checked for provenance, signature integrity or malicious tool behaviour.
Q: Why do MCP servers need both admission controls and runtime enforcement?
A: Admission decides whether a server may load, but runtime enforcement decides what that server can do after it is running. A signed artifact can still be over-permitted, so teams need separate controls for load-time trust and per-call behaviour to keep the server within its intended boundary.
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.
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.
Technical breakdown
Why MCP server curation has to start with a curated registry
Curation is the first control boundary because an MCP server is not a normal dependency. It exposes tools that can read data, trigger actions, or move content between systems, so approved status has to be tied to provenance, scan results, and version pinning. A curated internal registry creates the source of truth for what is allowed to exist in the environment. Without that anchor, every downstream control inherits uncertainty and every audit claim becomes weaker than the operational reality. See the MCP Security Guide.
Practical implication: Build a signed internal registry before expanding server adoption, and treat the registry as the authoritative inventory for MCP governance.
How admission policy differs from runtime policy in MCP controls
Admission decides whether a server is allowed to load. Runtime policy decides what an approved server may do after it is already running. That distinction matters because signature checks, provenance, and attestations answer only the question of whether the artifact may enter the runtime boundary, while tool policy and guardrails govern each invocation, argument, and response. A secure MCP program needs both layers because a trusted artifact can still be dangerous if it is over-permitted or if its tool surface is abused after load. See the NHI Authentication Guide.
Practical implication: Separate load-time approval from per-call enforcement so a server cannot assume broad privileges simply because it passed admission.
Why auditability is a control requirement, not a reporting extra
Audit is the evidence layer that makes MCP governance defensible to both incident responders and compliance teams. A cryptographically chained log preserves admissions, denials, approvals, and tool calls so later review can verify what happened without relying on mutable records. That makes the audit function part of the control plane, not a retrospective reporting exercise. If the logs are incomplete, editable, or fragmented across environments, the organisation loses the ability to prove policy enforcement even when the policy itself looks sound. See the Incident Response Guide.
Practical implication: Instrument every decision path so the evidence chain is tamper-evident, centralized, and exportable for review.
Threat narrative
Attacker objective: The attacker seeks to turn a trusted MCP server path into a control surface for unauthorized data access, action execution, or undetected persistence.
- Entry occurs when teams load an MCP server from a public or uncurated source into a developer or production environment.
- Credential access or abuse follows when the server is allowed to handle sensitive tool arguments, responses, or downstream actions without policy checks.
- Escalation happens when the same runtime can reach high-value operations such as database writes, email, ticketing, or payment flows.
- Impact is the misuse of trusted server access to leak content, change systems, or leave no defensible trail for investigation.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP governance is becoming the practical control plane for model-connected tooling. The article describes a world where servers are no longer isolated integrations but shared execution paths for employees, agents, and assistants. That changes the security problem from endpoint-style hardening to governed access, scoped runtime behaviour, and auditable decisions. Practitioners should treat MCP governance as an identity and control discipline, not a narrow platform feature.
Curated registry control is the new trust anchor for MCP estates. If teams cannot name the approved source of MCP servers, every subsequent control is built on drift. This is the same failure pattern security teams already know from shadow IT and unmanaged service accounts, but now the execution surface can trigger real business actions. The implication is that inventory quality becomes a governance prerequisite, not a housekeeping task.
Runtime policy is where MCP governance stops being theoretical. The article’s strongest point is that approval alone is insufficient once a server is live. Tool policy, guardrails, and human approval gates define the actual blast radius, especially when content and actions cross the agent-server boundary. That makes runtime policy the control that determines whether an approved server remains bounded or becomes an open-ended execution path.
Audit chains are not evidence after the fact, they are the proof of control. Cryptographically chained records matter because MCP governance has to answer auditor and incident responder questions with verifiable history, not recollection. A tamper-evident log turns policy claims into defensible evidence. Practitioners who cannot export a complete decision trail should assume their governance model is not yet operational.
Shadow MCP is the named concept this market now needs. Unapproved MCP servers create the same governance ambiguity that shadow IT created, but with higher consequence because they can act on prompts, data, and downstream tools. The article shows that discovery, admission, and audit are all required to collapse that hidden estate into something manageable. Security teams should evaluate MCP exposure as a control inventory problem first and a tooling problem second.
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
Shadow MCP will become a recurring governance problem: as server adoption spreads into IDEs, production agents, and local runtimes, the hidden risk is not just exposure but unmanaged authority. Programmes built around inventory and policy review will see the fastest improvement because they can surface unapproved servers before they create runtime risk.
MCP governance also changes how teams think about evidence. A cryptographically chained audit trail is not just useful after an incident, it becomes the proof that approvals, denials, and human approvals were actually enforced across the environment.
The governance lesson is that trust must be earned twice, once at admission and again at runtime. If a server can load, invoke tools, and pass content across the boundary without separate checks, the organisation does not have governance, only convenience.
For practitioners
- Inventory all MCP server usage Sweep developer desktops, CI/CD pipelines, agent runtimes, and IDE configurations to identify every active MCP server before you define policy.
- Stand up a curated internal registry Mirror approved servers into a signed internal registry with scan results, provenance data, and version pinning so there is one source of truth.
- Separate admission from runtime enforcement Use artifact policy for load-time approval and a distinct runtime policy for tool calls, arguments, approvals, and content boundaries.
- Make audit logs tamper-evident and exportable Chain admissions, denials, human approvals, and tool invocations so compliance and incident response teams can verify the record later.
- Define fail-closed defaults for policy errors Treat missing data, policy evaluation failures, and unverified provenance as deny conditions rather than fallback allow behaviour.
Key takeaways
- MCP governance is about controlling the server estate as a lifecycle problem, not just hardening a protocol endpoint.
- The biggest operational weakness is the gap between approved status and real runtime behaviour, where tool use and content flow must be constrained.
- A defensible programme needs inventory, curated admission, per-call enforcement, and tamper-evident audit evidence working together.
Related NHI Mgmt Group resources: NHI Authentication Guide · Incident Response Guide · Incident Response Maturity Model · Smithery.ai MCP hosting breach 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Public and uncurated MCP servers create third-party trust risk at the server boundary. |
| NHI-05 — Overprivileged NHI | The article centres on limiting what a server may do once loaded and approved. | |
| NHI-08 — Environment Isolation | The article highlights local runtime control across desktop, Kubernetes, on-premises, and air-gapped environments. | |
| Recommendation — Review external MCP servers as third-party NHIs before allowing them into the internal registry. Constrain MCP server tool scopes so approved servers cannot exercise unnecessary privilege at runtime. Isolate MCP runtimes and policy enforcement so trust decisions remain local to the execution boundary. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | MCP governance is fundamentally about who can call which tools and what they can do. |
| Recommendation — Align MCP tool permissions and approvals with PR.AA-05 so authorizations stay explicit and reviewable. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat pattern includes trusted server paths being abused to reach additional systems and data. |
| Recommendation — Map MCP abuse paths to credential access and lateral movement to guide detection and containment priorities. | ||
Key terms
- MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
- Curated Registry: A curated registry is a governed catalog of approved tools or services with verified configurations and ownership. In NHI and AI tooling programmes, it functions as the control point for sanctioned discovery, installation, and lifecycle management.
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- Tamper-Evident Audit Trail: A tamper-evident audit trail is a log record that captures who invoked an AI agent, which tool it called, what policy decision was made, and when it happened. It is designed for forensic reconstruction, compliance review, and incident response, especially when actions happen faster than humans can supervise them.
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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org