MCP Roots Need a File Access Review

An MCP root is not a harmless project picker.

It is the file boundary a server can see.

Short answer

Treat MCP roots as filesystem access. Before approving a root, review the exact path, why the server needs it, whether a smaller path works, what sensitive files live under it, whether untrusted files can become model context, which resources can be read, which tools can act on those files, whether any tool can communicate externally, how path traversal is blocked, how root changes are monitored, and where the decision is logged. If the root is a home directory, synced drive, broad repo folder, or unknown bundle of files, narrow it before enabling the server.

What MCP roots actually expose

The MCP roots specification describes roots as a standard way for clients to expose filesystem roots to servers. The spec says roots define the boundaries of where servers can operate in the filesystem. Servers can ask supporting clients for the root list, and roots are represented as file:// URIs.

That sounds simple.

It is also easy to approve too much.

A root can be a single project directory. It can also be multiple repositories. In a badly reviewed setup, it can become a broad parent folder that includes secrets, local notes, customer exports, build artifacts, logs, and old repos that the workflow does not need.

The spec already points at the right control shape. Clients must only expose roots with appropriate permissions, validate root URIs to prevent path traversal, implement access controls, and monitor root accessibility. Servers should respect root boundaries and validate paths against provided roots. Clients should also prompt users for consent before exposing roots.

That is a file access review.

Not a vibe check.

Roots become sharper when resources are involved

MCP roots matter because files can become context.

The MCP resources specification says resources let servers share context with language models, including files, database schemas, and application-specific information. It also describes host-driven resource use, including explicit selection, search and filtering, and automatic context inclusion based on heuristics or model selection.

That last part is where the risk shows up.

If a root contains only the workflow's project files, the blast radius is easier to explain. If it contains a whole home directory, a shared drive, or a parent folder full of unrelated repos, the resource boundary gets muddy fast.

A builder should be able to answer:

• Which files under this root can become resources?
• Can the user explicitly select them, or can the client include them automatically?
• Can the model select resources from the root?
• Are generated files, logs, exports, caches, or local notes included?
• Are secrets and private records excluded by policy and by enforcement?

If those answers are unclear, the root is too broad.

Roots can carry indirect prompt injection

Files under a root are not all trusted just because they are local.

A repo can include a malicious README. A downloaded HTML file can include hidden instructions. A generated issue export can include prompt text. A PDF can tell the agent to ignore its rules. A test fixture can be copied from an untrusted bug report.

OWASP LLM01: Prompt Injection describes indirect prompt injection as malicious or unintended instructions from external sources such as websites or files. OWASP lists potential impacts that include sensitive information disclosure, unauthorized function access, arbitrary commands in connected systems, and manipulation of critical decisions.

That maps cleanly to MCP roots.

The root review should separate file classes:

Trusted project files:
Generated files:
Downloaded files:
Customer or user-provided files:
Docs copied from external systems:
Secrets and config files:
Logs and exports:

The safer pattern is to narrow the root to the files the workflow needs, then treat untrusted files as data. Do not let untrusted files expand context, change tool permissions, or steer approval prompts.

Roots meet tools

Roots get more dangerous when tools can act on what the server sees.

The MCP tools specification says tools are model-controlled, meaning the model can discover and invoke tools based on context and the user's prompt. The same spec says there should always be a human in the loop with the ability to deny tool invocations. It also says clients should show tool inputs before calling the server to avoid malicious or accidental data exfiltration, validate tool results, enforce timeouts, and log tool usage.

That is the missing connection in many MCP reviews.

A root by itself gives a boundary. A tool decides what can happen after file context is available.

For example:

• A read-only root plus a summarization resource is lower risk.
• A project root plus a file write tool needs review.
• A project root plus a network or message-sending tool needs a stronger review.
• A home directory root plus a shell, browser, database, or outbound API tool is a bad default.

The question is not only, "Can the server see this folder?"

It is, "What can the workflow do after this folder is visible?"

Local MCP servers make the review more important

The official MCP security best practices are blunt about local server risk. Local MCP servers run on the user's machine and may have direct access to the user's system. The guidance calls out risks such as malicious startup commands, malicious server payloads, insecure local servers, arbitrary code execution, data exfiltration, and data loss.

The same guidance recommends showing the exact local server command before execution, warning on sensitive locations such as home directories and SSH keys, sandboxing local servers, restricting filesystem and network access, and requiring explicit grants for additional privileges such as specific directory access.

That is the right mental model for roots.

Do not approve a root as if the MCP server is just reading a nice project tree. Review it as a local integration running with real system access and real downstream tool paths.

Sensitive files need a default deny rule

OWASP LLM02: Sensitive Information Disclosure lists sensitive information categories that matter for root review:

• Personal identifiable information
• Financial details
• Health records
• Confidential business data
• Security credentials
• Legal documents

For MCP roots, that should become a default deny class.

Block or isolate paths that include:

• .ssh, .aws, .kube, .gnupg, .docker, .npmrc, .pypirc, .netrc, and credential stores
• .env files and local config with tokens
• Customer exports and support transcripts
• Legal, finance, health, and HR records
• Browser profiles and cookies
• Private notes and unmanaged synced folders
• Logs that may contain credentials or personal data
• Old repos with unknown secrets or stale config

Prompt rules are not enough here. OWASP notes that restrictions about what data an LLM should return may not always be honored and can be bypassed through prompt injection or other methods.

The control should be structural: do not put sensitive files under the approved root unless the workflow has a specific, reviewed reason.

Roots can feed excessive agency

OWASP LLM06: Excessive Agency frames the root problem well. Excessive agency comes from too much functionality, too many permissions, or too much autonomy. OWASP recommends minimizing extensions, minimizing extension functionality, avoiding open-ended extensions, minimizing permissions, requiring approval, and using complete mediation.

A broad root can create excessive agency without looking like a tool permission.

The tool might say "read project files," but the approved root quietly defines what "project" means. If the root points at a broad parent folder, the agent's readable world just expanded.

The safer pattern is:

1. Start with the smallest root.
2. Exclude sensitive paths by default.
3. Require explicit user approval for root expansion.
4. Review resources separately from tools.
5. Require separate approval for writes and external communication.
6. Log root changes and high-risk file access.

The MCP root review record

Before approving an MCP root, write this down:

MCP client:
MCP server:
Workflow using the server:
Root path:
Why this root is needed:
Smaller root possible:
Sensitive file classes present:
Untrusted file classes present:
Can files become resources:
Can resource inclusion be automatic:
Tools that can read files:
Tools that can write files:
Tools that can communicate externally:
Path traversal validation checked:
Root change monitoring:
Default decision if unclear:
Log location:
Owner:
Review date:

If a team cannot fill this out, it probably cannot explain the file boundary.

Deny or narrow these roots

Deny or narrow an MCP root when:

• The root is the user's home directory
• The root is a whole synced drive or document folder
• The root includes secrets, credentials, or private key material
• The root includes legal, financial, health, HR, or customer data unrelated to the workflow
• The root includes untrusted downloads or generated content that can reach the model
• The root includes old repos with unknown secret history
• The server can write files under the root without a separate approval gate
• A tool can read from the root and communicate externally in the same path
• The client cannot show root changes or log who approved them
• The server cannot prove it validates paths against the root boundary

This is not about blocking MCP.

It is about refusing to turn "select a project" into "approve my filesystem."

Evidence versus opinion

Evidence from the sources:

• The MCP roots specification defines roots as filesystem boundaries exposed by clients to servers.
• The roots spec requires clients to expose roots with appropriate permissions, validate root URIs, implement access controls, and monitor accessibility.
• The resources spec says resources can provide files, database schemas, and application-specific information as model context.
• The tools spec says tools are model-controlled and calls for human-deniable tool invocations, visible tool inputs, result validation, timeouts, and audit logs.
• MCP security best practices warn about local MCP server compromise risk and recommend sandboxing, restricted filesystem and network access, exact command visibility, and explicit extra privilege grants.
• OWASP LLM01 frames indirect prompt injection as coming from external sources such as files.
• OWASP LLM02 defines sensitive information categories and warns that prompt restrictions can be bypassed.
• OWASP LLM06 frames excessive agency as too much functionality, permission, or autonomy.

My opinion:

MCP roots should be reviewed like file access. The smallest useful root should be the default. Broad roots should require a named reason, sensitive-file exclusions, separate tool approval, and a log.

If the root includes private data and the server also has tools that can write or communicate externally, treat that as a high-risk agent workflow.

Free next step

Test one MCP server you use. List every root it can see, then fill out the review record above. If the server can also use tools, compare the result against the MCP permission review, the MCP sampling approval gate, the MCP elicitation sensitive data gate, and the lethal trifecta test before you leave the root enabled.