MCP Server Registry Security Scoring Methodologies

MCP Server Registry Security Scoring Methodologies measure different parts of server risk, but none replaces runtime enforcement. Securing OAuth credentials for enterprise AI agent tool calls requires task-scoped credentials, identity-bound access policies, and controls that inspect actions after a token is issued. Registry grades help assess a server before connection, while enterprise governance must control what agents can do after connection.

Why MCP registry security scores exist and what gap they are trying to fill

Li and Gao's DSN 2026 paper describes a chain with no independent check between its links. Registries list servers, hosts integrate them, and LLMs invoke their tools without any entity independently verifying what the others have done. NSA guidance states that “associating a session to an identity is not defined by the protocol” and that RBAC permissions are not exchanged at instantiation. MCP lets tools connect but leaves out the identity binding and authorization needed to trust those connections.

That leaves the consuming organization responsible for deciding which servers to trust, with no standardized signal to settle the question. Registry scores try to fill this vacuum, but their authors have defined security in different ways. Some check code, while others test how a live server behaves or check what a tool tells the model. Runlayer layers identity-tied policy enforcement and real-time MCP-specific threat detection over those signals, binding actions to authenticated sessions.

The scale of what is actually deployed and how little of it has been vetted

Padilla's dynamic assessment cites Censys telemetry showing over 21,000 server instances detectable on the public internet. Its discovery pipeline draws on eleven passive sources, including certificate transparency logs, package registries, code repositories, and internet search services. That spread matters because the deployment surface is not contained in one registry.

The same study found that nearly half of the servers confirmed to be active disappeared between measurement runs just days apart. A grade from an earlier deployment can no longer serve as a steady baseline for the server in use. Because it is easy to expose a database, shell, or cloud API as an MCP endpoint, what needs to be scored keeps changing. Before security teams can use grades to make decisions, they need to see which servers are in use, including unreviewed deployments that observability platforms such as Runlayer find across an organization.

Static analysis scoring: what it measures, how grades are constructed, and where it stops

Static analysis offers a structured, reproducible way to grade many servers without connecting to them. The most revealing design choice in the static-composite approach is the cap at 20 when analysis confirms a dangerous code sink. Arbitrary code evaluation, command injection, or unsafe deserialization can force a failing result regardless of how clean the rest of the server looks. This cap keeps good supply-chain findings from averaging away a critical code flaw.

Li and Gao's MCPInspect uses a two-stage pre-integration analysis covering misleading tool metadata and exploitable code vulnerabilities. It found hundreds of vulnerable servers and others with suspicious descriptions, showing the value of inspection before integration. But static analysis never contacts a live server, so it cannot show whether the server enforces its declared authentication, changes tool definitions between calls, or behaves as its published manifest says it does. At execution time, MCP-aware detection systems, including Runlayer, address risks such as tool poisoning and credential exfiltration that a source-level grade cannot settle.

Dynamic behavioral auditing: what live testing reveals that static grading cannot see

Dynamic auditing tests the running service instead of relying on what has been published about it. Padilla's Corvus framework implements 34 test modules covering 10 MCP-specific vulnerability classes. Across four measurement runs in July 2026, 414 servers received full dynamic auditing. The tests exposed SQL injection in live tool responses, SSRF targeting cloud metadata services, prompt template injection, and path traversal through cursor manipulation. These findings make the distinction concrete, because runtime evidence can reveal failures that source or manifest inspection alone leaves unresolved.

Cursor-based path traversal is especially instructive because it weaponizes MCP's pagination primitive rather than an obviously suspicious declared capability. The primitive belongs to the specification, while its unsafe behavior emerges when exercised. The study also found hundreds of tool instances that allowed shell execution without access controls, showing that the risk was present at runtime. Getting that evidence has a cost, because connecting to production systems brings duties under responsible disclosure and limits how many servers can be tested. Padilla confirmed only 640 active servers from the larger discovery set before dynamic testing began, so live auditing complements a registry-wide static scan.

Pattern-based scanning and its false-positive problem

Pattern-based scanning checks whether tool text looks like a known warning sign, but ordinary MCP instructions often look like attack instructions. More than a quarter of the detections in the described audit were flagged as “prompt injection” because of standard dependency instructions such as “You MUST call this function first”. The scanner could not distinguish a coordination instruction from an adversarial override. Likewise, browser-devtools-mcp received 9 detections, all for designed functionality such as screenshots, JavaScript execution, and navigation. Counting those matches as the same kind of security failure would use what tools can do as a measure of how they are misused.

The audit also surfaced genuine concerns, including desktop-commander credential harvesting through filesystem search, arbitrary SQL execution in a postgres tool, and injection-capable tools. Cisco mcp-scanner's pattern checks and mcp-scan's config-drift checks examine different surfaces and need to be assessed on that basis. The latter calls tools/list twice, compares the results for mutations, checks names for shadowing and typosquatting, and flags exfiltration risks. On the 33-server set, it found mostly benign mutations as well as name shadows and exfiltration flags, reinforcing why findings need interpretation before they become a grade.

Tool-description injection scanning as a distinct evaluation layer

The tool catalog is part of the LLM's prompt at tools/list time, so its text is not merely documentation. A rigorous injection check treats the tool's name, description, and JSON schema, including every nested field, as one document. Scanning only the description string leaves other parts of that document unexamined. The methodology notes that attackers move into schemas and nested fields once descriptions are being scanned.

This evaluation also needs to distinguish what text means. Li and Gao identify textual tool metadata as a distinct risk because checking executable code does not evaluate instructions presented to a model. The scan must run at registration and on every tools/list refresh because a server can silently change its definitions after approval. That rug-pull problem makes the freshness of the evaluation as important as its coverage.

Authentication posture as a scored dimension and why declared auth is not the same as enforced auth

Authentication posture contains two separate facts, namely what a server declares and what its endpoint enforces. The MCP specification defines an OAuth 2.1 flow for remote servers in which the server points to an authorization server, the client completes consent, and scoped tokens are issued. The protocol supports PKCE, token scoping, and consent screens, but makes the flow an optional recommendation. Padilla's dynamic audit found that the vast majority of audited servers operated without an OAuth authentication layer at runtime.

A manifest-only score leaves that gap unresolved because its evidence is limited to a policy statement. Even confirmed token issuance answers only the initial access question. The EMA extension addresses initial provisioning by centrally connecting users to approved servers through their identity provider. It does not inspect MCP traffic after the token is issued. Authentication scoring must show provisioning, endpoint enforcement, and post-token control as separate things to check.

What confirmed vulnerabilities in production reveal about score coverage gaps

In nginx-ui's CVE-2026-33032, rated CVSS 9.8, a message endpoint failed to authenticate command execution requests, allowing nginx restart and configuration modification through a missing check that a source scan focused on dangerous sinks might miss. Antiy CERT confirmed more than a thousand malicious skills across ClawHub, the marketplace for the OpenClaw AI agent framework, exposing a marketplace enforcement gap that static per-server scoring does not prevent. These are different failures of trust, even though both can sit behind a reassuring impression of prior review.

Recommendations to store secrets in insecure.env files or plaintext JSON configurations are hygiene problems that static scanning can flag. Dynamic testing can also expose the resulting risk when credentials appear in live responses, but that does not make it a substitute for inspecting storage guidance. Each method's ability to identify the failure depends on its access to the necessary evidence. A missing finding is not evidence of safety when the relevant surface was never examined.

How should enterprises enforce access policies on MCP tool calls beyond registry scores?

Enterprise governance requires five enforced layers. Each agent needs its own machine identity with a unique identifier, a named owner, a trust level that has been set, and a lifecycle that has been written down. Credentials should be scoped to the task and expire when it finishes. Audit trails need both a record of the tool call and the reasoning step the agent generated before acting. These controls make responsibility, authority, and the basis for an action visible in ways a server rating cannot.

The remaining layers govern approval and delegation. Read-only actions can run autonomously, while writes and external API calls above a cost threshold require asynchronous approval, and irreversible operations require synchronous confirmation. When agents delegate, permissions must stay the same or narrow as work passes between them. These are policies about a particular action under a particular identity.

Runlayer is one platform option for the post-token controls this split requires, with built-in OAuth and credential handling, SSO, SCIM, just-in-time credentials, and policy enforcement at tool-call depth. Its real-time detection covers tool poisoning, prompt injection, intent drift, and exfiltration, with tamper-proof audit logs and full OTEL tracing.