Not as a standalone category. MCP deserves controls, but the same governance logic applies to Dev Containers, Jupyter kernelspecs, package install scripts, Docker plugins, and Git hooks. The practical test is whether a file can turn into execution on the host, because that is the real decision point for access and containment.
Why MCP should be governed like any other execution surface
MCP is not a special exception to the normal question of whether a file, hook, or local configuration can trigger code on the host. If a surface can execute with user or developer privileges, it deserves the same containment, review, and trust-boundary thinking as other developer execution paths. The control objective is to prevent implicit execution from becoming implicit authority.
That is why MCP Security Guide belongs in the same conversation as other execution-oriented controls: the security issue is not the label, it is whether the surface can mediate tool use, load code, or hand off credentials. A local MCP server, a dev container, or a package script can all become a route from content to execution if the trust boundary is loose.
Practitioners should also read this through the lens of broader agent and tool governance. OWASP Agentic Applications Top 10 is useful here because tool misuse and identity or privilege abuse are the same class of failure when an execution surface can reach beyond its intended sandbox.
What actually makes a developer surface dangerous
The real test is whether the surface can turn a file, manifest, script, or metadata record into host execution. Once that is true, the security questions become familiar: who can author it, who can modify it, what privilege it inherits, and whether it can reach secrets, network resources, or the filesystem. That is the same decision structure you use for Git hooks, install scripts, kernelspecs, and plugin ecosystems.
Execution surfaces become more dangerous when they are easy to chain. An apparently harmless config file can load code, a wrapper can invoke a package manager, and a tool adapter can hand the process a broader token or environment than intended. The risk is not just code execution, but silent privilege transfer and context leakage.
Analysis of Claude Code Security is a good reminder that code-facing tools often blur the line between inspection and execution. If a surface can influence runtime behavior, treat it as an execution boundary, not a documentation boundary.
When this pattern is built into cloud or hosted tooling, the blast radius can expand quickly. A weakly governed execution surface can expose tokens, mutate files, or reach connected services well beyond the original repository or notebook session.
How teams should decide on controls without over-specialising MCP
Teams should apply one governance model across all execution-capable developer surfaces, then add MCP-specific checks only where the protocol changes the trust path. That means standardising on code review, provenance checks, privilege minimisation, sandboxing, and explicit approval for surfaces that can launch or alter execution.
AI Agent Identity Security: The 2026 Deployment Guide is relevant because the practical control question is the same: bind authority tightly, scope credentials narrowly, and avoid long-lived ambient access where a runtime can act on behalf of a person or pipeline.
For protocol-specific detail, Model Context Protocol: Authorization specification is the right reference when an MCP deployment uses HTTP transport and OAuth-based authorization. That matters where token audience, no-pass-through handling, and resource-server assumptions decide whether the server is safely contained or can overreach.
In practice, the best decision rule is simple: if the surface can execute, load, or delegate, put it under the same review and containment rules you would apply to any code path that can change host state. If it cannot, keep the control lighter and avoid inventing special handling just because the technology brand is different.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP and other execution surfaces can transfer authority into runtime actions. |
| ASI02 — Tool Misuse | Execution surfaces can be abused to invoke unintended tools or commands. | |
| Recommendation — Bind tool and runtime privileges tightly to prevent delegated execution abuse. Restrict tool invocation paths and require explicit approval for sensitive actions. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | MCP authorization and containment depend on correct server-side configuration. |
| Recommendation — Harden transport and authorization settings before exposing the execution surface. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Developer execution surfaces should expose only the minimum runtime capability. |
| AC-6 — Least Privilege | The issue is whether an execution surface inherits more authority than needed. | |
| Recommendation — Remove unnecessary execution paths and disable unused extensions or hooks. Limit inherited privileges for scripts, plugins, notebooks, and containers. | ||
Practitioner Guidance
What to prioritise: inventory every developer-facing surface that can convert content into execution, then group them by privilege, persistence, and secret access rather than by product name. That gives you one control model for the whole class and avoids fragmented exceptions.
What to verify: confirm whether the surface can run with inherited credentials, reach the network, write to the workspace, or invoke subordinate tools without an explicit approval step. If any of those are true, treat it as a containment and authorization problem, not just a configuration problem.
Common mistake: teams often isolate MCP as a “new protocol risk” and miss the older, better-understood execution channels that behave the same way. The failure mode is usually inconsistent governance, not novel exploitation.
Practitioner takeaway: manage MCP as one member of a broader execution-surface family, and make the control boundary follow execution and privilege, not protocol identity.
Related resources from NHI Mgmt Group
- Should organisations treat AI-themed developer tooling differently from other dependencies?
- Should IAM teams treat code assistants differently for auth than for other features?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?