Topic starter
16/01/2026 2:11 pm
TL;DR: MCP servers can extend IDEs with persistent context, tool access, and autonomous actions, but Backslash Security argues that the same design also expands prompt injection, access-control, and supply chain risk across development workflows. The governance problem is no longer just code quality. It is identity, privilege, and trust management for machine-driven tools.
Editorial analysis by NHI Mgmt Group, based on content published by Backslash Security: “Top 10 Risks of Using MCP Servers in IDEs”.
Key questions
Q: What breaks when MCP servers use shared credentials in IDE workflows?
A: Shared credentials break user-level accountability and scope control.
Q: Why do prompt injection attacks become more serious in MCP environments?
A: Prompt injection becomes more serious because the agent can act on manipulated content, not just display it.
Q: How do security teams know if MCP access policies are too coarse?
A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse.
Practitioner guidance
- Map MCP servers as non-human identities Inventory every server, connector, and extension that can act inside IDE workflows, then assign an owner, purpose, and access scope for each one.
- Propagate the human identity into backend calls Avoid shared service credentials where the server acts on behalf of a developer.
- Restrict tool permissions to task-scoped access Remove broad file, network, and execution rights from MCP servers and allow only the minimal tool set required for the current development task.
Bottom line: MCP servers in IDEs widen the attack surface because they can carry context, tool access, and action rights across development workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 5:41 pm
MCP servers create an identity layer inside development tools, not just an integration layer. Once a server can persist context, call tools, and reach backend systems, it is participating in access decisions. That means developers are no longer only consuming software features; they are delegating actions through a machine identity path that needs lifecycle and privilege governance. The practitioner implication is to model MCP as NHI, not as a harmless extension.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: Should organisations treat MCP servers as part of the identity control plane?
A: Yes. An MCP server that brokers access to secrets, models, or downstream services is effectively making authorisation decisions on behalf of machine workloads. That makes its retrieval policy, identity trust chain, and audit trail part of identity governance. If those controls are weak, the server becomes a privileged access path rather than a neutral integration layer.
👉 Read our full editorial: MCP servers in IDEs create new identity and trust risks