Topic starter
02/08/2026 11:25 am
TL;DR: Installed close to 70,000 times, the JetBrains Marketplace plugins showed how trusted IDE extensions can become a credential theft channel, according to Aikido. IDE settings now need tighter secrets review and faster revocation when plugins request provider keys or make suspicious outbound calls.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Multiple JetBrains IDE plugins caught stealing AI keys”.
Key questions
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.
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.
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.
Glossary terms: IDE plugin supply chain, Provider API Key, Secrets Exfiltration, Non-Human Identity (NHI)
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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