Yes. Floating npx installs are convenient but they weaken version control, reproducibility, and incident traceability. A pinned package gives you an explicit approval point and a stable artefact to assess, while a floating install can change whenever the registry changes. For governed environments, that difference is material to both risk and auditability.
Why floating npx MCP server installs deserve a different review path
An npx-installed mcp server is a moving target. The package that runs today may not be the exact package that runs tomorrow, so approval, testing, and rollback all become weaker if you treat it like a pinned artefact. For managed environments, that makes the install method part of the security decision, not just a convenience choice.
A pinned package gives you a stable version boundary, which matters when you need to know what was reviewed, what was deployed, and what behaviour is expected. A floating install can be acceptable for experimentation, but it should not be treated as equivalent to a package you have explicitly selected, recorded, and approved for operational use.
For MCP-specific operational guidance, the MCP Security Guide is the most direct starting point because it covers MCP authorisation, token handling, gateways, and the practical controls that become harder to enforce when servers are not pinned.
What changes when the registry can change the server you run?
The main difference is control over the supply chain boundary. With a pinned package, the artefact you assess is the artefact you expect to run. With an npx install, that expectation is weaker because a later invocation can resolve to a different release, with different dependencies, behaviour, or security posture.
That affects more than version drift. It also changes incident traceability, because logs, change tickets, and approvals may point to a command that no longer uniquely identifies the running code. When a server mediates sensitive tool calls or secrets, that ambiguity increases the cost of investigating abuse, misconfiguration, or malicious behaviour.
This is why package-level governance belongs in the review. If the server handles tokens, tool routing, or local credentials, the operational question is not simply whether the package name is familiar, but whether the exact artefact has a durable approval record. The AI Supply Chain Security and AI-BOM Guide is useful here because it frames MCP servers as part of the broader supply chain that should be recorded and governed.
When should teams pin, mirror, or block floating installs?
Use pinning by default when the MCP server is allowed to interact with production systems, user data, secrets, or privileged tooling. If the server is part of a repeatable workflow, treat reproducibility as a requirement, not a preference. Floating installs are better reserved for local evaluation, short-lived proofs of concept, or tightly supervised sandbox use.
If you must allow floating installs, reduce the blast radius. Restrict where they can run, constrain what they can access, and require a follow-up approval step before the same package is used more broadly. That gives you a chance to review the concrete artefact after it has been resolved, rather than relying on a moving reference string.
For teams that want a control baseline, the RFC 9728: OAuth 2.0 Protected Resource Metadata and the Model Context Protocol: Authorization specification both reinforce the need to know what a server is, how it declares itself, and how clients decide whether to trust it.
Risk and Threat Considerations
Floating installs create a time-of-check, time-of-use problem for software trust. The risk is not only that a newer version may be buggy, it is that the approved identity of the server can drift without an explicit change record, which weakens auditability and complicates compromise detection.
Failure mechanism: A registry-resolved package can change between runs, so the organisation believes it approved one artefact while a different artefact actually executes. That opens the door to silent behaviour changes, dependency substitution, and slower incident reconstruction.
Impact: Security teams lose a clean line from approval to execution, which makes it harder to prove what was deployed, what accessed sensitive data, and whether a later event involved an expected version or an unexpected one. In governed environments, that can turn a routine operational question into an investigation.
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 OWASP API Security Top 10 address the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Integrity | Pinned vs floating installs affect artefact provenance and repeatability. |
| Recommendation — Record and verify the exact artefact source before allowing production use. | ||
| OWASP Non-Human Identity Top 10 | NHI-09 — NHI Reuse | Floating installs can bypass stable approval of the specific server artefact. |
| Recommendation — Pin the MCP server version so the reviewed artefact stays the deployed artefact. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Approved software sources and controlled deployment reduce registry-driven drift. |
| Recommendation — Restrict production installs to approved, controlled software sources. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Version drift is a change-control problem that needs explicit approval boundaries. |
| Recommendation — Require approval for package changes that alter the deployed MCP server. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unpinned resolution can create inconsistent server behaviour and trust decisions. |
| Recommendation — Validate server configuration and trust settings before each deployment. | ||
Practitioner Guidance
Decision rule: If the MCP server can reach production data, privileged APIs, or any credentialed workflow, require a pinned version or an internally mirrored artefact. If it is only for local experimentation, allow floating use only inside a constrained environment with no production trust.
What to verify: Confirm that the exact package, version, and source used for approval are recorded in change control, and that the same artefact is what your deployment pipeline resolves. Also verify who can override that decision, because exceptions are where floating installs often become permanent by accident.
Practitioner takeaway: Treat npx convenience as a deployment mode with weaker assurance, not as a harmless shortcut, because the security difference only matters once you need to explain exactly what ran and why you trusted it.
Related resources from NHI Mgmt Group
- Should organisations block local MCP servers or govern them differently?
- Should organisations treat PAM for Kubernetes differently from PAM for servers?
- What do organisations get wrong when they treat MCP servers like a VPN concentrator?
- Should organisations treat MCP servers as part of the identity control plane?