MCP security depends on boundaries, approval, and context control

At a glance

What this is: This is a practical walkthrough of MCP’s six core features, showing how server-side capabilities and client-side controls divide responsibility for actions, context, and user approval.

Why it matters: IAM and security teams need to treat MCP as an identity and governance boundary problem, because tool execution, context access, and runtime prompts all create control points that must be scoped and approved.

Context

Model Context Protocol is a control plane for how large language models reach external tools, data, and context. In identity terms, the article is really about where approval, scope, and runtime boundaries sit when an NHI or AI workflow can both read context and initiate actions.

WorkOS separates MCP into server-side exposure of tools, resources, and prompts, and client-side handling of sampling, roots, and elicitation. That split matters because governance failures tend to occur where the server can influence action and the client must preserve user control, especially when filesystem access, approval prompts, and model context are all in play.

The article also shows that MCP is not one behaviour but a set of different trust boundaries. Tools can act, resources can reveal, prompts can steer, sampling can offload reasoning, roots can constrain filesystem access, and elicitation can fill missing context, so teams have to govern each capability differently.

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. The client should enforce explicit approval, the server should expose only narrowly scoped schemas, and the organisation should log each call as a distinct authorised event so action cannot drift beyond user intent.

Q: Why do MCP boundaries matter so much for AI security?

A: Because MCP turns context, files, and actions into a shared workflow surface. If boundaries are weak, the model can assemble information from resources, receive instructions from prompts, and execute tools in ways that outgrow the original request, which creates governance drift even without malicious intent.

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. Once the server can read or write outside the intended folder, the model can pull in sensitive files, overwrite data, or reuse stale context from a previous task.

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.

Technical breakdown

Tools and explicit user approval in MCP

Tools are action interfaces: the server exposes a schema-defined operation, the client selects when to call it, and the model proposes the tool based on user intent. The security control is not the tool itself but the approval gate around execution. Because tools can trigger real-world actions such as booking, emailing, or updating calendars, each call becomes a potential privilege boundary. The article makes clear that tools are designed to be explicit, typed, and user-approved, which is fundamentally different from passive context retrieval. That means tool design has to account for action scope, input validation, and the risk that a model will chain multiple operations in one flow.

Practical implication: Treat every MCP tool as a privileged action and require explicit approval, scoped inputs, and logging for each execution.

Resources, prompts, and context exposure

Resources are read-only data objects that expose files, APIs, or databases for browsing and search, while prompts are reusable instruction templates that shape how the model behaves. Together, they create the context layer that can guide or mislead downstream decisions. In MCP terms, resources are not supposed to perform actions, but they still expand what the model can infer and combine. Prompts are explicitly invoked and can be centrally updated, which is useful for consistency but also means governance must cover template provenance and when a prompt is allowed to reference sensitive resources. The risk is less about execution and more about context leakage or overbroad knowledge exposure.

Practical implication: Classify resources and prompts separately, then restrict which data sources a server may expose to avoid unintended context expansion.

Sampling, roots, and elicitation as client-side controls

Sampling lets a server ask the client to run model reasoning, roots define which filesystem paths a server can touch, and elicitation requests missing user context during a session. These are client-side controls, so they sit closer to the user trust boundary than the server’s feature set. Sampling is especially important because it keeps the model call inside the client’s context, while roots prevent unrestricted file access and elicitation formalizes missing-information flows. The common pattern across all three is that the client preserves boundary enforcement even when the server is orchestrating the workflow. That architecture makes the client the main policy gate for context, scope, and user interaction.

Practical implication: Use client-side policy to confine filesystem access, approve sampling requests, and force structured elicitation for missing context.

Threat narrative

Attacker objective: The objective is to turn model connectivity into uncontrolled action or context access by exploiting weak approval and boundary enforcement.

1. Entry occurs when an MCP server is connected to external tools, resources, prompts, or filesystem roots that extend the model’s operational reach beyond the original session context.
2. Privilege is exercised when the client allows tool calls, sampling, or resource access that can influence actions or expose sensitive context across multiple systems.
3. Impact follows when approval, boundaries, or context controls are too loose, enabling unintended actions, overbroad data exposure, or workflow chaining across servers.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Context control is a governance problem, not a UX detail: Resources, prompts, sampling, and elicitation all shape what the model knows before it acts. That makes context exposure part of identity governance because the model can only make bounded decisions if the client and server agree on what context is visible, when, and to whom. The practical conclusion is that context boundaries must be reviewed with the same seriousness as action boundaries.

Roots create a filesystem analogue to scoped access: Root boundaries are effectively filesystem entitlements for an MCP session, limiting what a server can see and change. This is the same control logic that underpins least privilege in NHI programmes, but here it is enforced at runtime through client policy rather than static onboarding alone. Teams should recognise roots as a direct control surface for data containment.

Multi-server workflows multiply the governance gap: Once tools, resources, and prompts span several servers, the trust model stops being local to one integration and becomes chain-wide. That is where hidden privilege accumulation appears, especially when one server can influence another through context and approved actions. Practitioners should review MCP as a delegation chain, not a single integration point.

MCP exposes a context-control gap that traditional IAM does not fully cover: Identity programmes were designed to govern who can authenticate, what they can access, and which actions are authorised. MCP adds a layer where the model can infer, assemble, and request action across multiple boundaries, so the real challenge is controlling context flow as well as credentials. The implication is that practitioners must extend governance from identity to interaction boundaries.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Context boundaries are now an identity control surface: MCP makes context, filesystem scope, and action approval part of the same trust model. Teams that still treat these as separate engineering details will miss where privilege actually accumulates during agentic workflows.

Roots, sampling, and elicitation should be reviewed together: the client now owns the boundary between model reasoning and server execution. That means the control question is no longer just who can call a tool, but what context the model can see before it decides to call one.

Model Context Protocol is already creating secret sprawl pressure: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, a sign that protocol adoption is exposing new governance surfaces faster than many teams can inventory them.

For practitioners

• 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. Require the client to preserve the approval step and retain an audit trail for each execution.
• Scope filesystem access with explicit roots Limit each MCP server to named filesystem roots tied to the project or workspace it actually needs. Reassess those roots whenever the user changes folder, project, or task so servers do not inherit stale access.
• 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. Avoid exposing sensitive data through resources unless the model truly needs that context to complete the task.
• Govern prompts as centrally managed instructions Version and review prompt templates because they shape behaviour at runtime and can be reused across clients. Keep sensitive references out of prompts unless the server has a clear need to combine them with approved context.
• Treat sampling as a policy-controlled model bridge Allow sampling only when the client can keep the model call inside its own policy and user review flow. Do not let server-side reasoning requests bypass rate limits, data boundaries, or user visibility.

Key takeaways

• MCP shifts identity governance toward approval gates, context boundaries, and scoped filesystem access rather than simple tool enablement.
• The article’s core message is that client-side controls are as important as server-side features when AI workflows can read, reason, and act across systems.
• Practitioners should review MCP as a delegation chain so that tool calls, resources, prompts, sampling, roots, and elicitation all map to explicit control ownership.

Key terms

• MCP Tool: An MCP tool is a capability exposed through the Model Context Protocol so an AI agent can call external functions, retrieve data, or trigger actions. Technically, it is a structured interface with defined inputs, outputs, and permissions, allowing controlled interaction between an agent runtime and systems such as databases, APIs, or workflows.
• MCP Resource: An MCP Resource is a data object, file, or service endpoint exposed through the Model Context Protocol for an AI agent to read or reference. In technical terms, it is a named, addressable context source that can be discovered, described, and accessed through MCP permissions, metadata, and transport rules.
• MCP Root: MCP Root is the top-level trust anchor for a Model Context Protocol deployment. It defines which servers, tools, and policy boundaries an AI agent can rely on. In practice, it is the authoritative control point for identity, authorization, and session trust across MCP-connected workflows.
• MCP Elicitation: MCP elicitation is the process of prompting an AI agent to request, reveal, or infer information through Model Context Protocol interactions. In security analysis, it refers to how tool calls, context sharing, and user prompts can be shaped to extract sensitive data, permissions, or hidden instructions from connected systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.