JetBrains plugins stealing AI keys expose a new supply chain risk

At a glance

What this is: Aikido found at least 15 JetBrains IDE plugins that behaved as advertised while secretly stealing AI provider API keys from users who pasted them into settings.

Why it matters: This matters because IDE plugins run with developer trust and access, so leaked AI keys can become an NHI governance problem that spans developer workstations, cloud spend, and downstream model abuse.

By the numbers:

• At least 15 IDE plugins, published under seven vendor accounts, share the same hidden behavior.

👉 Read Aikido's analysis of JetBrains plugins stealing AI provider keys

Context

IDE plugins are part of the software supply chain, but they also sit inside a trust zone that many programmes treat as a developer convenience rather than a control boundary. In this case, the primary risk is not a vulnerability in the AI model itself. It is the misuse of non-human identity secrets, specifically API keys stored by developers in tools that can run with broad local privileges.

That creates an identity governance problem as much as a malware problem. Once an AI provider key is entered into an unvetted plugin, the key becomes a transferable credential that can be harvested, reused, or resold. For IAM and NHI teams, the lesson is that developer tooling now behaves like an identity ingress point, not just a productivity layer.

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 AI provider keys need the same governance as other NHI secrets?

A: Because they authenticate automated access to external services, often with spend authority and operational reach. If a plugin or build tool steals the key, the attacker inherits that identity until the key is revoked. Treating it as a managed NHI keeps rotation, ownership, and revocation in scope.

Q: How do security teams know if IDE plugins are being used to steal secrets?

A: Look for secret-entry events followed by unusual outbound connections, model API calls from unexpected hosts, and credentials that begin using new network paths or geographies. Correlate those signals with plugin installs, extension updates, and endpoint inventory so that suspicious behaviour is tied back to a specific tool rather than a vague user action.

Q: Should organisations allow developers to use AI assistants that require manual key entry?

A: Only with tight controls. If the assistant must receive a provider key, the credential should be scoped, monitored, and easy to revoke, and the extension should be reviewed like any other privileged dependency. Where possible, use brokered access or managed identities instead of direct long-lived keys.

Technical breakdown

How malicious IDE plugins harvest AI provider API keys

The campaign works because the plugin captures secrets at the moment they are entered into the settings flow. The code executes inside the apply handler, validates the string format, and then sends the key to an attacker-controlled endpoint through a normal-looking request path. There is no exploit chain in the traditional sense. The malicious logic is embedded in an otherwise functional extension, which makes code review and marketplace review the only practical choke points before installation.

Practical implication: Treat IDE extensions as privileged software and inspect them before they can receive AI provider keys.

Why API keys in developer tools become a non-human identity risk

An AI provider key is not just a secret, it is a delegated identity with spend and access authority. In practice, that key can authenticate workloads, invoke model APIs, and sometimes access related usage or management functions. When a plugin steals it, the attacker does not need to break the platform. They inherit the victim’s identity and can operate under that trust until the key is rotated or revoked.

Practical implication: Classify AI provider keys as NHI credentials and manage them with the same lifecycle controls as other machine identities.

Supply chain abuse in IDE ecosystems

IDE marketplaces are attractive because plugins can look useful, behave correctly, and still hide malicious logic in small utility paths. The attacker benefits from ambient trust, long user dwell time, and the fact that developers often paste secrets into tools they use all day. This is a supply chain pattern, not a single-malware event. The control gap is the assumption that marketplace presence or basic review is enough to establish trust.

Practical implication: Add software provenance checks, restricted plugin allowlists, and secret-entry controls to developer endpoint governance.

Threat narrative

Attacker objective: The attacker aims to harvest transferable AI provider credentials and monetise them by using, reselling, or redistributing the stolen access.

1. Entry occurs when a developer installs a seemingly legitimate JetBrains plugin from the marketplace and enters an AI provider API key into the settings panel.
2. Credential access happens when the plugin stores the key and silently forwards it to an attacker-controlled server through its save handler.
3. Impact follows when the stolen key is reused for AI model access, resold, or repackaged into a paid service that may consume the victim’s quota or budget.

Breaches seen in the wild

• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.
• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI provider keys are now NHI credentials, not mere application settings. When developers paste them into plugins, those keys become transferable machine identities with direct access to expensive and potentially sensitive AI services. That means the control problem sits in identity governance, not just malware detection. Programmes that do not classify API keys as managed NHI assets will miss the real blast radius.

Developer tooling has become an identity ingress layer. IDEs increasingly sit between humans, code, cloud services, and AI models, which makes extensions a path for credential collection as well as code execution. The boundary between endpoint security and identity governance is narrowing. Security teams should treat trusted editor extensions as part of the access plane, not as passive add-ons.

Marketplace review is not a sufficient trust model for plugin ecosystems. A plugin can function correctly while still exfiltrating secrets in a single background call. That creates a governance gap around provenance, runtime monitoring, and post-install validation. For identity-led security programmes, this is a reason to extend secret handling and least-privilege controls into developer workflow tooling.

Secret resale is becoming a credible monetisation model for AI ecosystem abuse. The article’s paid tier pattern shows how stolen credentials can be converted into downstream access for another user, which obscures who is consuming the service and who is paying for it. That complicates detection, billing, and abuse response. Practitioners should assume stolen AI keys will be reused rather than discarded.

Software provenance and NHI governance are converging. When a dependency can silently collect credentials, application security and identity security can no longer be managed separately. The same governance model that controls service accounts, tokens, and workload identities should now extend to developer-facing AI integrations. Teams that align these controls will be better positioned to contain supply chain abuse.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• From our research: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• Security teams should pair that finding with 52 NHI Breaches Analysis to understand how compromised machine credentials repeatedly turn into downstream access abuse.

What this signals

Credential-entry trust is the new weak point in developer workflows. The practical problem is not only whether a secret is stored securely after creation, but whether the point of entry can be trusted at all. That means secret handling policy must extend into IDEs, browser extensions, and build tooling where developers paste credentials during routine work.

NHI governance now includes AI service accounts and API keys as first-class assets. When a provider key can be harvested, redistributed, and consumed by another party, it behaves like any other non-human identity with lifecycle, access, and revocation requirements. Programmes that align this with NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls will have a clearer path to enforcement.

IDE marketplace abuse is a software supply chain problem with an identity consequence. The next phase of detection has to combine endpoint telemetry, extension provenance, and credential observability. For identity teams, the concept to watch is secret ingress control: the ability to govern where high-value credentials can be entered, stored, and transmitted.

For practitioners

• Restrict AI provider keys to short-lived, scoped credentials Replace long-lived API keys with scoped tokens or workload identities where the provider supports them, and rotate any key that must still be manually entered into an IDE. Limit each credential to the minimum model, billing, and management permissions needed for a single workflow.
• Block secret entry into unvetted IDE extensions Create an allowlist for JetBrains plugins and other editor extensions, and prohibit pasting provider secrets into plugins that have not been reviewed by security or platform teams. Pair that policy with endpoint controls that monitor which extensions can access clipboard, network, or configuration storage.
• Inventory AI credentials as managed non-human identities Track every AI provider key as an owned identity artifact with a responsible team, purpose, expiry, and revocation path. When a key appears in a plugin, treat it as a machine credential exposure event and move immediately to revocation, reissuance, and usage review.
• Add detection for unusual AI API usage patterns Alert on sudden spikes in model calls, odd geographies, new user agents, or requests made outside approved developer workstations. Correlate those signals with plugin installation events so that stolen keys can be identified before they are widely reused.

Key takeaways

• Malicious IDE plugins can turn routine AI assistant setup into a credential theft event.
• The scale of secret leakage makes provider keys a managed identity problem, not just a local tooling issue.
• Security teams should combine plugin allowlisting, key scoping, and revocation workflows to reduce the blast radius of developer-side secret abuse.

Key terms

• AI provider API key: A secret string used to authenticate calls to an AI service on behalf of a user, application, or workflow. In security terms, it functions like a machine credential because it grants access, can be reused elsewhere, and must be owned, scoped, rotated, and revoked like any other non-human identity secret.
• 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.
• Semantic exfiltration: The leakage of sensitive information through meaning rather than through obvious data patterns. A prompt can request a client list, secret sauce, or internal policy in ways that evade simple scanners because the text does not contain the full sensitive payload. This is why context-aware review matters.
• 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.

What's in the full analysis

Aikido's full post covers the operational detail this post intentionally leaves for the source:

• The full plugin list, download counts, and release dates for the affected JetBrains Marketplace entries.
• The code paths used to exfiltrate keys and the exact request flow to the attacker-controlled server.
• The indicators of compromise, including the C2 IP and plugin identifiers, for incident response teams.
• The vendor's detection workflow, including rescans and malware issue handling inside Aikido.

👉 Aikido's full post covers the plugin list, attack code, and indicators of compromise

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical framework for managing credentials, ownership, and lifecycle controls across modern identity programmes.