Trust, stated plainly.

Every published screen verdict is semantic: an adversarial LLM judge reads the description for hidden instructions, exfiltration, or overclaims, bound to the exact tool definition seen. The screener runs on a recurring schedule, prioritizing new or requested servers; coverage expands across the registry as the corpus grows. The output is a per-tool REVIEW or UNVERIFIED with dimension verdicts and severity. The deterministic conformance probe (does observed behavior match the declared schema) is built but has not run on the public corpus; no published verdict carries a conformance result, and a clearing ALLOW - which the probe would have to earn - is not produced at v1.

The full method, the four-state model, and the graduation gate are documented in /methodology. It is written to be checked, not taken on faith.

Verdict history is hash-chained and timestamped to Bitcoin via OpenTimestamps. Once a block confirms, the trust record for a tool cannot be quietly rewritten. The claim is precise: anchored history exists. It is not a claim about minute-level ordering inside the confirmation window - see the honest limits below.

• · Advisory, not blocking (the directory screen). The directory screen publishes a verdict; your agent or IDE decides whether to act. The screen does not sit in your call path or proxy your traffic. The in-path drift gate (below) is the separate surface that can HOLD a call.
• · Public artifacts in. Verdicts are produced from public tool definitions (the description + schema). The screener evaluates the text you paste - do not paste real secrets into it.
• · No call-time data. We evaluate the tool definition, not your runtime calls. Your arguments and your data never reach us.
• · Open by default. Methodology, quality scoring, and the registry source are public on GitHub. What we assert, you can audit.

The screen above is advisory and out of the call path. The drift gate is different in one decisive way: it is in-path. It pins each MCP tool’s contract on first sight and checks the live contract before your agent acts, so it can HOLD the call - not just alert after the fact, the way a passive scanner does. That position is what lets it protect a running agent; it is also what makes its trust posture worth stating exactly.

• · Zero credential custody. The gate never receives your tokens. It observes the session your client already authenticated and reads only the public tool contracts; the one-click wiring passes a server’s original env / headers through to that server untouched. There is no token field and no second connection - structurally, not as a promise.
• · Contract-diff, not a safety verdict. A HOLD means the tool’s contract changed versus what you pinned, not that the new contract is unsafe. The gate asserts what changed; you review and re-pin if it is expected.
• · Fail-closed. A tool with no pin, an unreadable contract, or a diff the gate cannot complete HOLDs rather than proceeds. The gate never renders a silent ALLOW on something it could not verify.
• · Advisory in judgment, in-path in effect. The judgment is narrow and provable (a deterministic contract-diff); the effect is real because the gate sits in the call path. We do not claim it verifies safety, blocks attacks, or certifies a tool.

What a security reviewer needs in one place: where the gate runs, what leaves the machine, and which threats it does and does not address.

• · Where it runs. In-path on the developer / agent host, single-tenant by default. The multi-tenant gateway (logical, in-process isolation, posture, and audit) is built but held off by default behind an explicit flag; spoof-resistant identity and process/VM separation are roadmap, and it is not the default deployment.
• · What leaves by default: nothing. The deterministic tier-0 contract-diff runs locally; the default build egresses nothing and never holds your credentials. Tiers 1-3 (cloud corpus lookup, LLM consult, behavioral verifier) are built in-path seams, each held off by default and gated behind explicit opt-in.
• · Optional egress: the cloud corpus lookup. If you opt into the cloud tier-1 corpus lookup, the only thing that leaves is a contract hash (a deterministic hash over the public tool contract) plus your bearer key on the pinned transport - never a token, an argument, a schema body, or your call data. Any error degrades to a miss (fail-closed). That request lands on mcpindex’s US-region edge.
• · Optional egress: the drift network. If you opt into drift telemetry (MCPINDEX_DRIFT_TELEMETRY=detection, off by default), the gate emits one one-way signal on a pin or a drift - salted (HMAC) fingerprints of the server/tool id, the contract hashes, the change type, a safety flag, an hour-rounded time, a random install id, and the SDK tag - and queries the network so it can warn you on the first call. Never a schema, argument, description, URL, or server/tool name. Fail-open: it never blocks or changes a call. Full disclosure on privacy.
• · Sub-processors. None in the default local deployment - nothing leaves the host, so there is nothing to sub-process. If you opt into the cloud tier-1 lookup, the request lands on our US-region edge (Vercel) and no other sub-processor sees it. A current sub-processor list is available on request.
• · Supply-chain integrity. The install.sh / install.ps1 installer and the published wheel ship with a SHA-256 you can verify before you run them, and the installer is auditable by piping it to less first. A signed single-binary (SLSA provenance) is on the roadmap; until then, pin the checksum.
• · Threats addressed. Silent contract drift (a tool changing its contract after you pinned it), description-poisoning (hidden instructions in a tool description), and an injection / exfil marker planted in an input or output schema.
• · Threats NOT addressed. The gate does not prove a tool safe, block or prevent an attack, or catch malicious runtime behavior that stays within an unchanged contract. It reports what changed; you decide.

Direct and current: mcpindex is pre-SOC 2. We are not going to imply otherwise. The interim posture is the one above - advisory deployment, no call-time data, public method, Bitcoin-anchored history. Formal attestation (SOC 2 Type 2) is on the roadmap, not something we claim today. If you have a specific compliance requirement, tell us what you need and we will answer honestly about where we are.

Data handling is described in our privacy policy.

A trust product earns trust by stating its edges, on every verdict: the screen is semantic (the conformance probe is built but has not run on the public corpus; when it runs it is monitored, not enforced); confidences are reported but not yet calibrated (calibrated=false at v1); coverage expands continuously as the backfill scanner runs (15 of 150 labels to graduation, adversarial cases first). The full contract lives on /methodology - and it changes there first, before the verdict surface does.

Report a vulnerability to security@mcpindex.ai (or hello@mcpindex.ai). We acknowledge within two business days and aim to ship a fix or a mitigation timeline within ten. Please give us a reasonable window before public disclosure. A SECURITY.md with the same policy and a PGP key is published in the repo.

Live system status, data freshness, and the incident log are at /status. To report a problem with a verdict, email hello@mcpindex.ai.