TL;DR: At least 15 JetBrains Marketplace plugins, installed close to 70,000 times, secretly exfiltrated AI provider API keys from developer settings and may have resold stolen access back through a paid tier, according to Aikido. The case shows how trusted IDE extensions can turn long-lived secrets into a supply-chain credential theft channel, especially when AI tools are granted keys inside the editor.
NHIMG editorial — based on content published by Aikido: Multiple JetBrains IDE plugins caught stealing AI keys
By the numbers:
- At least 15 IDE plugins, published under seven vendor accounts, share the same hidden behavior.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Aikido's analysis of JetBrains plugins stealing AI provider keys →
JetBrains IDE plugins stealing AI keys: what should teams do now?
Explore further
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: JetBrains plugins stealing AI keys expose a new supply chain risk