Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: Understanding Roots in Model Context Protocol (MCP)
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Separate context from access control Map every MCP root to the permissions, secrets, and tools that the server can actually use.
- Revalidate access when roots change Treat root updates as a lifecycle event.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- JSON examples showing how clients declare one or more roots in an MCP session.
- Developer guidance on handling dynamic root changes when users switch projects or configurations.
- Practical examples of filesystem, API, and repository roots used in real deployments.
- Implementation-oriented advice on how servers should resolve resources within declared scope.
👉 Read WorkOS's article on understanding MCP roots and workspace scope →
MCP roots and workspace boundaries: what IAM teams should watch?
Explore further
08/06/2026 6:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP roots clarify workspace scope, but not identity trust
