An MCP contract alone does not limit filesystem access

An MCP server can advertise a narrow task while running in a process that inherits much broader host access. The gap between the described function and effective capability is a security boundary that cannot be resolved by the tool schema alone.

Status: Evidence Brief approved for publication. Editorial series: Papers we read for you. This text analyzes the preprint *MCP Security at Scale*. It does not expose vulnerable servers, paths, credentials, payloads, or exploitation instructions; nor does it claim that every MCP server is insecure or that the study measured effects beyond observed responses.

The catalog is not the denominator for dynamic confirmation

The authors consolidated 21,097 servers from nine registries. They identified 17,919 open-source projects and ran local-reach measurement on 7,222 of them. After triage, 4,806 servers proceeded to deeper analysis and 4,292 received static analysis.

In 787 of the 4,806 triaged servers, or 16.4%, an L1 signal appeared: the implementation had filesystem capability, but the public description did not declare an explicit FileSystem category. This signals misalignment between contract and capability, not confirmation of exploitation or leakage.

150 instances were confirmed, without a universal rate

The pipeline dynamically confirmed 150 instances using a three-case protocol. In 136, the response contained the exact credential marker used by the researchers; in 14, there was other observable evidence. The paper provides no denominator that would justify turning the 150 confirmations into a prevalence rate across 21,097 servers, 17,919 open-source projects, or the 7,222 reached.

The correct reading is that real cases were confirmed within a pipeline-directed selection. The incorrect reading would be that an equivalent percentage of the entire ecosystem is vulnerable.

Coordinated disclosure and upstream fixes

The authors prepared 13 disclosure packages. Two flaws received CVEs and upstream fixes:

1. CVE-2025-68143 / GHSA-5cgr-j3jf-jw3v, fixed in the version identified by the advisory on September 25, 2025.
2. CVE-2026-27735 / GHSA-vjqx-cfc4-9h6v, fixed in the version identified by the advisory on January 14, 2026.

These advisories corroborate two specific occurrences. They do not validate the entire methodology or turn the remaining findings into third-party-confirmed vulnerabilities.

A tool contract is not a sandbox

Name, description, and schema help the model decide when to call a tool. They do not remove permissions from the process implementing the server. If that process inherits the user's directory, environment variables, sockets, or credentials, the real boundary is the runtime's capability set.

A minimum executable contract must separate:

1. Declared intent: what the tool promises to do and what data it expects.
2. Granted capability: files, network, processes, secrets, and identities available to the runtime.
3. Invocation policy: who may invoke it, in what context, and with which arguments.
4. Observed effect: resources actually read, written, sent, or changed.
5. Acceptance and revocation: evidence required to promote, limit, or remove the integration.

Proportional controls

• run each server with a minimal identity and directories, preferably in its own isolation boundary;
• use path and destination allowlists, denying access by default;
• inject short-lived secrets only into the call that requires them;
• validate descriptions and schemas against behavior observed in a controlled environment;
• record calls, granted capabilities, and effects without storing sensitive content;
• test updates, revocation, and rollback before allowing autonomous use;
• treat a dependency or image change as a new boundary review.

Limits and conflicts of interest

Only 34.2% of cataloged open-source projects reached local-reach measurement. After that filter, 97% of the executable sample was concentrated in Node and Python, and 84% of started servers came from a single registry. This selection limits generalization.

Capability boundaries were inferred through analysis and experiments; they are not a complete measurement of all operating-system effects. The protocol covered selected tools and sequences, used LLM judgments in parts of the pipeline, and observed disclosure through responses, potentially missing silent side effects. The macOS Seatbelt sandbox used by the researchers does not prove equivalence with other operating systems or production environments.

The authors report affiliations with the University of Illinois Urbana-Champaign, Santa Clara University, Auburn University at Montgomery, and independent work. We found no explicit funding or conflict-of-interest statement in the consulted text. By the editorial cutoff, we found no complete independent reproduction of the survey.

Architecture rule

Forge must treat MCP as third-party code with capabilities, not as a trustworthy description of intent. Promotion requires contract, identity, isolation, telemetry, and revocation to be tested together. If the process can reach a resource, that capability belongs in the threat model even when it does not appear in the tool name. [R2-C3]

Direct sources

1. MCP Security at Scale — arXiv. Preprint, authors, abstract, version, and date.
2. MCP Security at Scale — full text. Method, funnel, results, limitations, and coordinated disclosure.
3. GHSA-5cgr-j3jf-jw3v. Public advisory for CVE-2025-68143.
4. GHSA-vjqx-cfc4-9h6v. Public advisory for CVE-2026-27735.

Editorial and responsibility note

This text combines facts attributed to sources with the author's analysis and technical proposal. Personal and professional views are not proven facts; data, denominators, limitations, affiliations, and the absence of independent reproduction are stated when available. The content is informational and does not replace technical, legal, regulatory, or security assessment. MCP, projects, products, and institutions mentioned belong to their respective owners; there is no sponsorship or endorsement. No target, secret, or offensive procedure is reproduced. Tech Human and Trustyu operate commercially in digital-product development and governance. Research, structure, and writing were AI-assisted; factual review, authorial approval, and publication were authorized by Fernando Parreiras on October 16, 2026, without additional independent human review.

Research cutoff: October 16, 2026. Editorial status: special Evidence Brief authorized for October 17, 2026 at 09:00 BRT.