MCP Vulnerabilities and Powerful Permissions: Three Different Adoption Decisions
Command execution and file access are not automatically MCP vulnerabilities. Distinguishing intended permissions, defects that cross a boundary, and missing evidence makes the choice between updating, isolating, and investigating more precise.
Read in JapaneseThe official MCP security policy describes launching a configured command over stdio as intended behavior. A published filesystem advisory, by contrast, describes access beyond an allowed directory. Both involve an MCP touching local files; they call for different adoption decisions.
Three states that change the decision
- An intended but powerful permission may exceed what a particular task needs.
- A vulnerability crossing an allowed boundary requires checking the affected release and the publisher's fix.
- Missing inspection evidence leaves a question open; it does not establish either safety or a vulnerability.
A server that can run commands is a different proposition from an unauthorized party being able to execute commands outside the granted boundary. Start an MCP vulnerability review by identifying whose authority permits the action and what would exceed it.
A practical acceptance record
| Observed situation | Action before adoption | Evidence for acceptance |
|---|---|---|
| Editing a work directory is an intended feature | Expose only the directories required for the task | Mount configuration and OS permissions that enforce the limit |
| A known defect permits access outside the allowed directory | Stop using affected releases and apply the publisher's fix | Installed artifact version, advisory, and rejection of out-of-scope access |
| Startup or authentication prevents an observation | Retain the missing observation and arrange a bounded follow-up | Evidence for the same release and launch configuration |
For a document-organizing task, consider a separate working directory containing approved documents instead of exposing an entire home directory. A conversational instruction to stay inside that directory does not reduce the process's OS permissions. If the required isolation cannot be enforced, do not connect the server for that use case.
Isolation also should not be recorded as a software fix. Keep the release check alongside the environmental control. Conversely, a failed or incomplete inspection should not be counted as a discovered vulnerability.
Match the result to your connection
Read publisher, release, launch configuration, inspection date, and connection conditions together. A result for one configuration is not automatically evidence for another release or a broader permission grant. The inspection guide and server database provide starting points for that review.
Scope and sources
This explanation uses public material reviewed on September 22, 2026. It does not report a fresh inspection of individual servers or estimate vulnerability prevalence. The acceptance record above is an MCP Guard recommendation, not a required format in the protocol specification.