Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: Understanding MCP features, tools, resources, prompts, sampling, roots, and elicitation
Questions worth separating out
Q: How should security teams govern MCP tools that can trigger actions across systems?
A: Treat every MCP tool as a privileged action, not a convenience feature.
Q: Why do MCP resources and roots create governance risk for identity teams?
A: Because they turn read access into decision context.
Q: What breaks when MCP approval is treated as a one-time consent step?
A: Downstream actions lose traceability.
Practitioner guidance
- Map every MCP feature to an identity control owner Assign tools to privileged action governance, resources to data access governance, roots to filesystem boundary governance, and sampling and elicitation to client-side policy enforcement.
- Constrain roots to least-necessary workspaces Expose only the directories and resource collections needed for the active task, and review every root as if it were a scoped access grant.
- Require explicit approval for each high-risk tool chain Treat chained tool execution as multiple privileged actions, not one workflow.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of MCP server methods such as tools/list and tools/call for implementation teams.
- Concrete JSON structures for prompts, resources, roots, sampling, and elicitation flows.
- The multi-server offsite example that shows how the features interact in a single workflow.
- Client and host role separation that matters when you are designing production integrations.
👉 Read WorkOS's guide to MCP tools, resources, prompts, sampling, roots, and elicitation →
MCP server features and the governance gap teams should close?
Explore further
08/06/2026 6:16 pm
MCP governance is really a control-plane problem, not a feature checklist. Tools, Resources, Prompts, Sampling, Roots, and Elicitation only become safe when each one has a distinct identity boundary. Workflows that mix read context, runtime reasoning, and action execution inside the same trust zone create the exact conditions where NHI governance breaks down. Practitioners should treat MCP as an access architecture decision, not a developer convenience layer.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Hard-coded secrets remain a structural exposure point because they collapse deployment, access, and rotation into one brittle control surface.
A question worth separating out:
Q: How do security teams reduce context blast radius in MCP deployments?
A: Start by limiting roots, narrowing resource collections, and reviewing every prompt, template, and sampling path for unnecessary exposure. Context blast radius shrinks when clients expose only the minimum information required for the current task and force review before additional data is added.
👉 Read our full editorial: MCP security depends on boundaries, approval, and context control
