Topic starter
02/08/2026 11:25 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Multiple JetBrains IDE plugins caught stealing AI keys”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Trusted IDE plugins can become credential theft channels when they are allowed to handle AI provider keys inside normal settings flows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:42 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: JetBrains plugins stealing AI keys expose a new supply chain risk