Cryptographic trust for MCP servers
Source fingerprinting. Author identity verification. Adversarial security analysis. Building the trust layer the MCP ecosystem needs as it scales.
In active development
Source fingerprinting. Author identity verification. Adversarial security analysis. Building the trust layer the MCP ecosystem needs as it scales.
MCP is a powerful protocol — but like HTTP before TLS, the security layer is still being built. The ecosystem doesn't yet have the equivalent of npm audit, Sigstore, or Dependabot for MCP servers. Developers are making install decisions based on GitHub stars and README quality while the verification infrastructure catches up.
Those social signals can be manufactured. Straiker's STAR Labs recently documented exactly this — a supply chain attack using cloned repos and fake accounts to poison MCP registries. Credence adds the cryptographic trust layer the ecosystem needs.
Credence provides cryptographic attestation at MCP server install time — not social signals, not vibes, not stars.
Clone repo at exact commit. Generate SBOM via Syft. Compute Merkle tree SHA-256 source hash. Extract author identity from package metadata, GitHub API, and git history. Detect forks, compare contributor lists, flag provenance anomalies.
SAST via Semgrep and Bandit. Dependency CVE scanning via Trivy. Secrets detection via GitLeaks. MCP-specific tool analysis: suspicious patterns in tool definitions, dynamic description loading.
Multi-agent adversarial deliberation. Five agents — two skeptics, two believers, one neutral — debate the findings across up to five rounds. Primed with real MCP attack patterns: SmartLoader TTPs, tool poisoning, rug pulls. Produces confidence-scored verdict with dissenting opinions. Probabilistic issues require probabilistic solutions.
Cryptographically sign the analysis. Publish attestation with source hash, author identity, provenance flags, verdict, and trust score. Pin to exact commit — new commits invalidate attestation.
{
"server_id": "modelcontextprotocol/server-github",
"commit_sha": "a1b2c3d4...",
"source_hash": "sha256:def789...",
"source_hash_method": "merkle-tree-sha256",
"author_identity": {
"repo_owner": "modelcontextprotocol",
"identity_match": true,
"provenance_flags": []
},
"trust_score": 91,
"trust_dimensions": {
"security": 70,
"provenance": 100,
"behavioral": 100
},
"thinktank_verdict": "VERIFIED",
"signature": "ed25519:..." // verify before install
}
Fake provenance, cloned repos, manufactured credibility. The SmartLoader pattern.
Vulnerable dependencies in the server's dependency tree.
Hidden directives, unicode tricks, schema manipulation in MCP tool definitions.
API keys, credentials, tokens committed to source.
Dynamic tool descriptions, external config loading, version-gated behavior changes.
Missing lockfiles and lockfile drift across attestations.
Credence provides install-time trust data. It's complementary to runtime tools — Docker MCP Catalog, ToolHive, Solo.io Agent Mesh — that handle enforcement after installation. Defense in depth.
Attestations are only useful if machines can read them. Credence provides three consumption interfaces — so the trust check happens automatically, not manually on a website.
Add Credence as an MCP server in Claude Desktop, Claude Code, or any MCP client. Your AI agent calls credence_check_server before connecting to unknown servers. Attestation data flows through the same protocol your agent already speaks.
credence check owner/server from the terminal. Exit codes for CI integration: 0 = safe, 1 = not attested, 2 = flagged, 3 = rejected. Verify local source hashes against attestations before install.
Wrap any MCP server installation with a Credence check. Clone, hash, verify against the attestation, install only if the source matches. Works in shell scripts, CI pipelines, or orchestration tools.
# Install $ pip install git+https://github.com/pestafford/credence-registry.git#subdirectory=mcp-server # Add to claude_desktop_config.json { "mcpServers": { "credence": { "command": "python3", "args": ["-m", "credence_mcp.server"] } } } # Or from the terminal $ credence check modelcontextprotocol/server-github Trust score: 91/100 Verdict: VERIFIED ✔ VERIFIED
Finding vulnerabilities is only useful if they get fixed. Credence follows a tiered response model based on severity and verified submitter identity — we don't publish vulnerability details to people who don't own the code.
When a server is submitted, the pipeline checks whether the submitter is the repo owner or a listed collaborator via GitHub API. Verified maintainers are identified via GitHub API and notified directly when issues are found. Third-party submitters receive a verdict and provenance summary only — no vulnerability details. This prevents Credence from being used as a recon tool against other people's code.
Minor SAST findings, low-severity CVEs in transitive dependencies, style issues. Reflected in the trust score dimensions. No hold on publication. Maintainer notified via GitHub issue with suggested fixes.
Exploitable CVEs in direct dependencies, hardcoded secrets, suspicious MCP tool patterns. Maintainer contacted privately before attestation is published. 30-day remediation window. We'll help — dependency upgrades, secret rotation guidance, tool description rewrites. Attestation published after the window with current status, whether or not the issue is resolved.
Supply chain poisoning signatures, provenance fraud, malicious payloads, credential theft. Registry operators notified immediately for delisting. If the account is legitimate and compromised, we assist with incident response. If it's a manufactured identity operation, findings are published immediately with no remediation window and reported to the relevant platform (GitHub, npm, MCP Market).
After remediation, maintainers can request a fresh scan at the new commit. The updated attestation replaces the previous one. Full history is preserved — consumers can see that an issue existed and was addressed, which is better signal than no history at all.
Credence is a security tool, not a shaming tool. The goal is fewer vulnerable MCP servers in production, not more drama on security Twitter.
Submit an MCP server for Credence analysis. We'll clone the repo, run the pipeline, and publish the attestation. Submissions are tracked as GitHub Issues — you can follow progress there.
Opens a pre-filled GitHub Issue. You'll need a GitHub account.
A maintainer will review your submission and start the scan. Results get posted directly to your GitHub issue — watch it for updates.
Credence is open source and in active development. Architecture docs, attestation schema, and scan pipeline are on GitHub.