Topic starter
02/08/2026 12:11 pm
TL;DR: Third-party MCP servers inside Claude Code and Cursor move trust into the IDE loop, where they can read sensitive context, shape code changes, and expose secrets before CI or review controls engage, according to Akto. The governance gap is not code quality but unmanaged third-party integration risk at the developer boundary.
Editorial analysis by NHI Mgmt Group, based on content published by Akto: “Governing Third-Party MCP Servers in Claude Code & Cursor”.
Key questions
Q: What breaks when third-party MCP servers are allowed inside AI IDEs?
A: What breaks is the assumption that the IDE is a local, low-risk workspace.
Q: Why do many MCP servers create more risk than a single development server?
A: Because scale turns a simple integration pattern into a distributed access problem.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Inventory every AI IDE and MCP server Build a current register of Claude Code, Cursor and other MCP-enabled IDE usage, including owner, repo scope and hosting location.
- Enforce corporate identity for MCP access Require corporate accounts and managed keys for AI IDE integrations so developer activity can be tied to a real user, device and session.
- Block sensitive paths from leaving the endpoint Deny export of .env files, secrets directories, production folders and credential stores until the control is technically enforced.
Bottom line: Third-party MCP servers move trust into the developer workflow, where external tools can observe and shape sensitive context before review-based controls begin.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:14 pm
Third-party MCP servers in AI IDEs create a privileged integration surface, not a harmless plugin layer. Once the IDE can request context and return results from an outside tool, the trust decision has moved into the development session itself. That changes the governance model from downstream review to upstream access control. Practitioners should treat these tools like repo-scoped applications with standing ability to observe sensitive context.
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.
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should organisations restrict third-party MCP servers to org-hosted tools only?
A: They should do so for high-risk repositories containing authentication, payments, security controls or regulated data. In those environments, the cost of uncontrolled context sharing is high enough that third-party exposure should be tightly limited or removed entirely.
👉 Read our full editorial: Third-party MCP servers in AI IDEs expand the governance perimeter