JetBrains plugins stealing AI keys expose a new supply chain risk

At a glance

What this is: Aikido says multiple JetBrains IDE plugins were stealing AI provider API keys from developer settings and sending them to an attacker-controlled server.

Why it matters: This matters because IDE plugins can sit inside trusted developer workflows with the same privileges as other dependencies, making pasted secrets and provider keys a supply chain liability for both human and AI-assisted development.

Context

An IDE plugin is a trusted extension that runs inside a developer’s tooling environment and can access the same workflow surface as the user. When that plugin handles API keys for AI coding assistants, the boundary between convenience and credential exposure becomes thin, especially if the extension is not tightly reviewed.

The governance problem is not just malware in an add-on. It is that developer tools increasingly host long-lived secrets for AI services, cloud systems, and build workflows, and those secrets are often entered manually into interfaces that users assume are routine. In that setting, supply chain controls and secrets governance converge.

This campaign is atypical in volume, but the underlying control failure is familiar: a dependency that behaves correctly on the surface can still steal credentials in the background.

Key questions

Q: What breaks when developers paste AI provider keys into IDE plugins?

A: The key stops being a controlled secret and becomes a transferable credential inside untrusted software. A malicious plugin can harvest it at entry, reuse it silently, or exfiltrate it for resale. That breaks the assumption that local developer tooling is outside the identity perimeter and turns the IDE into a credential exposure point.

Q: Why do developer tools increase the risk of AI provider key theft?

A: Developer tools concentrate secrets, code, and trusted execution in one place. If a plugin runs inside that environment and accepts a long-lived API key, it can capture credentials at the point of entry without breaking any perimeter control. That is why IDE governance now matters to NHI security.

Q: What are the signs that an IDE plugin is mishandling secrets?

A: Look for settings pages that ask for provider keys, network calls when users click Apply, plaintext transmission, or plugins that work normally while making unexplained external requests. Unexpected credential prompts, donation walls tied to access, and hidden outbound traffic are strong warning signs.

Q: Should organisations treat AI assistant plugins as part of their identity governance programme?

A: Yes. If a plugin can accept, store, or forward an API key, it is participating in identity and access control, even if it is not a formal IAM system. Organisations should inventory those tools, approve them explicitly, and revoke keys quickly when behaviour is suspicious.

Technical breakdown

How malicious IDE plugins exfiltrate AI provider keys

These plugins abuse a normal settings save path. The user pastes an API key for a model provider, the plugin stores it locally, and hidden code forwards the same value to attacker infrastructure the moment the settings are applied. Because the exfiltration happens inside an expected workflow, the plugin does not need to break the IDE or trigger obvious malware behaviour. That makes the trust boundary the real problem. The code shown in the article also checks key format, proving the theft is targeted at valid provider secrets rather than random text.

Practical implication: Treat plugin settings handlers as credential handling code, not harmless configuration UI.

Why IDE plugins are a supply chain and secrets problem

IDE plugins run with user trust inside an environment that already contains source code, cloud credentials, signing material, and now AI provider API keys. That combination creates a supply chain exposure because a plugin can look functional while quietly harvesting secrets. The article also shows how a paid tier can return a key from attacker infrastructure, which turns the plugin ecosystem into a credential resale channel. In identity terms, these are non-human identities and service secrets being moved through an ungoverned third-party dependency.

Practical implication: Classify IDE plugins as third-party software with secret access and review them accordingly.

Why hidden exfiltration is hard to spot in marketplace ecosystems

Marketplace review does not eliminate risk when malicious logic is buried inside otherwise working features. A plugin can appear to deliver chat, code review, or test generation while still sending keys over the network in the background. The article’s note about fake five-star reviews and inflated downloads adds a trust signal problem on top of the code problem. That means listing reputation, functionality, and actual behaviour are three different things, and only one of them really matters for security.

Practical implication: Verify runtime behaviour and network paths, not just marketplace ratings or install counts.

Threat narrative

Attacker objective: Steal developer-held AI provider API keys and monetise them either by resale or by reissuing access through the malicious plugin.

1. Entry via a seemingly useful JetBrains IDE plugin that a developer installs from the marketplace and configures with an AI provider API key.
2. Credential access occurs when the settings handler captures the key and silently forwards it to attacker-controlled infrastructure over plaintext HTTP.
3. Impact follows when the stolen key can be reused, resold, or redistributed through the plugin's paid tier, exposing provider access and compute spend.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Editor plugins have become a non-human identity exposure layer. When an IDE plugin accepts an AI provider key, it is handling a service credential, not just a preference setting. That shifts the control problem from simple software vetting to credential lifecycle governance inside the developer workflow. Practitioners should treat plugin-installed secrets as governed NHI assets, not convenience inputs.

Secret theft is now a supply chain pattern, not just a code repository problem. The article shows that the attacker did not need to compromise source control or the provider directly. A trusted extension was enough to collect reusable secrets at the point of entry, which means secret sprawl has moved into tooling layers that many organisations still under-govern. The practitioner conclusion is to extend secrets governance to the IDE.

Marketplace trust signals are not control evidence. Install counts, ratings, and even apparent functionality do not prove that an extension is safe to grant secrets access. This article reinforces a broader governance lesson for NHI and agentic AI programmes: if a tool can accept a credential, it must be treated like an access path with audit, inventory, and revocation requirements. The practical response is to validate behaviour, not marketing or popularity.

AI coding assistants create a new credential resale incentive. Provider keys have direct economic value because they can be used for model calls and can be burned for compute. That makes stolen AI keys attractive not only for access but also for monetisation, which widens the attacker market beyond traditional account abuse. Security teams should assume AI tooling secrets will be targeted as a tradable asset.

What this signals

Secret-handling controls must now reach the IDE layer. The campaign shows that the point of compromise can be the first place a human pastes a credential into a tool that feels routine. For NHI programmes, that means editor plugins need the same scrutiny as other third-party software that can touch reusable secrets.

AI provider keys should be treated as tradable credentials. Once a provider secret is exposed inside a compromised plugin, the attacker can monetise it directly or indirectly, so the business impact is broader than a single account loss. Teams should align secrets inventory, revocation, and endpoint software governance so that the IDE is not a blind spot.

For practitioners

• Govern IDE plugins as third-party access paths Require security review for any plugin that can read or store provider keys, cloud tokens, or other reusable secrets, and include them in approved software inventories.
• Remove long-lived AI keys from developer workflows Replace manually pasted provider secrets with short-lived, scoped credentials where possible, and separate personal development keys from production-adjacent access.
• Inspect plugin network behaviour before approval Check whether an extension makes external calls when settings are saved or keys are entered, and block software that transmits secrets to non-provider destinations.
• Revoke and rotate exposed AI provider keys Assume any key entered into a compromised plugin is exposed, revoke it, and rotate related secrets that may share the same trust boundary.
• Inventory AI assistant plugins across endpoints Track which IDE plugins are installed on developer machines, which ones can access secrets, and which teams use them for AI-assisted coding.

Key takeaways

• Trusted IDE plugins can become credential theft channels when they are allowed to handle AI provider keys inside normal settings flows.
• The attack matters because AI provider keys are reusable secrets with direct economic value, which makes them attractive for theft and resale.
• Security teams should extend secrets governance, plugin review, and revocation processes into the developer workstation and IDE layer.

Key terms

• IDE plugin supply chain: The distribution path through which extensions, add-ons, and helper packages are delivered to developer tools. It is a supply chain because trust is inherited from the marketplace, the publisher, and the code package itself, yet any one of those layers can be abused to introduce secret theft or other malicious behaviour.
• Provider API Key: A provider API key is a secret string used to identify and authenticate a caller to a service provider’s API. It usually grants access to specific endpoints or data, and must be protected like a credential. In identity security, it is a non-human credential that should be inventoried, rotated, scoped, and monitored.
• Secrets Exfiltration: The theft of credentials, tokens, API keys, or certificates from a system and their movement to an attacker-controlled location. In developer and automation environments, exfiltration is often hidden inside normal workflow activity, which makes detection and containment harder.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security, IAM, and platform teams apply consistent governance where reusable credentials now appear outside traditional IAM systems.