What Credence does, what it doesn't do, what we publish, and what stays private.
Credence is a trust registry for AI tools. It scans MCP servers, OpenClaw skills, and Claude Desktop extensions, then publishes a cryptographically signed attestation with a trust score, verdict, and provenance data. You can check that attestation from the CLI, an MCP client, or CI before you install anything.
Scanners find things. They don't decide what those things mean. Credence runs multiple scanners (Semgrep, Bandit, Trivy, Gitleaks, plus custom analyzers for skills and extensions), normalizes the results, and then passes them through adversarial deliberation: five AI agents with different security mandates debate the findings and produce a verdict. A scanner tells you "there are 3 high-severity findings." Credence tells you whether that means the tool is dangerous or just noisy.
The provenance layer matters too. Scanners don't check who wrote the code, whether it's a fork, whether the original author was removed from the contributor list, or whether the GitHub account is 12 days old. Credence does.
Currently: MCP servers (git repos), OpenClaw skills from ClawHub, and Claude Desktop extensions (MCPB bundles). Each gets the same scanning pipeline and attestation model. The registry tracks a tool_type field so you can filter by category. We're adding new tool types as the AI tool ecosystem evolves.
The registry, scanning pipeline, CLI, and MCP server are all open source under the MIT license. The adversarial deliberation engine is a separate service. The full scan pipeline and attestation schema are in the GitHub repo.
Three dimensions, each scored 0–100:
Security (30% weight) — Code-level findings from static analysis and vulnerability scanners. Secrets detection is weighted highest because leaked credentials are immediately exploitable.
Provenance (40% weight) — Who wrote it and can we verify that? Checks fork status, account age, author identity, lockfile presence, and contributor history. This is the heaviest dimension because the SmartLoader attack that motivated Credence was a pure provenance attack.
Behavioral (30% weight) — What does the tool claim to do vs. what it actually does? Analyzes MCP tool definitions, permission requests, and suspicious patterns in skill/extension metadata.
The aggregate score is a weighted average with hard overrides: if any dimension scores 39 or below, the aggregate is capped at 39 regardless of the other dimensions. If provenance is 0, the aggregate is forced to 0.
VERIFIED (90+) — No significant findings. Provenance checks out. The deliberation panel agreed this tool looks clean.
CONDITIONAL (70–89) — Some findings or provenance gaps, but nothing that looks intentionally malicious. Might have a missing lockfile, a low-severity CVE, or a young account. Use your judgment.
FLAGGED (40–69) — Significant concerns. Could be a poorly maintained project, or could be something worse. The deliberation panel saw enough to warrant caution. Read the attestation details before installing.
REJECTED (0–39) — The tool failed hard on one or more dimensions. This is what a supply chain attack, a coordinated fork network, or a project with critical unpatched vulnerabilities looks like.
Verdicts carry a _PRELIMINARY suffix until adversarial deliberation confirms them. Only confirmed verdicts enter the registry.
After the scanners run, five AI agents with different mandates debate the findings. Two are skeptics (looking for attacks and supply chain red flags), one is neutral (checking compliance), and two are believers (arguing for legitimate use cases). They go up to five rounds, and the debate terminates early when positions stabilize.
This catches things scanners miss. Obfuscated Lua bytecode in a text file wouldn't trigger a Semgrep rule, but the combination of that file plus a forked repo plus a missing original author plus a brand-new account is enough for the skeptic agents to argue rejection. Deliberation lets Credence reason about signals in aggregate, not just count findings.
Yes. Attestations are pinned to a specific git commit. If the code changes, submit a new scan. The new attestation will replace the old one in the registry. The previous scan results stay in scan-results/ for the historical record.
No. Raw scanner output (Semgrep findings, Trivy CVE details, Gitleaks secret locations) is ephemeral. It stays on the CI runner during the scan and is passed to the deliberation engine for analysis, but it never enters the public registry. What we publish is the trust score, verdict, provenance flags, and dimension breakdowns. Counts, not details.
This is a deliberate security boundary. Publishing "there's a hardcoded AWS key on line 47 of config.py" would be handing attackers a roadmap. We tell you the tool has a secrets problem. We don't tell the world exactly where.
Tools that receive a FLAGGED or REJECTED verdict go into a responsible disclosure hold. The score and verdict are recorded internally but not published to the registry until the disclosure process completes. For tools classified as adversarial (intentionally malicious), the hold is 24 hours and then auto-publishes. For tools with vulnerabilities, a maintainer reviews first.
The goal is to give maintainers time to fix legitimate issues before the score goes public, while still publishing adversarial tools quickly so people know to avoid them.
Each attestation includes: the commit SHA, a deterministic source fingerprint (SHA-256 hash of all files), the trust score and dimension breakdowns, the confirmed verdict, provenance flags, lockfile information, author identity data, the tool type, and an Ed25519 signature covering all of it. You can verify the signature independently with the public key published in the registry index.
Every file in the repository (excluding .git/) is hashed individually with SHA-256. Those per-file hashes are combined into a single deterministic fingerprint for the entire codebase. This fingerprint is pinned to a specific git commit and included in the signed attestation. If even one byte of source code changes, the fingerprint changes.
Yes. Install the Credence CLI (pip install credence-mcp) and run credence verify <server-name>. It fetches the attestation, checks the Ed25519 signature, and compares the source hash against the code on your machine. You can also query attestations through the Credence MCP server from Claude Desktop or any MCP client.
No. Credence is install-time verification only. It tells you whether to trust a tool before you run it. Once installed, runtime behavior is out of scope. For runtime enforcement, look at Docker's MCP Catalog, ToolHive, Solo.io's Agent Mesh, or Acuvity's runtime guardrails. Credence is complementary to those tools.
Yes. Anyone can submit a tool for scanning. But the attestation carries their identity, not the original author's. The provenance checks would flag the mismatch: fork status, excluded original author, account age, identity discrepancies. The deliberation would evaluate those signals. You can't get a clean attestation without clean provenance, and you can't fake provenance without leaving flags that Credence is specifically built to detect.
The attestation only covers the exact commit that was scanned. If the code changes, the source fingerprint won't match. The Credence CLI's credence watch command monitors your MCP client config for newly added servers and alerts you if they don't have a current attestation. But if a previously-attested tool pushes a malicious update to the same commit hash (which would require compromising git itself), Credence won't catch that.
No. Credence catches supply chain attacks that leave provenance signals (forks, identity mismatches, young accounts, excluded authors) and code-level issues that scanners can detect. It does not catch: zero-day vulnerabilities in dependencies, runtime-only attacks, indirect prompt injection, or a perfectly patient attacker who builds a legitimate reputation over years before going malicious. Credence raises the cost and complexity of supply chain attacks. It doesn't make them impossible.
Use the submission form on the homepage. Provide the public git repository URL and optionally a specific commit SHA and server path (for monorepos). A Credence maintainer reviews the submission, and scanning starts when approved.
Not currently. Credence clones the repository during scanning, so it needs to be publicly accessible. The attestation model is designed for public trust decisions about public tools. Private tools are a different problem with different trust assumptions.
Both can submit. The attestation records whether the submitter is a verified maintainer (repo owner, collaborator, or contributor) or a third party. Verified maintainer submissions get that noted in the attestation. Third-party submissions still get scanned, but the submitter identity is recorded separately from the author identity.
Phase 1 (deterministic scanning) takes a few minutes. Phase 2 (adversarial deliberation) typically takes 5–15 minutes depending on the complexity of the findings. Total end-to-end is usually under 20 minutes. You'll see results posted to the submission issue when complete.
Semgrep — Static analysis with auto-config rules for Python, JavaScript, TypeScript, and more.
Bandit — Python-specific security linter.
Trivy — CVE scanning for dependencies across all major package ecosystems.
Gitleaks — Secrets detection (API keys, tokens, credentials in source).
Skill Analyzer — Custom scanner for OpenClaw skills: checks for encoded payloads, broad permission requests, quarantine bypass, and other skill-specific attack patterns.
MCPB Analyzer — Custom scanner for Claude Desktop extensions: checks manifest integrity, template injection, dynamic code loading, and source-bundle mismatches.
Results from all scanners are normalized into a unified evidence format before scoring and deliberation.
For GitHub-hosted tools: fork status, whether the original author is in the contributor list, account creation date (tiered: 30/90/180 days), repo owner vs. package metadata author match, lockfile presence and hash, coordinated fork network detection (cross-fork ring patterns among multiple accounts), and contributor availability.
For non-GitHub hosts: provenance checks are limited to lockfile detection. The attestation records this gap with a NON_GITHUB_HOST flag.
Ed25519 for attestation signing. SHA-256 for source fingerprinting and lockfile hashing. The attestation is canonicalized as sorted JSON, signed, and the signature is stored as base64 alongside a canonical hash for independent verification. The public key is published in the registry index.
Everything is static files served by GitHub Pages. The registry index (registry/index.json), per-server attestation files (registry/servers/), and redacted scan results (scan-results/) are all committed to the git repository. No database. No API server. The Credence CLI and MCP server read directly from these files.