Security researchers have uncovered a campaign involving fake AI coding assistant plugins that appeared legitimate while secretly sending developer API keys to external servers. AI-powered coding tools are becoming common inside modern development teams. Developers use them to write code faster, generate commit messages, review pull requests, create tests and troubleshoot bugs.
However, the same demand for AI-assisted development is also creating a new target for attackers: developer API keys.
Security researchers have reported a coordinated malware campaign involving plugins published through the JetBrains Marketplace. The affected plugins reportedly presented themselves as ordinary AI coding assistants, but quietly captured and transmitted API keys entered by developers during setup.
The concern is not only about a compromised workstation. Stolen AI provider credentials can give attackers access to paid cloud services, model usage quotas, internal development workflows and potentially connected business systems.
Fake AI Assistants That Looked Legitimate
According to research from Aikido Security, multiple JetBrains IDE plugins were found to contain similar credential-exfiltration routines.
The plugins were published through several different vendor accounts and marketed as tools that integrated with popular AI model providers. Their advertised features included chat assistants, automated code reviews, commit-message generation, unit-test support and general coding help.
That is what made the campaign difficult to spot.
The plugins appeared to work normally. A developer could install one, connect an AI provider account and use its visible features as expected. Behind the scenes, however, the plugin could capture the API key supplied during setup and send it to an external destination.
This kind of approach is especially dangerous because it does not rely on obviously suspicious behaviour. The product looks useful, the interface behaves normally and the user may have no reason to believe their credentials are being copied.
Why Developer Workstations Are a High-Trust Target
Developer environments are different from most standard office computers.
Engineers often need elevated permissions to compile software, run containers, test virtual machines, connect to development databases and work with cloud services. They also frequently install packages, extensions, SDKs and plugins as part of their normal workflow.
That makes the developer workstation a valuable target.
A malicious IDE plugin does not need to break into a system through a traditional exploit if it can convince a developer to install it voluntarily. Once installed, it may be able to access configuration settings, environment variables, local files or API keys entered directly into the application.
The reported JetBrains plugins allegedly embedded their credential-theft logic inside standard settings pages. When a developer entered an API key to connect an AI service, the plugin could transmit that credential immediately without requiring an additional approval prompt.
API Keys Are More Valuable Than Many Teams Realise
API keys are often treated as simple technical credentials, but they can carry significant business value.
A valid key may allow access to paid AI services, cloud resources, source-code automation tools or internal application integrations. In some cases, it can also reveal usage data, enable unauthorised spending or become a stepping stone to wider cloud-account compromise.
These credentials are often classified as non-human identities. Unlike employee accounts, they may not have regular login reviews, multi-factor authentication prompts or strict expiry policies.
That creates a blind spot.
When an API key is copied from a developer workstation, an attacker may be able to use it silently from another location. The organisation may only notice after seeing unusual billing, unexpected API traffic, unexplained service consumption or suspicious activity in provider logs.
Stolen Keys Can Be Used to Build Shadow Services
One of the more troubling aspects of the reported campaign is the possibility that stolen credentials were used to support a wider unauthorised service.
Researchers indicated that some malicious plugins appeared to offer users a paid option, while the operators behind them may have used credentials harvested from other users to fund those services.
In simple terms, one group of users may unknowingly provide the compute resources, while another group pays for access to the same underlying AI capability.
This turns stolen API keys into a form of underground cloud currency.
The affected organisations may end up paying for unauthorised model usage, inflated consumption charges or activity that cannot easily be traced back to a particular employee or project.
Credential Theft Can Lead to Larger Security Incidents
The immediate risk of a stolen API key is unauthorised access to a service. But the longer-term danger can be much larger.
Attackers who obtain valid credentials may use them to explore connected systems, discover cloud resources, access source-code repositories or identify weaknesses in an organisation's development pipeline.
This is why security teams should not treat credential theft as a minor workstation issue.
A compromised API key can become the first step in a wider attack. It may help threat actors move from a local development environment into cloud infrastructure, production systems, internal repositories or business data.
In the worst cases, this type of access can contribute to data theft, extortion or ransomware-related incidents.
Why Marketplace Trust Is Not Enough
Developer marketplaces are useful because they make it easy to discover plugins and extensions. But convenience can also create risk.
A plugin being available in a recognised marketplace does not automatically mean it is safe forever. Malicious packages can pass initial review, change behaviour after later updates or use misleading branding to appear more credible.
Developers should be especially cautious when a plugin asks for:
• API keys or cloud credentials
• Access to source repositories
• Elevated local permissions
• Network access outside known service providers
• Broad permissions that are not clearly needed for its stated purpose
Before installing a tool, teams should review the publisher, check how long the plugin has been available, look for independent feedback and confirm whether it is officially recommended by the relevant AI provider.
What Development Teams Should Do Now
Organisations that allow AI coding tools should take a more structured approach to plugin and credential security.
The first priority is visibility. Security and engineering teams should know which IDE plugins, browser extensions, packages and AI integrations are being used across developer workstations.
Teams should also review how API keys are stored and shared. Keys should not be pasted into random tools, stored in plain-text files or reused across multiple environments.
Useful safeguards include:
• Using separate API keys for individuals, projects and environments.
• Rotating exposed or suspected credentials immediately.
• Monitoring AI-provider logs for unusual locations, volumes or spending.
• Restricting which plugins can be installed on managed developer devices.
• Using centrally managed secrets tools instead of storing keys locally.
• Applying least-privilege permissions to service accounts and tokens.
• Reviewing marketplace plugins before approving them for company-wide use.
Where possible, organisations should use endpoint controls and dependency-monitoring tools that can identify suspicious packages before they are installed.
The Need for Better Non-Human Identity Management
Many companies have improved controls around employee accounts, but non-human identities often receive less attention.
API keys, access tokens, service accounts and automation credentials can remain active for years without being reviewed. They may be shared between teams, embedded in scripts or left behind after projects end.
That is a major security problem.
Every non-human credential should have a clear owner, a defined purpose, limited permissions and an expiry or rotation process. Security teams should also know where the credential is being used and what systems it can access.
The fewer long-lived and unrestricted credentials an organisation has, the smaller the attack surface becomes.
Final Thoughts
The reported JetBrains Marketplace campaign is a reminder that modern developer tools can become a direct route to valuable credentials.
AI coding assistants may improve productivity, but they should still be treated as third-party software with real security implications. A plugin that asks for an API key is not simply a convenience feature. It may become a gateway into paid services, cloud environments and development pipelines.
For engineering teams, the practical lesson is clear: trust should not be based only on marketplace presence or polished features. Review tools carefully, manage API keys properly, monitor usage closely and rotate credentials quickly when there is any suspicion of exposure.
Comments