Because the effective control boundary moves onto the developer endpoint, where local files, IDE rendering, and tool execution all sit outside network inspection. That makes MCP a governance issue for both identity and device policy, especially when servers run locally and can reach secrets on the workstation.
Why This Matters for Security Teams
MCP servers move governance into a place endpoint teams already struggle to instrument: the developer workstation. Once a server can read local files, invoke tools, and pass data into an LLM workflow, the question is no longer just network exposure. It becomes whether the endpoint, the identity, and the tool chain are all governed with the same rigor. That is why this issue sits at the intersection of device policy, secret hygiene, and workload identity, not just application security.
Current guidance suggests treating MCP as an identity-driven control plane problem rather than a socket-level one. Endpoint tools can miss local config files, IDE extensions, and helper processes that expose secrets or expand access without leaving classic perimeter signals. NHIMG’s The State of Non-Human Identity Security shows how often organisations still lack confidence in NHI controls, which is a warning sign for any workstation-born server path. The same concern appears in the OWASP OWASP Agentic AI Top 10, where tool use and permission boundaries are treated as first-order risk. In practice, many security teams encounter MCP abuse only after secrets have already been copied from the developer machine, rather than through intentional policy design.
How It Works in Practice
Endpoint teams need to think in terms of what the MCP server can do locally, not only what it can reach over the network. If the server runs on the workstation, it may inherit access to files, environment variables, cached tokens, and IDE-integrated data streams. That is why static allowlists and generic device compliance checks are usually insufficient. The more reliable pattern is to combine workload identity, per-tool authorization, and short-lived credentials so the server only receives the access needed for the specific task.
In practice, this means moving toward runtime checks tied to context: which repository is being touched, which user approved the action, which tool is being invoked, and whether the request matches policy. Standards work in adjacent areas points in the same direction. NIST Cybersecurity Framework 2.0 reinforces governance and access control as cross-cutting obligations, while NHIMG’s OWASP Agentic Applications Top 10 highlights how tool-using systems fail when trust is granted too broadly. A practical control set usually includes:
- Ephemeral secrets issued per task rather than long-lived workstation credentials.
- Workload identity for the MCP server, not just the human developer account.
- Policy-as-code checks before tool execution and before file access.
- Logging of prompt, tool, and file events to create a usable audit trail.
NHIMG’s The State of MCP Server Security 2025 is especially relevant here because it shows how often MCP deployments still leak credentials through configuration and fail to scope tool permissions. These controls tend to break down when MCP servers are allowed broad local filesystem access on unmanaged developer endpoints because endpoint telemetry rarely captures the full chain from local secret to downstream tool execution.
Common Variations and Edge Cases
Tighter endpoint control often increases friction for developers, requiring organisations to balance fast local automation against the risk of uncontrolled tool access. That tradeoff becomes sharper in environments with offline laptops, embedded IDE assistants, or teams that store secrets in local config for convenience. In those cases, best practice is evolving rather than settled, and there is no universal standard for how much local autonomy an MCP server should have.
One edge case is centrally hosted MCP versus local MCP. Central hosting can simplify monitoring, but it does not eliminate governance risk if the server still brokers access to developer tokens or sensitive repositories. Another is multi-agent or chained-tool workflows, where one approval can cascade into broader access than the original request intended. That is why endpoint security alone is not enough; teams need identity, device, and policy controls to agree on the same decision boundary. NHIMG’s Top 10 NHI Issues and the ISO/IEC 27002:2022 Information Security Controls both reinforce the same operational point: if access is not time-bound, scoped, and observable, the control plane will drift toward privilege creep.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers tool misuse and excessive agent permissions on local MCP workflows. |
| CSA MAESTRO | MAESTRO-07 | Addresses agent runtime controls and governance for tool-using AI systems. |
| NIST AI RMF | GOVERN | MCP creates governance gaps that require explicit accountability and oversight. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP servers often expose or misuse secrets stored on developer endpoints. |
| NIST CSF 2.0 | PR.AC-4 | Access control must extend to local tool execution and workstation identity. |
Enforce contextual approvals and continuous monitoring for every agent tool call.
