MCP roots clarify workspace scope, but not identity trust

At a glance

What this is: This is an explanation of MCP roots, showing that they help define workspace boundaries and resource scope but do not themselves enforce identity trust or access control.

Why it matters: IAM and NHI teams need to treat roots as context, not authorisation, because scoped discovery still depends on separate controls over what tools, data, and locations an MCP server can touch.

Context

Model Context Protocol roots are URI-based hints that tell a server which workspace or resources a client wants it to pay attention to. In practice, that means they shape scope and navigation, not trust decisions.

The governance gap is straightforward: a boundary declaration can improve clarity, but it does not prove the server is allowed to access the underlying resources. That distinction matters for MCP deployments because tool access, data access, and location scope still need independent control.

For identity programmes, this is an NHI problem first and an application-integrated trust problem second. Roots reduce ambiguity about context, but they do not replace authentication, authorisation, or lifecycle governance for the credentials and tokens that let the server act.

Key questions

Q: What breaks when MCP roots are treated as access control?

A: The control breaks because roots only declare expected workspace context. They do not authenticate the client, authorise the server, or prove that the server should access the resources inside that scope. Practitioners need separate policy enforcement for files, APIs, and other locations the server can touch.

Q: Why do MCP tunnels still require IAM and NHI controls?

A: MCP tunnels solve the connectivity problem, but they do not decide who can reach which tools or how long that access should remain valid. IAM and NHI controls are still needed to manage authorization, ownership, revocation, and auditability. Without them, a secure transport can still carry over-privileged AI access into sensitive systems.

Q: How should teams handle dynamic MCP root changes?

A: Treat every root change as a governance event, not just a context update. Recheck entitlements, validate the credentials the server is using, and confirm that access to prior projects or environments has been removed where it is no longer needed.

Q: What is the difference between MCP roots and authorisation policy?

A: MCP roots describe where the client wants the server to focus. Authorisation policy decides whether the server can actually read, resolve, or operate on the resources in that workspace, and that decision must be enforced independently of the root declaration.

Technical breakdown

What MCP roots do in request scoping

A root is a URI that represents a location or context the client wants the server to consider during an MCP session. The server uses those declarations to narrow discovery, resolution, and resource selection so it does not operate as if every connected system were globally relevant. This is useful in distributed environments where local files, remote APIs, and configuration stores all matter at once. But the mechanism is descriptive, not coercive. Roots help the server understand the workspace boundary, yet they do not themselves grant access to the resources inside that boundary.

Practical implication: Treat roots as a scoping signal and enforce authorisation separately for every tool, data source, and endpoint the server can reach.

Why informational scope is not the same as trust

MCP roots can tell a server where a client expects it to operate, but they cannot prove the server should be trusted to act there. That distinction matters because the server may still hold credentials, tokens, or delegated access that extend beyond the declared roots. In other words, scope declaration reduces ambiguity, while identity governance determines what the actor is actually allowed to do. This is the same pattern seen in many NHI architectures: context hints improve coordination, but they do not replace authenticated identity, least privilege, or offboarding control.

Practical implication: Separate workspace declaration from access approval so the MCP server’s effective permissions remain bounded by policy, not by client hints.

How dynamic roots affect operational control

The article notes that roots can change as users switch projects or configurations. That creates a moving scope boundary, which is useful for coordination but risky if teams assume the latest declared root automatically constrains the server’s entire privilege set. In an MCP environment, the control plane must therefore track both the declared workspace and the credentials used to operate within it. If roots move but authorisation does not, the server may retain access paths that no longer match the intended workspace, creating residual reach across projects or environments.

Practical implication: Bind root changes to access review and credential validation so scope updates do not leave stale access paths in place.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Roots are a coordination primitive, not a trust primitive: The article correctly frames MCP roots as declarative scope markers, but that should not be confused with enforcement. Workspace boundaries help clients and servers agree on context, yet they do not establish whether a server can safely or legitimately act on the resources inside that context. Practitioners should treat the boundary as a routing aid and nothing more.

Context without authorisation creates a false sense of containment: MCP deployments can look disciplined because the server is told where to operate, but the real control question is whether it is permitted to operate there at all. That distinction is central to NHI governance, where capability hints often outpace access governance. The practical implication is to separate declared scope from effective privilege in every MCP integration.

Declarative boundaries do not solve identity lifecycle: Roots may change as projects shift, but credentials and delegated access can outlive the context that originally justified them. That means offboarding, rotation, and entitlement review remain necessary even when workspace scoping is well defined. Practitioners should assume that scope drift and privilege drift are related until proven otherwise.

Workspace scope becomes an identity issue as soon as the server can act: Once an MCP server can read files, query services, or resolve configuration, the question is no longer just where the workspace begins. It is who or what is authorised to cross that boundary on behalf of the client. The answer belongs in IAM and NHI controls, not in the root declaration itself.

Root-based design sharpens the case for explicit MCP authorisation controls: Declarative scope works best when paired with server-side checks that validate each resource request against policy. Without that second layer, roots are only a coordination convention. Practitioners should read this as evidence that MCP governance has to be built around authorisation, not inferred from context metadata.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.

What this signals

Scope metadata is not a substitute for trust enforcement: MCP roots can make distributed systems easier to coordinate, but teams should not let descriptive boundaries stand in for authorisation. The immediate programme question is whether server-side checks exist for every resource class the MCP layer can reach.

Declarative workspace boundaries increase the need for lifecycle discipline: When roots change often, entitlement review and credential governance have to keep pace. Otherwise, the server’s real access footprint will drift away from the workspace the client thinks it has declared.

For practitioners

• Map roots to explicit authorisation decisions Document which MCP roots are informational only and which server-side policies actually govern file, API, and configuration access within each declared workspace.
• Review delegated credentials behind each server Inventory the tokens, service accounts, and other NHI credentials an MCP server uses so the permissions match the declared root scope and nothing broader.
• Reconcile root changes with lifecycle controls When a client switches projects or roots change dynamically, trigger entitlement review, credential validation, and offboarding checks for stale access paths.
• Enforce resource-level checks at the server Require the MCP server to validate each request against policy before reading local files, calling APIs, or resolving configuration outside the minimal allowed scope.

Key takeaways

• MCP roots help clients describe workspace scope, but they do not enforce who or what may access the resources in that scope.
• The practical risk is a mismatch between declared context and effective privilege, especially when servers hold tokens or service account access beyond the root.
• Teams should pair root declarations with server-side authorisation, entitlement review, and NHI lifecycle controls so scope stays aligned with access.

Key terms

• MCP Root: MCP Root is the top-level trust anchor for a Model Context Protocol deployment. It defines which servers, tools, and policy boundaries an AI agent can rely on. In practice, it is the authoritative control point for identity, authorization, and session trust across MCP-connected workflows.
• Workspace Scope: Workspace scope is the set of files, services, or configuration locations an MCP interaction is meant to touch. In practice, it is a coordination boundary, not a security boundary, because the effective permissions still come from identity and policy enforcement.
• Informational Boundary: An informational boundary is a declared limit that helps systems organise behaviour without forcing compliance. In MCP, roots act this way: they guide the server, but they do not prevent the server from reaching beyond the declared context if policy is not independently enforced.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.