Treat MCP servers as privileged local services and restrict what they can read. Run them only on trusted hosts, bind them to localhost, and scope file access to approved directories. Do not assume local means safe. If the service can process user-controlled paths, a malicious local process may turn that into arbitrary file read, credential theft, and broader compromise.
Why This Matters for Security Teams
MCP servers on developer machines are not just convenience tooling. They are local services with access to code, secrets, configs, and sometimes cloud credentials that developers keep within reach. When a server can follow user-controlled paths or read broadly from disk, the attack surface shifts from “tooling issue” to “local data exfiltration and identity theft.” That is why guidance from the OWASP Top 10 for Agentic Applications 2026 matters here: local trust does not equal safe trust.
This is also consistent with NHIMG research on MCP exposure, where The State of MCP Server Security 2025 found 24,008 unique secrets exposed in MCP configuration files in 2025 alone. The practical lesson is simple: if an MCP server can inspect arbitrary files, it can become a shortcut to tokens, SSH material, environment files, browser profiles, and developer notes. In practice, many security teams discover that local file exposure only after a secret has already been copied out of a workstation.
How It Works in Practice
The safest pattern is to treat each MCP server as a privileged local service with a narrow file system contract. Bind it to localhost, run it only on trusted developer hosts, and scope access to specific approved directories rather than the entire home folder or workspace tree. Current guidance suggests that the allowlist should be explicit and small, because “read-only” is not a meaningful control if the read target can be attacker-influenced.
For filesystem safety, teams usually combine three layers:
- Path allowlisting for exact directories, not broad glob patterns.
- Symlink and path traversal defenses, so a permitted path cannot resolve outside the intended boundary.
- Process separation so the MCP runtime does not inherit unnecessary shell history, browser sessions, or cloud credentials.
Where possible, pair file limits with a stronger identity model for the service itself. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege and controlled information flow, which maps well to MCP hardening. For broader NHI context, NHIMG’s Guide to the Secret Sprawl Challenge shows why configuration files and local caches are frequent leakage points, especially when tools auto-load secrets from developer environments.
Operationally, teams should test the server against malicious local input, including crafted paths, symlinks, and files that point into hidden credential stores. These controls tend to break down when the server runs on unmanaged developer laptops with broad home-directory permissions, because the machine itself becomes the trust boundary rather than the service.
Common Variations and Edge Cases
Tighter file scoping often increases developer friction, so organisations have to balance usability against exposure reduction. That tradeoff becomes sharper in multi-repo setups, remote development containers, and machines that mix personal and corporate data, because legitimate workflows may need access to more than one project root.
Best practice is evolving for these edge cases. Some teams isolate MCP servers inside dev containers or ephemeral VMs so the “local” filesystem is already constrained. Others enforce separate profiles for code, secrets, and browser data so a compromise of one context does not automatically expose all three. The same principle appears in NHIMG’s Analysis of Claude Code Security, which highlights how agent-adjacent tooling can magnify local trust mistakes.
There is no universal standard for local MCP file policy yet, but the direction is clear: minimize readable surface area, constrain runtime identity, and assume a developer workstation will eventually host untrusted inputs. Where teams have not defined a directory boundary, the default usually becomes “anything the user can reach,” which is far broader than most security teams intend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic tools must not inherit broad local file access by default. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Local services reading secrets create non-human identity exposure risk. |
| CSA MAESTRO | AM-03 | Workload isolation and least privilege are core to safe MCP deployment. |
| NIST AI RMF | AI risk management requires controlling data access paths for tool-using systems. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits implicit trust in local developer machines and services. |
Restrict MCP server reads to explicit paths and validate every user-controlled file reference.
Related resources from NHI Mgmt Group
- How should security teams reduce npm and PyPI supply chain risk on developer machines?
- What should teams do when MCP servers are running on developer laptops?
- How should security teams reduce the risk of developer secrets stored in local .env files?
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?
