Topic starter
08/06/2026 4:34 pm
TL;DR: MCP’s six core features split into server-side capabilities and client-side controls, with Tools, Resources, Prompts, Sampling, Roots, and Elicitation shaping how models act on external systems, according to WorkOS. The governance question is not whether MCP is useful, but whether approval, boundaries, and context handling are tight enough for NHI and agent workflows.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Understanding MCP features: Tools, Resources, Prompts, Sampling, Roots, and Elicitation”.
Key questions
Q: How should teams govern tool execution in MCP workflows?
A: Teams should treat tool execution as a privileged action path, not a background feature.
Q: Why do MCP boundaries matter so much for AI security?
A: Because MCP turns context, files, and actions into a shared workflow surface.
Q: What breaks when MCP roots are too broad?
A: Broad roots erase the file boundary that keeps an MCP server from touching unrelated workspaces.
Practitioner guidance
- Define approval boundaries for every tool call Treat each tool invocation as an individually authorised action, especially where the tool can move money, send messages, or change calendar state.
- Scope filesystem access with explicit roots Limit each MCP server to named filesystem roots tied to the project or workspace it actually needs.
- Separate read-only resources from active workflows Inventory which data sources are exposed as resources, then decide whether they are safe to browse, search, or combine with tools.
Bottom line: MCP shifts identity governance toward approval gates, context boundaries, and scoped filesystem access rather than simple tool enablement.
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:16 pm
Approval is the primary control boundary in MCP: MCP’s most important governance question is not whether a server can expose tools, but whether every action still passes through a meaningful approval step. The article’s design assumes user consent at execution time, which is exactly where identity programmes have to draw the line between suggestion and authority. Practitioners should treat approval as the boundary that prevents model intent from becoming unattended action.
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 an MCP resource and an MCP tool for security governance?
A: An MCP resource is read-only content exposed to the client, such as data the model can inspect without acting on it. An MCP tool performs an action or function on behalf of the model. That distinction matters because tools create operational risk, while resources mainly create exposure risk. Governance should therefore apply stricter approval, scoping, and logging to tools.
👉 Read our full editorial: MCP security depends on boundaries, approval, and context control
This post was modified 3 days ago by NHI Mgmt Group