Notifications
Clear all
Topic starter
18/08/2026 2:52 pm
TL;DR: MCP servers should be treated like production artifacts, pinned, signed, scanned, and promoted through a reviewed catalog because runtime fetches from npx or uvx create blind trust in upstream code and complicate governance as AI workflows gain access to sensitive systems, according to Obot. The security model shifts from install-time diligence to artifact ownership and catalog-controlled promotion.
NHIMG editorial — based on content published by Obot: MCP supply chain security and governance for production servers
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create a bigger secrets risk than ordinary package installs?
A: Because the threat is not only code on disk, but code that executes inside a real user context and can read live credentials immediately.
Q: What breaks when MCP servers are allowed to run from latest upstream code?
A: The review model breaks first, because the code that runs is no longer the code that was approved.
Practitioner guidance
- Pin every MCP server version before approval Replace latest references with fixed upstream versions in the catalog manifest so reviews, diffs, and rollbacks remain possible.
- Build and scan the deployable image only Package the exact server artifact that will run, then scan that final image and publish the results alongside the build output.
- Require signature checks at admission time Use digest signing and policy enforcement so the runtime accepts only artifacts produced by the trusted CI workflow.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- The reference GitHub Actions workflows that detect upstream version changes and open reviewable pull requests.
- The manifest structure used to pin Node, Python, and container-based MCP servers in a catalog.
- The build, sign, and SBOM generation steps used to turn an MCP server into a deployable artifact.
- The runtime and catalog promotion pattern that links approved images to downstream deployment visibility.
👉 Read Obot's analysis of MCP supply chain security and catalog governance →
MCP server supply chain security: what IAM teams need to govern?
Explore further
18/08/2026 3:35 pm
MCP supply chain security is an identity control problem, not just a software build problem. The article correctly frames MCP servers as production artifacts because each server can reach sensitive tools, credentials, and data sources. That makes the catalog, the signed build, and the promotion gate part of the identity governance layer, not just DevOps hygiene. Teams that treat MCP startup as a convenience feature will miss the fact that the server itself is now an access-bearing actor.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that makes centralised control harder to sustain.
A question worth separating out:
Q: Who should control promotion of MCP server updates?
A: The team operating the catalog should control promotion, because that is where review, scope, and visibility decisions become enforceable. If promotion happens automatically at runtime, teams lose the ability to track what changed, when it changed, and why. Catalog governance is the point where identity, access, and change management meet.
👉 Read our full editorial: MCP supply chain security means treating servers as artifacts
