Third-party MCP servers in AI IDEs expand the governance perimeter

At a glance

What this is: Third-party MCP servers in AI IDEs create a privileged integration surface that can read, send, and influence developer context before downstream controls see it.

Why it matters: IAM, security architecture, and NHI teams need to govern AI IDE integrations like any other third-party access path because they now sit inside the developer trust boundary.

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.

👉 Read Akto's guidance on governing third-party MCP servers in Claude Code and Cursor

Context

Third-party MCP servers in AI IDEs such as Claude Code and Cursor turn the editor into a privileged integration point. The governance problem is not whether the generated code compiles, but whether outside tools are now participating in what the IDE reads, what it sends, and what gets changed during development.

That shifts the identity and access question upstream of CI and review. If developers can connect unsanctioned MCP servers to sensitive repositories, the organisation has created a new non-human access path that behaves like a third-party integration but is often managed with far less oversight than code, pipeline, or endpoint controls.

For identity teams, this is a familiar failure pattern in a new place: unmanaged access, unclear auditability, and weak scoping. The control gap is in the IDE boundary, where context is assembled before traditional security gates have anything to inspect.

Key questions

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. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

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. If the server is compromised, those credentials can be reused outside the intended boundary. Runtime injection reduces that exposure by keeping secrets out of user space.

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. A policy that ignores procurement, revocation, and exception management will miss the identities that create the risk.

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.

Technical breakdown

How MCP servers expand the AI IDE trust boundary

Model Context Protocol lets an IDE or model call tools and fetch context from external sources. In practice, that means a third-party server can receive files, prompts, metadata, and repo context, then return outputs that influence code suggestions or edits. The security consequence is that the IDE no longer behaves like a closed local workspace. It becomes an integration runtime where data, policy, and execution all meet before downstream controls such as CI, DLP, or code review can intervene.

Practical implication: treat every MCP-enabled IDE as an integration boundary that needs explicit policy, inventory, and audit.

Why secrets and sensitive paths leak through context requests

MCP risk is often accidental rather than overt. A request for project context can pull in .env files, sample configs, logs, stack traces, shared libraries, or adjacent directories that contain real credentials or architecture details. Because the tool asks for context rather than a single file, the exposure can be broader than the developer intended. This is why secrets management and path-based controls matter even in development environments: the leak happens during context assembly, not after a commit.

Practical implication: block sensitive paths and credential-bearing files from AI IDE context sharing before they can be requested.

Why auditability fails when MCP access is informal

When an MCP server is used through a personal token, an unknown host, or an unapproved endpoint, the organisation loses the ability to reconstruct who accessed what, from where, and through which tool. That breaks incident response, policy enforcement, and third-party accountability. Auditability in this setting is not about logging every token value. It is about preserving enough metadata to answer which developer, device, IDE, MCP server, repo, and session were involved.

Practical implication: require corporate identities and session-level metadata for every MCP connection to preserve reconstruction capability.

NHI Mgmt Group analysis

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.

Context export is the new secret exposure path in AI IDEs. The most likely failure is not a deliberate exfiltration event but incidental leakage through broad context requests. Files, logs, fixtures, and adjacent folders can all be pulled into a tool session that was initiated for a narrow task. Context leak blast radius: that is the right concept for this problem. The implication is that scoping must happen at the context boundary, not only at commit or deployment.

Auditability is the control that separates managed MCP use from shadow integration. If teams cannot identify the MCP server, repo, device, and session involved in a tool call, they cannot establish accountability after the fact. That makes the access path operationally similar to an unmanaged service account or third-party workload credential. Security teams should treat unknown MCP endpoints as an identity governance failure, not just an AppSec issue.

High-risk repositories need a stricter trust model than general development work. Auth, payments, security tooling, and regulated-data repos cannot absorb the same MCP exposure profile as low-sensitivity code. The governance mistake is assuming one policy fits all repositories. Practitioners should apply stronger controls where the data and blast radius justify it, because the IDE is now part of the sensitive-data perimeter.

From our research:

• 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.
• For the broader governance pattern, see 52 NHI Breaches Analysis for repeated cases where unmanaged non-human access widened the blast radius.

What this signals

Context leak blast radius: AI IDE governance now depends on controlling what can leave the development environment before a diff exists. That is the practical shift teams should prepare for, because traditional review and CI controls are too late to govern context export.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, the pattern is already familiar. The difference here is that the third-party access surface has moved into the developer workstation and the IDE session.

Teams should expect MCP to force a closer merge between endpoint governance, identity control, and third-party risk management. The organisations that can reconstruct who used which server, against which repo, will be in a much stronger position to contain policy violations and explain exposure scope.

For practitioners

• Inventory every MCP-enabled IDE and server Build a current register of AI IDEs, connected MCP servers, owning teams, and approved use cases. Reconcile that list with developer endpoints and repository access so you can see where third-party context access exists today.
• Enforce corporate identity for MCP access Require corporate accounts or keys for all AI IDE and MCP sessions. Ban personal tokens and unknown endpoints so sessions can be attributed during investigation and policy enforcement.
• Block sensitive paths from context sharing Define denylisted paths and patterns such as .env files, secret stores, production folders, and customer export directories. Apply endpoint or IDE-boundary controls so these locations never leave the environment through MCP requests.
• Restrict third-party MCP use in high-risk repos Require org-hosted or explicitly approved MCP servers for repositories that contain authentication code, payments logic, security controls, or regulated data handling. Use stricter review for any exception.
• Capture enough metadata for session reconstruction Log developer identity, device identity, IDE version, MCP server identifier, repository identifier, and timestamped session metadata. Preserve the minimum audit trail needed to answer what was accessed and what was sent.

Key takeaways

• Third-party MCP servers move trust into the AI IDE, where they can read and shape sensitive context before downstream controls can see it.
• Secrets exposure, shadow integration, and weak auditability are the three operational failure modes security teams should expect first.
• The right response is to govern MCP like privileged integration access, with inventory, scoping, egress limits, and reconstructable audit trails.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• AI IDE: An integrated development environment that uses AI features to read, suggest, or change code based on workspace context. When connected to MCP servers, the IDE becomes a privileged integration point and not just a local editor.
• Context Export: The transfer of files, prompts, metadata, or adjacent project material from a development environment into an external tool session. This is a governance problem because the sensitive information often leaves before traditional review, build, or DLP controls can intervene.
• Shadow Integration: A shadow integration is an undocumented or unmanaged connection between applications that operates outside central governance. These integrations often appear when business teams configure webhooks directly, leaving security teams without clear ownership, data-flow visibility, or retirement controls.

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

👉 Akto's full post covers the five MCP failure modes, governance model, and audit controls in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.