Use a third-party access model for plugins and servers, review the permissions they request, and revoke connections that no longer meet trust standards. The critical control is not convenience, it is limiting what untrusted tooling can reach inside the development environment.
Why This Matters for Security Teams
malicious ide extension and MCP servers are dangerous because they sit inside the developer workflow with enough trust to see code, secrets, and prompts, then reach outward through tools and APIs. That makes them more than a supply chain nuisance. They are an identity and authorization problem, especially when an extension or server can chain actions faster than a human reviewer can notice. Current guidance suggests treating them as third-party access paths, not harmless productivity add-ons. The risk is amplified when teams assume the IDE boundary is a safe place for long-lived tokens or broad permissions.
This is not theoretical. NHIMG research on The State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions. That means most deployments still allow excessive reach by default. Security teams should align this problem with the broader agentic attack surface described in OWASP Top 10 for Agentic Applications 2026, because the same misuse patterns apply when tooling can act autonomously inside the dev environment. In practice, many security teams encounter credential exposure only after a plugin has already reached the wrong system, rather than through intentional review.
How It Works in Practice
The practical control set starts with reducing trust at the connector layer. IDE extensions and MCP servers should be treated like third-party workloads that need explicit approval, scoped permissions, and a revocation path. That includes reviewing what file paths, shell actions, network destinations, and tool invocations they can access. When possible, restrict them to the minimum set of repositories, environments, and APIs needed for a specific task.
For MCP specifically, the protocol makes it easy to overexpose tools unless teams define boundaries deliberately. That is why NHIMG’s Hard-Coded Secrets in VSCode Extensions research matters: if a plugin can read embedded credentials or inherit a broad session, compromise becomes immediate. Use short-lived access, separate dev and production identities, and require reauthorization when the trust context changes. NIST’s Cybersecurity Framework 2.0 supports this approach through stronger governance, asset oversight, and access control discipline.
- Approve extensions and MCP servers through a third-party access model, not developer convenience alone.
- Scope tool permissions to specific repositories, hosts, or environments.
- Prefer ephemeral credentials over long-lived tokens in extension configs.
- Revoke stale connections and revalidate trust when a plugin updates or expands capability.
- Log tool calls so security teams can audit what the extension or server actually did.
Where this works best is in managed developer environments with centralized policy and strong telemetry. These controls tend to break down when local developer workstations can install arbitrary extensions and reach unmanaged internal services because visibility and revocation become fragmented.
Common Variations and Edge Cases
Tighter extension and MCP controls often increase friction for developers, so organisations must balance security with workflow speed. The tradeoff is real: every additional approval step can slow experimentation, but broad trust invites silent privilege creep.
One common edge case is the “helpful” extension that does not look risky until it inherits access to source code, cloud CLIs, or secret stores. Another is an MCP server that is safe in a sandbox but dangerous once pointed at internal ticketing, chat, or deployment systems. Guidance is still evolving on how much runtime inspection to apply to agent-like tooling, but current best practice suggests policy should be evaluated at request time, not only during installation.
NHIMG’s JetBrains Marketplace AI Plugin Campaign and Analysis of Claude Code Security show why marketplace trust alone is not enough. Pair that with OWASP guidance and continuous review, because plugins can become risky after updates, permission expansion, or backend server changes. The highest-risk environments are those that mix local developer access, shared secrets, and broad internal network reach, because a single compromised extension can turn a workstation into a pivot point.
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 | Agentic tool abuse maps to unsafe tool permissions and overreach. |
| CSA MAESTRO | TR-2 | MCP servers need runtime trust and access boundaries. |
| NIST AI RMF | GOV-1 | Third-party AI tooling needs governance, accountability, and monitoring. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Malicious extensions and servers often abuse excessive NHI permissions. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control are central to limiting tool reach. |
Assign ownership, define approval criteria, and monitor third-party AI tool behavior continuously.
Related resources from NHI Mgmt Group
- Why do malicious IDE extensions create a supply chain risk for development teams?
- How should security teams reduce the risk from malicious developer extensions?
- Why do MCP servers create a bigger risk than model prompts alone?
- What should teams do immediately to reduce skill-based supply-chain risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
