Topic starter
08/06/2026 4:45 pm
TL;DR: MCP Roots let clients declare URI-based workspace boundaries so servers know which resources to scope, but the article also makes clear that roots are informational rather than strictly enforced, according to WorkOS. That means identity and access controls still need to govern what tools, data, and locations an MCP server can actually touch.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Understanding Roots in Model Context Protocol (MCP)”.
Key questions
Q: What breaks when MCP roots are treated as access control?
A: The control breaks because roots only declare expected workspace context.
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.
Q: How should teams handle dynamic MCP root changes?
A: Treat every root change as a governance event, not just a context update.
Practitioner guidance
- 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.
Bottom line: MCP roots help clients describe workspace scope, but they do not enforce who or what may access the resources in that scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 6:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP roots clarify workspace scope, but not identity trust
This post was modified 3 days ago by NHI Mgmt Group