Because Roots was the structural boundary that limited which local paths an agent could reach. Without it, scope becomes opt-in per server, so sensitive directories can be reachable even when the task does not require them. That makes scope enforcement a server obligation rather than a protocol guarantee.
Why Roots Was More Than a Convenience Flag
Roots was acting as the protocol-level boundary that separated the agent’s intended working area from the rest of the local filesystem. That matters because a filesystem boundary is not just a usability feature, it is a governance control: it defines what the agent can even ask for, not only what it should ideally avoid. When that boundary disappears, the control shifts from protocol enforcement to server discipline.
In practice, that changes the security model from “the protocol constrains access by default” to “each server must correctly police its own scope.” For an AI agent, that is a meaningful reduction in assurance because the agent’s reach becomes dependent on per-server configuration, server quality, and how consistently teams interpret the scope rule.
One useful way to think about this is that Roots was providing protocol boundary guidance for MCP deployments, while the absence of that boundary makes the server the last line of control. If the server is misconfigured, over-permissive, or simply inconsistent across environments, the agent can gain path access that the task itself did not require.
What Changes When Scope Becomes Opt-In Per Server
With Roots removed, scope is no longer structurally inherited by the protocol flow. Each server must explicitly define which paths it will expose, and that is easy to get wrong when multiple tools, servers, or environments are involved. The result is not just broader access, but broader ambiguity: reviewers now have to inspect server configuration, path mapping, and local trust assumptions instead of relying on a common protocol constraint.
This also creates a mismatch between intent and reach. An AI agent may be authorised for a task, yet still be able to browse directories that contain credentials, project data, source code, or operational files because the server granted access too broadly. That is why the problem is governance-related, not merely technical, because it weakens the default rule that access should be narrowly bounded by purpose.
The issue is especially visible in agentic systems where delegated tool access can expand quickly. NHIMG’s AI Agent Authorisation Guide is relevant here because it shows why task-scoped and just-in-time access work better than standing, server-wide permissions. Zero Trust for AI Agents reinforces the same point: verify each request and remove standing privilege rather than assuming the surrounding server boundary is enough.
Why This Becomes a Filesystem Governance Problem, Not Just a Security Bug
The governance problem is that path access is now distributed across implementation choices instead of being anchored in a protocol guarantee. That makes it harder to answer basic questions such as who approved the access, which directories were exposed, whether access was task-bounded, and how a reviewer can prove the server did not overreach.
Once the boundary is opt-in, assurance depends on configuration hygiene and operational consistency. A team may believe it has limited an agent to a narrow working set, while the server quietly exposes parent directories, shared mounts, or adjacent paths. In that situation, the file system itself becomes a policy surface, and policy drift is much easier to introduce than to detect.
That is why the risk grows when agents interact with local development environments, build systems, or shared workspaces. NHIMG’s AI Coding Agents Security Guide is a useful analogue because it shows how over-scoped local access, secrets in context, and weak sandboxing create the same pattern of unbounded reach. The underlying lesson is that filesystem access must be explicitly bounded, observable, and reviewed as a control, not treated as an incidental implementation detail.
Risk and Threat Considerations
Removing Roots increases the chance that an agent will reach sensitive files through configuration drift, server mis-scoping, or over-broad local mounts. The danger is not only accidental exposure, but also adversarial abuse if a compromised or malicious agent can read material that was never needed for the task.
Failure mechanism: The protocol no longer enforces a default local-path boundary, so a permissive or inconsistent server can expose directories that should have remained outside the agent’s working scope.
Impact: Sensitive files can become readable without a direct task justification, expanding blast radius, weakening least privilege, and increasing the chance of credential, code, or data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Roots removal changes path exposure and privilege scope for agent file access. |
| Recommendation — Limit each server and agent to the minimum filesystem paths needed for the task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer centers on verifying each access request and not trusting a default boundary. |
| Recommendation — Enforce per-request path checks and remove standing filesystem trust assumptions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Opt-in scope per server can create broad function-like access beyond intended task boundaries. |
| Recommendation — Map each file-access function to explicit authorization checks before exposing paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Filesystem governance depends on controlling who and what can access local paths. |
| Recommendation — Review and restrict server path access on a least-privilege basis. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is fundamentally about governing access to filesystem resources. |
| Recommendation — Define and enforce access rules for agent-visible paths and server scope. | ||
Practitioner Guidance
What to verify: Confirm that each MCP server explicitly enumerates the directories it exposes, and test whether the agent can traverse above the intended working tree or reach sibling paths. If the answer is unclear, treat that as a control failure rather than a documentation gap.
Common mistake: Teams often assume that task intent is enough to constrain file access. It is not. If the server can reach a directory, the agent can usually reach it too, so the real control is the server’s scope enforcement and not the user’s expectation.
What good looks like: The agent only sees the minimum filesystem paths required for the job, access is reviewed per server and per environment, and any exception has a named owner and expiry. Where possible, pair narrow path scope with sandboxing and logging so you can prove what was reachable during execution.
Practitioner takeaway: Treat Roots as a control boundary, not a convenience feature. Once you remove it, you must replace that boundary with explicit path scoping, reviewable server policy, and a clear answer to what the agent can reach if the server is misconfigured.