No. MCP roots tell a server which directories the client considers relevant, but the spec calls them informational guidance rather than an access-control mechanism, and the protocol does not enforce that servers stay inside them. To limit file access you need operating system or sandbox controls.
What roots are
A root is a file URI, such as a project folder, that the client shares with a server so the server can focus its work. A workspace picker in an editor is a typical source. The server can ask for the list and use it to decide where to look.
Nothing in that exchange stops a local server process from opening other paths. A server that runs as your user has your user's file access, whatever it was told about roots.
What the spec asks of each side
For clients, the draft says they must expose only roots with appropriate permissions, validate root URIs to prevent path traversal, implement access controls and monitor root accessibility. They should ask for consent before sharing roots.
For servers, it says they should respect root boundaries and validate paths against the roots they were given. That is a request for good behaviour, not a lock.
Roots versus real controls
| Question | Roots | Sandbox or OS permission |
|---|---|---|
| Tells the server where to focus | Yes | No |
| Stops a read outside the folder | No | Yes |
| Works against a malicious server | No | Yes, if configured well |
| Needs the server to cooperate | Yes | No |
If a server is not trusted, roots give you nothing. If it is trusted, roots are a convenience that also reduces accidents.
How to actually limit file access
- Run local servers in a container or application sandbox with only the needed folder mounted.
- Mount read only when the task does not need to write.
- Keep home directories, SSH keys and cloud credentials out of the mount.
- Use a dedicated low privilege user for server processes where you can.
- Log file operations so an unexpected read stands out.
Status note
The draft marks roots as deprecated as of protocol version 2026-07-28. It suggests passing directories or files through tool parameters, resource URIs or server configuration instead. Either way, the rule is the same: configuration and sandboxing decide access, not a hint sent over the protocol.
Safeguard includes asset discovery and agent identity, which help you see which agents and servers exist before you decide what to sandbox. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Can a client ignore roots?
Yes. Clients decide what to share, and the protocol says roots are guidance. A server can also ignore them.
Is a read only root possible?
Roots carry a location and a name, not a permission. Read only access has to come from how the server is run, such as a read only mount.
Sources
Last reviewed: 19 October 2026.
