Notifications
Clear all
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.
NHIMG editorial — based on content published by Akto: Governing Third-Party MCP Servers in Claude Code and Cursor
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources.
Q: Why do local MCP servers create secret exposure risk?
A: Local MCP servers often receive API keys or tokens through environment variables, which makes secrets visible to the process and potentially to logs, memory, and inspection tools.
Q: What do organisations get wrong about governing AI use?
A: They often separate AI governance from IAM and lifecycle management, even though AI adoption depends on who can access tools, what data those tools can reach, and how access ends.
Practitioner guidance
- Inventory every MCP-enabled IDE and server Build a current register of AI IDEs, connected MCP servers, owning teams, and approved use cases.
- Enforce corporate identity for MCP access Require corporate accounts or keys for all AI IDE and MCP sessions.
- Block sensitive paths from context sharing Define denylisted paths and patterns such as .env files, secret stores, production folders, and customer export directories.
What's in the full article
Akto's full blog post covers the operational detail this post intentionally leaves for the source:
- A five-point MCP governance policy model for AI IDEs, including corporate identity, allowlists, denylisted paths, high-risk repo handling, and audit requirements
- The specific control points the vendor recommends at the endpoint, IDE boundary, and egress layer for preventing context leakage
- Examples of metadata fields that support incident reconstruction when an MCP server touches sensitive repositories
- The vendor's framing of MCP governance inside Claude Code and Cursor environments
👉 Read Akto's guidance on governing third-party MCP servers in Claude Code and Cursor →
Third-party MCP servers in Claude Code and Cursor: are controls keeping up?
Explore further
02/08/2026 1:14 pm
Third-party MCP servers are now a privileged integration class, not a novelty feature. Once an IDE can pass repository context to external tools, the access path deserves the same scrutiny as GitHub Apps, CI plugins, or endpoint agents. The central issue is not that the model writes code, but that outside tooling can read and shape sensitive development context before standard controls engage. Practitioners should classify MCP as governed integration access, not optional productivity tooling.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between an MCP tool and a normal IDE plugin?
A: A normal plugin usually adds local functionality, while an MCP tool can participate in context retrieval and external data exchange that influences model output. That means the risk profile includes data movement, third-party retention, and session reconstruction concerns. In practice, MCP needs tighter access scoping and oversight.
👉 Read our full editorial: Third-party MCP servers in AI IDEs expand the governance perimeter
