From Unknown to Verified: Solving the MCP Server Trust Problem

I think we can all agree that the Model Context Protocol (MCP) ecosystem is exploding. Developers are building AI agents that can interact with GitHub, query databases, scrape websites, and integrate with dozens of other services - all through MCP servers. It's an exciting time, but there's a problem lurking beneath the surface.

Every time you run a third-party MCP server, you're executing someone else's code with access to your systems.

That innocent-looking command npx @modelcontextprotocol/your-cool-mcp-server isn't just downloading a package - it's executing someone else's code on your system, potentially giving a stranger access to your code, API keys, and other sensitive data.

The Trust Problem We All Face

The majority of MCP servers today are typically deployed by:

• Run npx commands that download code at runtime from npm
• Run uvx or install Python packages with uv or pip from PyPI
• Trust that package names match what you think you're installing
• Hope the maintainer's build environment wasn't compromised
• Cross your fingers that nothing malicious got injected

It's a matter of time before we see cases of attacks like:

• Typosquatting: Malicious MCP servers with names like @modelcontextportocol/github-mcp-server (spot the typo) that steal your tokens
• Account takeovers: Maintainers' accounts get compromised, pushing malicious updates to legitimate packages
• Build system compromises: Attackers inject malicious code during the build process, creating backdoored packages that look completely legitimate

The scary part? You might never know you've been compromised until it's too late.

Enter Sigstore and GitHub Attestations

Fortunately, we don't have to accept this insecure status quo. The open source community has already built powerful solutions to verify software provenance:

Sigstore revolutionizes code signing by eliminating the need to manage cryptographic keys. Instead of developers juggling long-lived signing keys (which can be lost, stolen, or compromised), Sigstore uses short-lived certificates tied to your existing identity providers like GitHub or Google. When you sign software, the signature gets recorded in an immutable transparency log, creating an unforgeable record of who signed what and when.

GitHub Attestations take this further by creating detailed provenance records for anything built in GitHub Actions. These attestations don't just prove who signed the software - they prove which source code was used, which workflow built it, and exactly when and where the build happened.

Together, these technologies let you answer critical questions:

• Did this software really come from the claimed GitHub repository?
• Was it built using the official workflow, or something suspicious?
• Has anyone tampered with it since it was built?
• Can I trust the identity of who signed it?

Now let's see how we've integrated these proven technologies into ToolHive.

ToolHive: Security-First MCP Server Management

At Stacklok, we created ToolHive because we saw a gap in running MCP servers easily but also securely. As security engineers, we knew there had to be a better way.

ToolHive transforms MCP server deployment from a risky, manual process into a more secure, standardized workflow:

• One-command deployment: Instead of hunting through GitHub repos and figuring out installation procedures, just run thv run github and you're done.
• Container-based security: Every MCP server runs in a locked-down container with minimal permissions. No more worrying about what system resources a server can access.
• Curated registry: We maintain a registry of verified MCP servers, so you don't have to evaluate every package yourself.
• Enterprise-grade features: Fine-grained authorization controls, secure secrets management, and Kubernetes integration takes ToolHive a step further from being a local tool.

But even with all these security measures, there's still the question of: How do you know the container you're running is actually what the maintainer built?

Why We Built Provenance Verification Into ToolHive

At Stacklok, security isn't just a feature we bolt on - it's why we exist. We started ToolHive because we believe developers deserve secure tools that don't sacrifice usability for safety.

The container security model solved many problems, but even if we run MCP servers in locked-down containers, what if the container itself is malicious? What if someone compromised the build process? What if an attacker pushed a backdoored image to the registry?

That's why we integrated Sigstore and GitHub Attestations directly into ToolHive's core.

How It Works

When you deploy an MCP server, from the built-in ToolHive registry, ToolHive:

1. Examines the container image and extracts its cryptographic fingerprint
2. Searches for signatures and attestations associated with that specific image
3. Verifies the cryptographic signatures against trusted certificate authorities
4. Validates the build provenance to ensure it matches the expected source code and workflows for that image
5. Enforces your security policy by allowing, warning, or blocking deployment based on verification results

All of this happens automatically - you don't need to understand cryptography or manage signing keys.

Three Levels of Protection

ToolHive gives you control over how strictly you want to enforce verification:

# Lenient: Skip verification (development only)
thv run --image-verification=disabled github

# Balanced: Verify but warn on failures (default value, good for migration)
thv run --image-verification=warn github

# Strict: Require verification to pass (recommended for production)  
thv run --image-verification=enabled github

Registry Integration

Our curated registry now includes provenance metadata that tells ToolHive exactly what to verify. For example, here's how we've configured the GitHub MCP server:

{
  "provenance": {
    "sigstore_url": "tuf-repo-cdn.sigstore.dev",
    "repository_uri": "https://github.com/github/github-mcp-server",
    "signer_identity": "/.github/workflows/docker-publish.yml",
    "runner_environment": "github-hosted",
    "cert_issuer": "https://token.actions.githubusercontent.com"
  }
}

This metadata ensures ToolHive only accepts containers that:

• Were built from the official GitHub repository
• Used the expected GitHub Actions workflow
• Were signed by GitHub's certificate authority

What are attestations and why do they matter?

An attestation is an authenticated statement about a software artifact. Any process or tool that needs to associate metadata with a piece of software for later verification can capture it in an attestation. There are many uses for attestations, such as verifying build provenance, signing a claim that a process has been performed, results of scanning tools, listing software components (SBOM), and more.

An attestation has two parts: a subject (the software the attestation applies to) and a predicate (the claims made about the software).

An example attestation structure: A provenance attestation from the SLSA website.

Attestations are the building blocks of the transparent supply chain. As more and more data is collected during the software development lifecycle, software consumers, regardless of whether they are at the end or in the middle of the chain, can understand the risk they are taking with their software.

(For more information about the importance of attestations and how they're different from signatures, check out this great blog post by Trevor Rosen at GitHub.)

ToolHive works with Attestations from both public repositories (using Sigstore's public infrastructure) and private repositories (using GitHub's Sigstore instance).

What This Means for You

Provenance verification isn't just a technical achievement - it's a practical solution to real security problems:

• Stop supply chain attacks before they start: Verify that MCP servers actually come from their claimed sources, not from attackers with similar package names.
• Detect tampering automatically: Cryptographic verification ensures nobody has modified the container image after it was built.
• Enforce organizational policies: Set rules about which sources you trust and automatically enforce them across all deployments.
• Sleep better at night: Know exactly what you're running and where it came from, with cryptographic proof.

What's Next

We're just getting started. The MCP ecosystem needs security standards that grow with its popularity, and we're committed to helping. We'll be sharing more about the heuristics we follow when we are evaluating MCP servers for the ToolHive registry and overall best practices for maintainers who want to build trustworthy servers.

The MCP ecosystem is at a turning point. We can either accept the current insecure deployment patterns, or we can build something better together. At Stacklok, we believe in the power of community-driven open source projects.

Ready to join us?

Try ToolHive today at github.com/stacklok/toolhive. Join our Discord community to share feedback and help shape the future of secure MCP deployment.