MCP roots clarify workspace scope, but not identity trust

At a glance

What this is: This is an explanation of MCP Roots and how they define client-declared resource scope in distributed systems.

Why it matters: It matters because IAM teams cannot treat declarative context as enforcement, especially when NHI, workload, or agentic access depends on precise boundary control.

👉 Read WorkOS's article on understanding MCP roots and workspace scope

Context

Model Context Protocol Roots are URI-based declarations that tell an MCP server which resources a client wants it to pay attention to. In plain terms, they are scope hints, not access controls. For identity and access teams, that distinction matters because the protocol can narrow context, but it does not itself prove who is allowed to read, modify, or invoke adjacent resources.

The governance problem is familiar across NHI and agentic systems: a declared boundary is only useful if downstream permissions, secrets, and tool access stay inside it. When context is distributed across code, APIs, and configuration stores, the security model has to separate what the client names from what the server can actually reach. The same principle applies whether the subject is a workload, service account, or AI agent.

Key questions

Q: How should security teams govern MCP roots in distributed systems?

A: Security teams should treat MCP roots as declared context, not as access control. Every root must map to explicit permissions, secrets, and audit boundaries outside the protocol. If a server can still reach adjacent resources after a root change, the governance model is too loose and should be tightened at the identity and tool layer.

Q: Why do MCP roots matter for NHI governance?

A: MCP roots matter because they define where a server should focus, but NHIs such as service accounts, tokens, and workload identities can still reach beyond that boundary if their entitlements are broader than the declared context. The risk is entitlement drift, where the session looks scoped but the underlying identity is not.

Q: What breaks when a server treats a root as a security boundary?

A: What breaks is the assumption that naming a workspace is the same as enforcing it. A root can narrow context, but it cannot prevent a server from using inherited permissions, cached access, or adjacent API reach. That creates a false boundary that may be visible in logs but not in actual control.

Q: How do I know whether MCP scope is actually working?

A: You know scope is working only when the server cannot resolve or act on resources outside the declared roots, even if those resources are technically reachable through other credentials. Test for stale context, cross-root reads, and tool access that survives workspace changes. If those appear, the scope model is only advisory.

Technical breakdown

MCP roots as URI-scoped context declarations

In MCP, a root is a URI that marks the resources a client wants a server to consider during a session. That can be a filesystem path, an API endpoint, or another valid URI, which makes roots flexible but also inherently declarative. The client announces support for roots, sends the URIs, and can update them as the working context changes. The server then uses those hints to narrow search, resolution, and operating scope. The key technical point is that roots describe context boundaries, not access enforcement, so they are only as strong as the permissions behind them.

Practical implication: treat roots as scoping metadata and verify that the server’s real permissions cannot exceed the declared boundary.

Why root changes create governance drift

Roots can change dynamically when a user switches projects or when an application rebinds its operational context. That introduces governance drift if the server retains stale scope, caches old resource paths, or continues resolving objects outside the current root set. In distributed systems, stale context is often the first step toward overreach because the server may still have valid credentials even after the client’s working boundary has shifted. In identity terms, the risk is not the root itself, but the mismatch between declared scope and effective entitlement.

Practical implication: expire or revalidate contextual access whenever roots change so old resource paths do not remain reachable.

Roots are not the same as authorization

A root tells a server where to begin, but authorization decides whether the server may actually act on the resource. That separation is critical in MCP because a valid URI can point at sensitive data, internal APIs, or configuration state that should remain inaccessible outside a narrow purpose. If teams mistake contextual declarations for policy, they create a false sense of containment. The protocol works best when root scoping is paired with explicit permission boundaries, secret containment, and audited tool access.

Practical implication: enforce authorization and secret boundaries independently of MCP root declarations, especially for high-value internal APIs.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Roots are a context primitive, not a trust primitive. MCP gives clients a structured way to tell servers what part of a workspace matters, but that does not establish who should be trusted to act on it. The useful mental model is boundary declaration versus boundary enforcement. Practitioners should stop reading URI scope as proof of safe access, because the protocol itself does not supply that guarantee.

Declarative context is weaker than entitlement control: the same root can point to code, secrets, or live APIs, and each of those resources needs different access treatment. That means one MCP session can look neatly bounded while still carrying broad practical reach through inherited credentials or tool permissions. The implication is that access policy must be evaluated below the context layer, not assumed from it.

Root drift is a governance problem, not just a runtime nuisance. When clients switch projects or update context dynamically, any stale server state becomes latent overreach. That pattern maps directly to NHI governance failures where scope outlives intent. The practitioner takeaway is to treat changing roots as a lifecycle event that demands renewed control over credentials, tool scope, and audit state.

MCP makes the gap between declared and effective scope more visible. That visibility is useful because it exposes where distributed systems rely on conventions instead of enforcement. In identity programmes, the same pattern appears when service accounts or agents are given broad standing reach and are expected to self-limit by context. The discipline needed here is to align declared roots with explicit authorization boundaries, otherwise the workspace boundary is only cosmetic.

For autonomous workflows, the root concept becomes an assumption test. If an agent can select tools and timing independently, the question is no longer whether the client declared a root, but whether the governance model can constrain action when the runtime path changes. That makes MCP roots a useful warning signal for agentic design: context can be named, but intent can still drift beyond it. Practitioners should read this as a signal to harden enforcement where declaration ends.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• See Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, over-privilege, and secret-sprawl patterns that make scoped context hard to enforce.

What this signals

Root declarations will become more important, but they will not reduce the need for hard identity controls. As MCP adoption spreads, teams should expect more systems to advertise clean contextual boundaries while still relying on broad underlying credentials. The programme risk is that governance teams mistake a neat URI map for a real permission model, which leaves service accounts and agentic access under-controlled.

Context scoping is emerging as a named design pattern: the practical value of MCP roots is not containment by itself, but forcing teams to declare where a session starts. That makes the hidden problem easier to see, especially where internal APIs or shared repositories sit just outside the declared boundary. IAM teams should use this pattern to audit whether their enforcement model actually tracks the declared workspace.

The most relevant external control lens here is Zero Trust, because the protocol’s own documentation already separates description from enforcement. When client intent changes, the server should not assume continuity of trust. Teams that run MCP-backed workflows should look for places where OWASP Non-Human Identity Top 10 risks and contextual scope drift overlap.

For practitioners

• Separate context from access control Map every MCP root to the permissions, secrets, and tools that the server can actually use. Do not let declarative scope stand in for authorization decisions, and verify that each root is backed by least-privilege access enforced outside the protocol boundary.
• Revalidate access when roots change Treat root updates as a lifecycle event. If a client switches projects or replaces a workspace URI, revoke or re-scope the server’s reachable resources immediately so stale context does not keep old paths, APIs, or config locations alive.
• Constrain tool reach to the declared workspace Bind tool permissions to the current root set and log any attempt to resolve resources outside that set. For MCP servers touching sensitive APIs or config stores, add explicit deny rules for adjacent locations that look valid but fall outside the declared boundary.
• Review NHI credentials behind MCP services Inventory the service accounts, tokens, and certificates used by MCP-connected services, then confirm they cannot outlive the workspace context they were granted for. This is especially important when roots point to internal APIs or shared repositories.

Key takeaways

• MCP Roots define where a server should focus, but they do not by themselves enforce access boundaries.
• The governance risk is mismatch, where declared workspace scope is narrower than the identity’s real entitlement.
• Teams should bind authorization, secrets, and audit controls to the current root set, not to the protocol declaration alone.

Key terms

• MCP Root: A root is a URI that tells an MCP server which workspace or resource boundary a client wants it to consider. It is a contextual hint, not a security policy. In practice, roots help narrow resolution and orchestration, but they do not replace entitlement checks or secret containment.
• Context Declarations: Context declarations are client-provided signals that describe the operational scope of a session. They improve coordination by telling the server what matters now, but they remain informational unless backed by explicit authorization and audit controls. In identity programmes, they must be treated as metadata, not trust.
• Entitlement Drift: Entitlement drift occurs when an identity retains more reach than the current task, workspace, or lifecycle state justifies. The scope may look correct at the application layer while the underlying account, token, or certificate can still touch adjacent resources. That mismatch is a common source of overreach.
• Root Drift: Root drift is the gap between the current declared workspace boundary and the server’s effective reach after a context change. It often appears when clients switch projects or update URIs but the server still resolves old paths or retains cached permissions. The result is stale access that outlives intent.

Deepen your knowledge

MCP Roots, scoped access, and NHI boundary control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around distributed workspace declarations, it is worth exploring.

This post draws on content published by WorkOS: Understanding Roots in Model Context Protocol (MCP). Read the original.