MCP Server Attestation
Layer-2 supply-chain hardening for MCP servers
Ed25519-signed tool manifests, runtime spawn-attestation, default-deny argument sanitizer. Defends against marketplace-poisoning + CVE-2025-69256.
What it solves
In April 2026 a marketplace-poisoning study found that nine of eleven MCP registries accepted a malicious server, and the published position on that was that it is expected behaviour. Two CVEs from the same period show what it costs in practice: remote code execution through a command injection in one framework, and a spawn hijack through an OAuth-installed server in an editor. Nothing in the protocol proves which tools a server may expose or which processes it may start.
How it works
A signed manifest states which tools a server exposes and which spawn calls it may make, and the library verifies that with Ed25519 signatures against a trust-on-first-use store. Alongside it sits a command line tool that generates keys, signs, verifies, inspects, prints a fingerprint and checks a pin. It is a dependency you add, not a runtime you replace.
When to use it
Sign your own servers so a consumer can pin them, and verify the ones you install so a silent change in the tool list becomes visible. Pinning is the part that pays off later: it turns a supply chain change from something you never see into something that fails loudly.
When not to use it
A signature says who published something, not that it is good. A signed server can still be badly written or hostile, and trust on first use means exactly that: the first contact is taken on faith and only changes afterwards are caught. For runtime defence rather than provenance, mcp-armor is the piece that sits in the traffic.
Stars
★ 0
installs
↓ 831
Clones (14d)
⊟ 226
Language
TypeScript
Updated
2026-08-21
Install
npx -y mcp-server-attestation