JetBrains plugins live in the same architectural niche as VS Code extensions: third-party code that runs inside the IDE with broad access to the developer's environment. The ecosystem is smaller, the average plugin quality is higher, and the marketplace review process is more rigorous. None of this makes the security model fundamentally different. The plugins still run in-process, still have full filesystem access, and still represent a meaningful attack surface that most organizations do not measure.
This post covers the JetBrains-specific issues for 2026, the controls that the platform exposes, and the gaps that need compensating elsewhere.
How does the JetBrains plugin model differ from VS Code's?
JetBrains plugins are JVM code, typically Kotlin or Java, packaged as .jar or .zip files and loaded by the IntelliJ Platform at IDE startup. The execution model is different from VS Code's Node.js extensions in ways that matter for the threat model. JVM bytecode is harder to obfuscate convincingly than minified JavaScript, which makes static analysis somewhat more effective. Plugins can declare permissions in their plugin.xml, though the enforcement of these declarations has historically been spotty. There is no fine-grained sandbox; a plugin that loads has full access to whatever the IDE process can reach.
The marketplace review at JetBrains is more substantive than at the VS Code marketplace. New plugins go through a human review before publication, and updates from established publishers go through a faster automated check. This catches the most obvious malware and typosquats, but it does not catch maintainer takeovers, slow-burn behavior changes, or supply chain compromises where the plugin's own dependencies are the attack vector. The 2024 incident involving a popular IntelliJ plugin whose Maven dependency was compromised illustrated the latter category clearly: the plugin itself was clean, the dependency it pulled in was not, and the review process did not catch it.
What does the JetBrains-side trust model look like in 2026?
JetBrains introduced signed plugins in 2021 and made signing mandatory for marketplace publication shortly after. This means every plugin from the official marketplace carries a verifiable signature, which is a meaningful improvement over the VS Code situation. The signature binds the plugin to a publisher identity, and the marketplace tracks publisher reputation over time. Plugin verification is enforced by the IDE on install.
The gap is third-party plugin sources. JetBrains supports custom plugin repositories, and many organizations maintain internal repositories for proprietary plugins or for vendor-distributed integrations. Custom repository plugins are signed if the publisher chose to sign them, but the IDE does not enforce signing for custom sources by default. This is a configuration mistake more than a platform gap, but it is a common one. Audit your custom plugin repository config and ensure that unsigned plugins are rejected.
What about the IntelliJ-based language servers?
The 2026 trend in the JetBrains ecosystem is the move toward language-server-protocol-based plugins, which run an external process for language features rather than loading code into the IDE directly. From a security standpoint this is a small improvement, because the LSP process runs in a separate address space, but it introduces the LSP server itself as a new supply chain element. The LSP servers are typically distributed through npm, PyPI, or Go modules, which means the IDE plugin is a thin wrapper around a dependency tree that lives in a different ecosystem and goes through a different review process.
The implication is that a JetBrains plugin's risk profile is increasingly determined by the LSP server it bundles, not by the plugin code itself. The plugin code might be twenty lines of Kotlin that downloads and launches a Node.js or Python LSP. The supply chain controls you apply to npm and PyPI need to apply to the LSP servers your IDE plugins pull in, and most organizations do not currently track this dependency layer.
How do you control plugin installation across the team?
JetBrains supports managed IDE settings through the idea.properties file and through JetBrains IDE Services, the enterprise management platform introduced in 2023. The latter is the right tool for most organizations of meaningful size. It centralizes IDE configuration, including the plugin allowlist, and pushes settings to developer workstations automatically. The plugin allowlist accepts wildcards on publisher and plugin ID, which makes maintaining the list less painful than for VS Code.
A reasonable default policy is to allow all JetBrains-published plugins, allow plugins from a small set of vetted third-party publishers, and block everything else with a fast-track exception process. JetBrains-published plugins are the lowest risk in the ecosystem; the company has obvious reputational incentives and a real security team. The risk concentrates in the long tail of third-party plugins, which is also where the interesting functionality lives, so the policy needs an exception mechanism that actually works.
What about the AI-assistant plugins specifically?
The JetBrains AI Assistant, GitHub Copilot for IntelliJ, and the various competing AI coding plugins are a special case worth calling out. These plugins, by design, send code from the IDE to a remote inference service. The plugins themselves are trustworthy, the network destinations are documented, and the data flow is usually compliant with the organization's policy. The risk is the long tail of competing AI plugins from smaller publishers, which have similar functionality but vastly less scrutiny.
Several incidents in 2024 and 2025 involved third-party AI plugins that exfiltrated more code than they disclosed, or that routed requests through intermediary services without clear data-handling agreements. The pragmatic control is to allowlist a small number of vetted AI plugins, block the rest, and treat the allowlist as a high-touch item that requires legal and security review for additions. AI plugins are the highest-data-volume category of plugin in most environments, and they deserve correspondingly high attention.
How Safeguard Helps
Safeguard's workstation integration ingests the JetBrains plugin inventory and evaluates each plugin against our TPRM scoring, including the publisher's historical security posture and recent maintainer changes. Griffin AI flags plugins whose bundled LSP servers or other dependencies are on our zero-day watch list, surfacing risks that the plugin manifest alone would not reveal. Reachability analysis tracks which plugins are active on which workspaces, so the prioritization reflects real exposure rather than total installed count. Policy gates in CI can validate that the developer's IDE environment meets baseline requirements before a build is accepted from that workstation, tying endpoint posture to deployment authorization. For organizations running mixed IDE fleets, the same controls apply uniformly across VS Code and JetBrains, which is where the consolidated view becomes useful.