Infostealers are now harvesting AI logins and API keys. Here's what that means for your clients

Infostealer malware has always targeted saved passwords and browser sessions. What's changed is what those sessions now open. A stolen AI account can hand an attacker months of chat history, the files end users uploaded, the tools the account is connected to, and in the case of API keys, a bill someone else pays. A password reset may not fix it because the attacker is using a live session or key, not the password. For MSPs, that turns every infostealer infection into an AI incident as well as an endpoint one.

What does an infostealer actually take?

An infostealer is malware built to collect everything useful from a device in a few seconds and send it to the attacker. It doesn't encrypt anything or announce itself. A typical haul includes:

• Saved passwords from the browser's password manager.
• Session cookies and tokens, which keep users signed in to email, SaaS, and AI apps.
• Autofill data, such as names, addresses, and card details.
• Files from common folders, which is where API keys often sit in plain-text config files on developers' machines.

The stolen bundle, called a log, is sold or shared in criminal markets and Telegram channels, sometimes given away free as a teaser for paid access.

The infection usually starts in the browser. A ClickFix page tricks an end user into pasting a command, an ad on search or social media leads to a fake download, often of a popular AI tool, or an end user installs cracked software. That's worth remembering, because the same AI tools attackers want to steal from are also the bait they use to get in.

Why are AI accounts worth stealing?

The value is in everything end users have already put into them. An email password gets an attacker today's inbox. An AI session can get them a searchable record of how the business thinks.

• Chat history. End users paste in contracts, client records, source code, pricing, and board notes to get help with them. A stolen session opens every past conversation at once.
• Uploaded files and projects. Many AI workspaces keep the documents end users shared with them, organized and ready to read.
• Connected tools. AI assistants increasingly link to email, file storage, calendars, and code repositories. Depending on how they're set up, a hijacked session can reach those too.
• API keys and billing. A stolen API key lets an attacker run the AI service on someone else's account. Researchers at Sysdig named this LLMjacking in 2024. Attackers burn through usage, resell access, or use the model for their own purposes, and the victim gets the bill.

The accounts most at risk are often the ones that are not managed. When end users do their work in personal AI accounts, nobody enforces MFA or session limits, nobody sees the sign-in logs, and nobody knows to revoke anything after an infection. Verizon's 2026 breach report found that 67% of users accessing AI services on company devices did so with non-corporate accounts.

How big is the problem?

Two pieces of research from the past few months show where this has landed.

In September 2026, Okta's threat intelligence team analyzed a batch of infostealer logs released free on a Telegram channel, covering 5,871 infected machines in 162 countries. Alongside the usual Google and Microsoft sessions, it held session tokens for AI services including Anthropic's Claude, Cursor, and Character.ai, plus 24 still-valid API keys for services including OpenAI and Google Gemini. On the day the data went public, 1,843 of the tokens in it had not yet expired.

A few weeks later, threat intelligence firm SOCRadar reported more than a million AI-service records in stealer logs, tied to more than 80,000 corporate domains. In the 482 large enterprises it examined closely, ChatGPT sessions turned up at 358 of them, which the researchers read as a sign of shadow AI, meaning work happening in accounts the company doesn't control.

Okta's research also flagged Telegram sellers openly advertising access to stolen Claude, ChatGPT, Gemini, and Cursor accounts. AI access has become a product in its own right.

How can MSPs protect clients?

You're working on two fronts. The first is making infections rarer, and the second is making sure a stolen AI session or key is worth as little as possible when one happens anyway.

1. Make infections rarer. Restrict the command line and PowerShell for end users who don't need them, which takes the teeth out of ClickFix. Use application control and EDR. Provide end users with an approved way to get the AI apps they want, so they aren't searching for downloads and landing on fake installers.
2. Move AI work onto business accounts. Approve the AI tools each client actually uses, which may be several, and put them on business plans behind single sign-on and MFA. That's what lets you see sign-ins, set shorter sessions, and revoke access in one place. A personal account gives you none of that.
3. Steer end users away from personal sign-ins. Browser security platforms such as Atakama can warn and block, per client from one console, when an end user signs in to a work app with a personal account instead of a business one, so the work lands where you can protect it.
4. Treat API keys as secrets, not settings. Keep them out of plain-text files on laptops and in a proper secrets manager. Scope each key to one project, set spending limits and usage alerts where the provider offers them, and rotate keys on a schedule.
5. Respond to every infection as an AI incident too. Clean or reimage the device before anything else, or the stealer simply collects the new sessions and keys. Then revoke sessions in every app the user was signed in to, AI tools included, rotate any API keys that were on the machine, reset passwords, and check AI accounts for unfamiliar sessions, shared links, and newly connected apps.

Step 5 is where many incident playbooks fall short today. They cover email and Microsoft 365 and stop there, while the AI accounts holding the most sensitive context stay signed in.

FAQ

Can infostealers steal ChatGPT or Claude sessions?

Yes. Infostealers copy the session cookies and tokens browsers use to keep end users signed in, and AI services work the same way as any other web app. Researchers have found unexpired AI session tokens and working AI API keys in leaked infostealer logs.

Does resetting the password stop someone using a stolen AI session?

Not reliably. The attacker is using a session that was already signed in, and some services keep those sessions alive after a password change. Sign the user out of all sessions in each AI service, rotate any API keys, and reset the password as well.

What is LLMjacking?

Using stolen credentials or API keys to run an AI model on someone else's account. Attackers use it to get free access, resell it, or run up usage that the victim pays for.

Are personal AI accounts riskier than business ones?

For the business, yes. A personal account can hold work data, but the MSP can't enforce MFA, see its sign-ins, or revoke its sessions after an infection.

How do I know if a client's AI credentials have been stolen?

Watch for unfamiliar sign-ins or sessions in AI admin consoles, unexpected API usage or spending, and alerts from dark web or stealer-log monitoring for the client's domains. Any infostealer detection on a device should be treated as a likely AI credential exposure.

Keep reading

For more on protecting the accounts end users sign in to, see why MFA alone doesn't stop session hijacking, how ClickFix and fake AI installers work, why personal AI accounts are the real leak, and our pages on credential theft prevention and phishing protection.

Sources

• Okta Threat Intelligence, Signing in without actually signing in, September 2026, with coverage by The Hacker News and the Cloud Security Alliance
• Proton, Cybercriminals have stolen AI logins from 80,000 organizations, October 2026, reporting SOCRadar's AI Identity Exposure Report 2026
• Sysdig, LLMjacking: stolen cloud credentials used in new AI attack, May 2024
• Verizon, 2026 Data Breach Investigations Report