MCP security depends on boundaries, approval, and context control

At a glance

What this is: This is a practical guide to MCP’s six core features, showing how they divide into action, context, and control layers for AI systems.

Why it matters: It matters because IAM teams will inherit MCP exposure through NHI, agentic, and human-assisted workflows, and the security boundary sits in how those identities are allowed to discover, request, and execute actions.

👉 Read WorkOS's guide to MCP tools, resources, prompts, sampling, roots, and elicitation

Context

Model Context Protocol, or MCP, is becoming the connective tissue between AI models and the tools, files, prompts, and workflows they can use. The identity problem is not the protocol itself, but the way it shifts control from static application logic to runtime access decisions that still need to be governed.

For identity and security teams, MCP creates a familiar pattern with a new wrapper: read-only context, executable actions, delegated reasoning, and filesystem boundaries all need separate controls. That makes the topic relevant to NHI governance, because the real risk sits in exposed tools, over-broad roots, and weak approval handling rather than in the protocol label alone.

WorkOS frames the six MCP features as building blocks for secure, scalable AI applications, but the operational question is whether those building blocks remain controlled once they are combined across multiple servers and clients. In most environments, that is where governance starts to drift.

Key questions

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. Give each tool an explicit owner, scope it tightly, and require logging and approval for any tool chain that can change state, send data, or invoke downstream systems. The key control is per-action accountability, not just model permission.

Q: Why do MCP resources and roots create governance risk for identity teams?

A: Because they turn read access into decision context. If roots are broad or resource sets are poorly segmented, the model can infer sensitive operational detail without ever calling a tool. Identity teams should govern resource exposure like data access, because the resulting model context can be as sensitive as an active credential.

Q: What breaks when MCP approval is treated as a one-time consent step?

A: Downstream actions lose traceability. If one approval covers a multi-step workflow across several servers, the user may not understand every action that follows, and the system may execute more than was intended. Good governance requires approval to stay attached to the specific action, scope, and identity performing it.

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.

Technical breakdown

MCP tools and delegated actions

Tools are the executable side of MCP. They expose schema-defined actions such as search, booking, sending, or updating, and the model selects a tool when it needs to do work. In the article’s model, tool execution stays user-approved, which is the critical security control. The governance issue is that each tool becomes an identity-bearing action surface, especially when tools are chained together across multiple servers. That means tool design is not just an application concern. It is an access-control problem with runtime consequences for NHI and agent workflows.

Practical implication: inventory every MCP tool as a distinct privileged action and apply explicit approval and scope controls before production use.

MCP resources, roots, and read boundaries

Resources are the read-only side of MCP, but read-only does not mean low risk. They can expose files, APIs, databases, or document collections that models browse or reference on demand. Roots add filesystem boundaries, limiting what a client can expose to a server, while resource templates make those boundaries dynamically addressable. The security value here is containment. If roots are too broad, the server inherits more context than it should. If resource access is poorly segmented, the model can still assemble sensitive information without ever invoking a tool.

Practical implication: define roots as least-necessary workspaces and treat resource exposure as governed data access, not passive context sharing.

Sampling and elicitation as control points

Sampling lets a server ask the client to run model reasoning on its behalf, while elicitation lets the server request missing context during a session. Both features are useful because they reduce duplication and fill gaps, but they also create governance dependencies on the client. The client becomes the policy-enforcement point for what the server can ask, what the model can see, and what the user can approve or edit. This is where context control, not just authentication, becomes part of the identity model. If the client boundary is weak, the protocol’s safety claims collapse into implementation detail.

Practical implication: standardise client-side approval, review, and validation paths before allowing servers to request sampling or elicitation at scale.

Threat narrative

Attacker objective: The attacker’s objective is to turn delegated model access into over-broad execution or data access through trusted MCP pathways.

1. Entry occurs when an MCP server is connected to tools, resources, or filesystem roots that expose more context or action surface than the workload truly needs.
2. Credential access or abuse follows when the model is allowed to invoke chained tools or sample reasoning across multiple servers without tight scope separation and approval discipline.
3. Impact appears when combined tool execution, broad resource access, or weak elicitation handling produces unauthorized data exposure or unintended operational actions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Context is now an identity asset, not just a model input. When resources and roots expose files, directories, or reference data to a client, the model can reconstruct operationally sensitive knowledge without ever making a direct tool call. That changes the governance question from who can run code to who can shape the model’s decision context. The implication is that context exposure needs the same review discipline as secrets and privileged APIs.

Roots and resource templates define the new blast radius for AI systems. A broad root is functionally similar to an over-scoped service account, except the access now feeds model inference as well as retrieval. This is where the named concept matters: context blast radius is the amount of sensitive operational state an MCP client makes available to a model before any tool execution occurs. Practitioners should treat that blast radius as a governance boundary, not a performance detail.

Approval is only effective if it remains attached to the right identity and the right action. MCP’s user approval model helps, but approval that sits too far from the actual tool call becomes ceremonial rather than controlling. When tool chains span multiple servers, one approval can obscure several downstream actions. The field should read this as a reminder that delegated AI action needs traceable, per-action accountability rather than one-time consent.

Sampling and elicitation expose the limits of conventional IAM assumptions. These features depend on the client mediating what the server can ask for and what the model can see, which means the trust model is distributed across components. That is a stronger requirement than simple authentication. The practitioner takeaway is clear: govern the client, the server, and the model interaction together, or the weakest boundary will define the whole system.

From our research:

• 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.
• For a broader view of the risk pattern, see DeepSeek breach, which shows how exposed secrets and overshared data can amplify AI system compromise.

What this signals

Context blast radius: MCP deployments will increasingly be judged by how much model-visible state they expose before any tool runs. That pushes security teams toward narrower roots, stricter resource segmentation, and better client-side review flows rather than larger prompt libraries or looser server integration.

The practical signal is that AI governance is shifting from model access alone to context access plus action access. Teams that already map privileged accounts, service accounts, and API tokens should extend the same discipline to MCP clients and servers, especially where sampling or elicitation can change what the model sees mid-session. For standards alignment, the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework are the right reference points.

As MCP spreads into multi-server workflows, programme owners should expect more pressure to document which identity, which client, and which approval path allowed each action. That is a governance requirement, not an audit afterthought, and it will matter as much for human-assisted flows as for NHI-driven automation.

For practitioners

• 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. Do not let these controls sit in separate engineering queues.
• 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. Over-broad roots widen the model’s implicit knowledge base and increase context blast radius.
• Require explicit approval for each high-risk tool chain Treat chained tool execution as multiple privileged actions, not one workflow. Preserve per-step logging, human review, and cancellation points so downstream operations do not inherit unreviewed consent.
• Validate client-side boundaries before enabling sampling Make sure the client enforces prompt review, response editing, and data minimisation before a server can offload reasoning. Sampling should never bypass the same controls you would expect around sensitive NHI access.

Key takeaways

• MCP shifts security from isolated API calls to governed combinations of tools, context, and client-side approval.
• The main risk is not protocol novelty itself, but over-broad roots, resource exposure, and weak attachment between approval and action.
• Teams should treat MCP as an identity boundary design problem and apply least-necessary context, per-action control, and traceable consent.

Key terms

• MCP Tool: An MCP tool is an executable capability exposed by a server for a model or client to invoke during a session. In practice, it is a privileged action surface that can change state, move data, or trigger downstream operations, so it must be governed like any other high-risk non-human identity action.
• MCP Resource: An MCP resource is read-only content that a server makes available for browsing or retrieval, such as files, documents, APIs, or database-backed records. Even without direct execution, resource exposure can widen the model’s decision context and reveal sensitive operational information.
• MCP Root: An MCP root is a bounded filesystem scope that defines where a server may read, write, or search. It functions as a security boundary for client-managed access, and the quality of that boundary determines how much of the environment the model can safely see.
• Context Blast Radius: Context blast radius is the amount of sensitive information and operational state made available to a model before any tool runs. The wider the blast radius, the more likely the system is to leak decision-making context, infer secrets, or act on information that should have stayed out of scope.

Deepen your knowledge

MCP tools, roots, and client-side approval are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping AI protocol controls into an identity programme, that course is a practical place to start.

This post draws on content published by WorkOS: Understanding MCP features, tools, resources, prompts, sampling, roots, and elicitation. Read the original.