What runtime verification reveals about MCP security
The MCP ecosystem is growing faster than security teams can manually inventory it. We run exact releases inside isolated environments to separate observable behavior from package claims.
The MCP ecosystem is growing faster than security teams can manually inventory it. We run exact releases inside isolated environments to separate observable behavior from package claims.
Our catalog currently resolves 71,584 active source listings into 71,565 canonical MCP implementations. Runtime coverage is still expanding, so verified results and untested inventory must never be confused.
That represents runtime coverage of 12.0% of canonical inventory. Among current versions with completed verification, 6.0% have at least one proven security finding. These rates describe the tested population, not the untested remainder.
Source metadata can tell us what a server says it supports. It cannot prove which tools initialize, whether a dangerous input reaches a sink, or whether a result repeats reliably. Our pipeline installs the exact package version, initializes it as an MCP client would, observes its protocol capabilities, and exercises bounded security canaries in an isolated sandbox.
An unscanned MCP is not clean. A locally proven input-handling flaw is not automatically a hosted-service compromise. A similarly named project is not automatically affiliated with the referenced brand. We preserve those distinctions because overstating evidence makes security intelligence less useful.
Tests execute against downloaded artifacts or authorized targets in isolated infrastructure. Aggregate research excludes secrets, unpublished exploit instructions, and embargoed disclosures. Exact-version evidence is retained so later releases can be compared without rewriting history.
Explore the live catalog or learn about continuous organizational monitoring.