Security teams should treat MCP servers as execution environments with privilege, not as harmless utilities. The baseline should be containerized execution, pinned dependency versions, and restricted outbound network access. That combination limits what a compromised package can reach, even if a malicious release slips into the dependency tree.
Why This Matters for Security Teams
MCP supply chain risk is not just a software hygiene problem. In developer environments, an MCP server can act as a bridge between code, data, tools, and sometimes secrets, which means a compromised package can create an immediate path to lateral movement or data exposure. That makes dependency integrity, execution isolation, and outbound control part of the security design, not optional hardening. The issue also intersects with identity governance because MCP components often rely on tokens, API keys, and service credentials that are easy to over-grant and hard to inventory.
Security teams should treat this as a trust-boundary problem. Current guidance from the NIST Cybersecurity Framework 2.0 supports asset visibility, secure configuration, and continuous monitoring, but it does not prescribe MCP-specific controls. That is where practitioners need to apply a stricter operating model: know what is allowed to run, what it can reach, and which identities it can use. In practice, many teams discover MCP abuse only after a developer plugin or package has already been granted broad access to internal systems.
How It Works in Practice
The practical containment model starts with reducing what an MCP server can do at runtime. Containerization helps, but only if it is paired with pinned versions, minimal base images, and explicit egress restrictions. A pinned dependency tree reduces exposure to surprise releases, while network controls stop a compromised component from calling out to external hosts or reaching internal services it should never see. Security teams should also require code review or approval gates for any MCP server that can invoke tools, access repositories, or read environment variables.
For most organisations, the strongest control set includes:
- Run MCP servers in isolated containers or sandboxed processes with no unnecessary host access.
- Pin package versions and verify provenance where the ecosystem supports it.
- Restrict outbound network access to approved destinations only.
- Separate developer convenience tokens from production-grade secrets.
- Monitor tool invocation, process launches, and unexpected file or network access.
This is where identity controls matter. The OWASP Non-Human Identity Top 10 is directly relevant because MCP servers often behave like service identities with persistent access and opaque ownership. If a server authenticates to repositories, SaaS tools, or internal APIs, those credentials should be treated as non-human identities with explicit scoping, rotation, and revocation paths. Security teams should also review whether the MCP server can mint, forward, or reuse credentials on behalf of the developer session.
Where agentic workflows are involved, the risk surface expands further. The OWASP Agentic AI Top 10 and the OWASP Top 10 for Agentic Applications 2026 both point toward the same operational reality: tool access must be bounded, observable, and revocable. These controls tend to break down in fast-moving developer platforms because teams allow broad package installation rights, reuse long-lived tokens, and skip egress filtering to avoid slowing local workflows.
Common Variations and Edge Cases
Tighter MCP containment often increases developer friction and pipeline overhead, so organisations have to balance speed against blast-radius reduction. That tradeoff becomes sharper in local workstation setups, shared build runners, and inner-source environments where teams expect rapid plugin installation and frequent updates. Best practice is evolving here, and there is no universal standard for how much runtime freedom an MCP server should have by default.
One common edge case is internal-only MCP servers that are assumed to be low risk because they are not internet-facing. That assumption is weak if the server can reach source control, issue trackers, or secrets managers. Another case is agent-assisted development, where the MCP layer may indirectly touch production data through a chain of tools. In those environments, security teams should apply the same scrutiny they would to any privileged automation component: explicit ownership, narrow scopes, strong logging, and a clear kill-switch.
When the environment includes human and machine identities side by side, the cleanest rule is to separate developer convenience from privileged execution. Use short-lived credentials where possible, avoid shared service accounts, and treat every MCP package update as a potential trust change. If the organisation cannot answer who approved the server, what it can access, and how it is disabled, the supply chain risk has not been contained yet.
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, OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | MCP servers need authenticated, scoped access to reduce blast radius. |
| OWASP Non-Human Identity Top 10 | MCP servers often operate as non-human identities with persistent privilege. | |
| OWASP Agentic AI Top 10 | Agentic tool use makes MCP execution and delegation risks more dangerous. | |
| NIST AI RMF | GOVERN | AI-enabled developer workflows need governance for execution and accountability. |
| MITRE ATLAS | Adversarial abuse can target tool use, supply chain, and model-connected workflows. |
Inventory MCP credentials, scope them tightly, and rotate or revoke them like any service identity.
Related resources from NHI Mgmt Group
- How should security teams contain a supply chain incident in build environments?
- What do security teams get wrong about MCP supply-chain risk?
- How should security teams reduce npm and PyPI supply chain risk on developer machines?
- How should security teams reduce the risk of secret theft from npm supply chain attacks?
