What is the difference between MCP roots and authorisation policy?

How MCP roots differ from authorisation policy

MCP roots and authorisation policy answer different questions in the trust model. A root is a declared starting point or scope hint for the client, while authorisation policy is the server’s control over whether a request may actually touch a resource. That separation matters because a root can guide intent without granting access.

A useful way to think about it is that roots shape navigation and policy shapes permission. The root tells the server where the client is trying to work, but the policy decides whether the server can safely read, resolve, or act on anything in that workspace. In a secure design, the policy is always authoritative.

This distinction is especially important when a client can present paths, workspace names, or other scope declarations that look legitimate but are broader than the user’s actual entitlement. The server must treat the root as input, not proof. If the two are conflated, the client can appear correctly scoped while still reaching material it should not.

Why the separation exists in practice

Root declarations are useful for user experience, routing, and narrowing the working context. They help the client and server agree on the area of interest, but they do not replace server-side authorisation. The server still has to check the identity, request context, and resource policy before disclosing content or performing an operation.

That design prevents a common access-control mistake: assuming that a client’s declared workspace implies entitlement to every file, object, or tool within that workspace. In well-implemented systems, the root may influence which resources are considered, but authorisation policy decides which of those resources are actually available. This is the same security principle that keeps policy enforcement separate from user-supplied hints in other protocol layers.

For practitioners, the key implication is that a root can be valid and still insufficient. A request can originate from the right root and still fail policy checks because the server must evaluate ownership, tenancy boundaries, delegated permissions, or operation-specific rules before any read or write happens.

What breaks when roots are treated like permission

When a server trusts the root too much, the failure is usually overreach rather than obvious bypass. The most common mistakes are resolving paths outside the intended boundary, exposing metadata that should stay hidden, or allowing operations because the workspace “looks right.” These errors often appear first as excessive visibility, then become direct access issues.

Another failure mode is confused deputy behaviour. The client may be authorised to ask for a root, but not to use that root to reach every underlying resource. If the server resolves requests on the client’s behalf without enforcing its own policy, the client can indirectly obtain data or perform actions beyond its entitlement. That is why root handling and authorisation checks must be separately testable.

In operational terms, the difference shows up in audit and incident response. If root declarations and policy decisions are not recorded distinctly, teams will struggle to explain why a resource was accessible, who approved it, and whether the server or the client made the final decision. Separation also makes it easier to spot policy regressions when a new root expands the reachable surface.

Risk and Threat Considerations

The main risk is treating a convenience scope as a security boundary. If the server uses the root as a shortcut for entitlement, a client can gain unintended read or action paths inside the workspace, especially where path resolution, delegation, or shared workspaces are involved.

Failure mechanism: The server accepts the root as proof of access, then resolves or executes requests without independently checking whether the caller is allowed to reach the specific resource or operation.

Impact: Unauthorized data exposure, cross-workspace access, overbroad tool execution, and weak auditability follow because the policy decision is no longer distinct from the client’s declaration.

Practitioner Guidance

What to verify: Confirm that root handling, path resolution, and authorisation are separate code paths with separate tests. A request should still fail when the root is valid but the caller lacks permission for the target resource or operation.

Decision rule: If the resource can be read, resolved, or modified only because a client named the right root, treat that as a control failure. The server should evaluate policy on the final resolved resource, not on the declaration alone.

Practitioner takeaway: Use roots for scoping and usability, but never as an entitlement signal, the security decision must always happen at the server, on the actual resource and action.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?