How should organisations govern IDE extensions in developer environments?

Why This Matters for Security Teams

IDE extensions are not simple productivity add-ons. In developer environments, they often run with broad access to source code, local files, tokens, browser sessions, and internal services, which makes them access-bearing software rather than harmless UI enhancements. That distinction matters because an extension can quietly become a supply chain path into code, secrets, and build pipelines.

Security teams usually miss this risk when extension approval is handled as a convenience choice instead of an access decision. A plugin that requests workspace, file system, or network permissions can exfiltrate sensitive data, introduce malicious update paths, or trigger unexpected child processes. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to manage software risk continuously, not just at procurement time.

NHIMG research shows how quickly extension-related trust can fail in practice, including cases such as the JetBrains GitHub plugin token exposure and the broader pattern of secrets leakage covered in The State of Secrets in AppSec. In practice, many security teams encounter extension abuse only after tokens or source data have already been exposed, rather than through intentional review.

How It Works in Practice

Governing IDE extensions works best when the organisation treats each extension as software with its own identity, permissions, update path, and telemetry. The starting point is an allowlist of approved extensions by editor, business unit, and use case. That list should be managed centrally, because unmanaged marketplace installs create inconsistent risk across teams and make incident response harder.

Next, extension permissions should be reviewed as part of access governance. If an extension asks for workspace access, file system read or write, terminal control, browser integration, or outbound network connectivity, that request should be evaluated like any other privileged access grant. The current guidance suggests combining policy review with runtime monitoring, since static approval alone does not reveal what the extension will do once installed.

A practical control stack usually includes:

• Central logging of extension installs, updates, permission prompts, and runtime network destinations.
• Behavioural controls for unexpected process launches, shell execution, or calls to unknown endpoints.
• Network egress restrictions from developer workstations so extensions can only reach sanctioned services.
• Regular review of extension publishers, signed updates, and dependency integrity.
• Rapid removal paths for extensions that change permissions or begin touching sensitive repos.

This lines up with the need to manage secrets and code exposure as a combined problem, not separate issues. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both emphasise that unmanaged identity-like components create durable exposure when lifecycle controls are weak. These controls tend to break down in highly decentralised engineering teams because local developer autonomy outpaces central review and telemetry coverage.

Common Variations and Edge Cases

Tighter extension control often increases developer friction, requiring organisations to balance security assurance against engineering speed. That tradeoff is real, especially in teams that rely on rapid experimentation, open-source tooling, or editor-specific plugins for specialised languages and build systems.

There is no universal standard for this yet, so mature programmes usually apply tiered governance. Low-risk extensions may be approved through a baseline catalogue, while extensions with file, terminal, or network access require deeper review, explicit business justification, and time-bounded approval. Extensions that interact with code completion, local inference, or external AI services deserve extra scrutiny because they may process sensitive source text outside the workstation.

Another edge case is shared or golden developer images. If an extension is installed at the image level, a single bad approval can spread across entire teams before telemetry detects anything unusual. That is why the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here, alongside the NIST SP 800-53 Rev. 5 Security and Privacy Controls, which support auditability and control enforcement. Organisations should also treat extension telemetry as a detection source, not just a compliance record, because unusual outbound traffic is often the earliest signal of compromise.

Related resources from NHI Mgmt Group

• Why do AI-powered IDE extensions increase developer credential risk?
• How should security teams govern machine identity credentials in agentic AI environments?
• How can organisations govern AI agents that use service accounts and tokens?
• What breaks when IDE extensions are allowed broad workspace and shell permissions?