The discovery that AI-related credentials from more than 80,000 corporate domains have appeared in infostealer data should be viewed as a major identity-security warning rather than merely another credential-theft statistic. The issue is not confined to passwords for ChatGPT or other conversational AI tools. Modern AI accounts can contain conversation histories, uploaded files, API keys, active browser sessions, developer credentials, OAuth grants, and access to paid model infrastructure. When those identities are stolen, attackers may inherit far more than a login screen.

SOCRadar’s AI Identity Exposure research began with more than one million infostealer records associated with AI services across more than 80,000 corporate domains. Researchers then focused on 482 large, established organizations across 36 countries and eight industries to understand what these exposures represented. Among that smaller sample, they identified 5,434 stealer-log records linked to approximately 1,500 distinct corporate email addresses, while 295 of the 482 companies had appeared in stealer data within the previous 90 days.

The first important distinction is that the figure does not mean 80,000 organizations suffered a direct breach of an AI provider. The data comes from infostealer logs collected from compromised endpoints. In other words, employees or users had credentials, session cookies, API keys, or AI-related account information stored on machines that were infected by commodity information-stealing malware. That makes this fundamentally an endpoint and identity problem, not evidence that OpenAI, Anthropic, Google, or the other AI providers themselves were compromised.

This distinction matters because it changes the defensive response. An organization can select an AI provider with strong internal security and still lose control of the account if an employee uses it from an unmanaged or malware-infected device. Once an infostealer extracts browser cookies, saved credentials, local configuration files, or API keys, the attacker may be able to reuse those credentials independently of the original endpoint.

The SOCRadar data also shows how dominant ChatGPT and OpenAI-related exposure currently is. Of the 482 organizations studied in detail, 358 had at least one captured ChatGPT or OpenAI credential or session, and those companies accounted for roughly 90% of all records in the sample. That should not automatically be interpreted as evidence that ChatGPT is technically less secure than competing platforms. The more plausible explanation is adoption scale and shadow AI: employees have widely created their own AI accounts using corporate email addresses, often outside formal IT governance.

This is the real shadow-AI problem. Security teams may have carefully approved one enterprise AI platform while employees independently create accounts with ChatGPT, Replit, Hugging Face, Notion AI, Zapier, Lovable, ElevenLabs, or dozens of other tools. Those accounts may be opened on personal devices, accessed from unmanaged browsers, or authenticated using reused passwords. The company may not know the account exists until its credentials appear in a criminal marketplace.

A stolen AI identity is also potentially more valuable than a conventional SaaS login because an AI account can combine several security roles at once. It may function as a searchable archive of corporate information, a paid compute resource, a developer environment, and an identity trusted by connected applications. Attackers stealing one session may therefore gain access to previous prompts, files, internal discussions, code, customer data, or strategic information that employees pasted into the service.

The conversation history itself can become the breach. Employees routinely use generative AI to summarize documents, troubleshoot source code, rewrite contracts, analyze customer information, prepare financial material, or discuss unreleased products. If an attacker replays a stolen browser session, the information may already be available without the attacker needing to penetrate any internal corporate system.

This risk is particularly serious when attackers steal session cookies rather than passwords. Multi-factor authentication is highly effective against many forms of credential theft, but a live session token represents an authentication event that has already succeeded. If malware steals that token and the provider accepts it from another device, the attacker may inherit the logged-in session without needing the password or MFA code. Resetting the password alone may not terminate that access unless active sessions are explicitly revoked.

That makes infostealer infections much more than a local malware incident. Once a corporate device appears in stealer logs, the appropriate response should include session invalidation across exposed SaaS and AI services, API-key rotation, browser-token revocation, and investigation of every credential accessible from that endpoint. Treating the incident as a simple password reset risks leaving the attacker logged in through stolen sessions.

AI APIs create another monetization path through LLMjacking. In this model, attackers obtain cloud or AI-service credentials and use the victim’s access to run expensive models without paying for them. Those credentials may also be resold through underground markets or aggregated behind proxy services so multiple customers can consume the victim’s AI quota. The victim receives the bill while the attacker receives the compute.

LLMjacking is conceptually similar to cryptojacking, but instead of stealing CPU or GPU capacity for cryptocurrency mining, the attacker steals access to commercial foundation models. Fortinet has documented cases where stolen AWS credentials were used to create new identities, subscribe to foundation models through AWS Marketplace, and begin consuming AI services. Sysdig has also documented attackers evolving from simple unauthorized model usage toward using hijacked AI resources as part of offensive agentic tooling.

The financial exposure can be substantial. Commercial AI APIs may support high-volume inference, code generation, image generation, embeddings, agent workflows, and other expensive workloads. Attackers can automate requests at a scale far beyond ordinary employee use. A stolen API key with generous limits can therefore create a significant bill before the organization notices an anomaly.

But direct cost is only one concern. A stolen API key can also provide cover. Malicious activity appears to originate from a legitimate customer account rather than attacker infrastructure. That makes attribution harder and can allow criminals to use premium models for phishing, malware development, vulnerability research, automation, or content generation while hiding behind the victim’s identity.

The exposure becomes even more serious where AI platforms are connected to other business applications. Automation and agent platforms may hold OAuth grants to email, CRM systems, file storage, source repositories, project-management tools, and databases. If the attacker steals the AI or automation session, they may inherit those delegated privileges as well.

A stolen Zapier or agent-platform account, for example, could potentially allow the attacker to create workflows that copy data from trusted SaaS systems to attacker-controlled destinations. Because the workflow operates through legitimate integrations, the resulting traffic may originate from a trusted cloud provider rather than a visibly malicious server.

This changes how organizations should think about AI identities. They are no longer merely application credentials. They can become identity bridges into other systems.

Developer-oriented AI tools create another layer of risk. Platforms such as Hugging Face and Replit appeared in the SOCRadar dataset, reflecting the growing overlap between AI usage and software development. Developer endpoints often contain Git credentials, cloud keys, .env files, SSH keys, package-registry tokens, and infrastructure secrets. An infostealer that compromises the same device can therefore collect both the AI account and the credentials needed to reach production systems.

The risk is particularly acute because AI API keys are often stored in plaintext configuration files. Developers may place keys in .env files, shell histories, notebooks, source-code repositories, or IDE settings. Check Point’s 2026 AI Security Report cited the Bissa Scanner campaign, which harvested AI credentials for providers including OpenAI, Anthropic, and Google from more than 30,000 exposed .env files.

That is a different initial-access mechanism from infostealer malware, but the end result is the same: AI credentials become another class of high-value secrets attackers actively search for.

The 80,000-domain figure should also serve as a warning about unmanaged endpoints. One employee using an AI account from a personal computer infected with commodity malware can create exposure for a billion-dollar organization. SOCRadar found that 68% of the 482 enterprises in its focused sample were billion-dollar organizations, demonstrating that corporate size and security maturity do not eliminate shadow-AI risk.

The issue is also not confined to technology companies. Although technology and Internet-service firms represented the largest share of the analyzed organizations, financial services, healthcare, industrial companies, retailers, and energy organizations were also significantly represented. In fact, the research found AI-platform exposure across nearly every sector, demonstrating that generative AI has become ordinary business infrastructure rather than a niche developer tool.

For CISOs, the first challenge is visibility. An organization cannot revoke an AI credential it does not know exists. Security teams therefore need to identify which AI services employees are using, which corporate identities are registered with them, which services are officially approved, and which accounts exist outside enterprise governance.

This should include discovery of shadow AI accounts, browser-based usage, API keys, OAuth applications, connected agents, and developer tools. Network and SaaS discovery can provide some of this visibility, but stealer-log intelligence can also reveal accounts that security teams never knew existed.

Once an account is identified, enterprise SSO should be used wherever supported. SSO removes the need for employees to maintain separate passwords and gives security teams centralized lifecycle control when staff leave or access must be revoked. However, SSO should not be treated as a complete solution because stolen live sessions can still bypass the initial authentication step.

Session lifetime therefore matters. Short-lived access tokens, refresh-token rotation, device binding, risk-based reauthentication, and rapid session revocation can reduce the usefulness of stolen cookies. Security teams should monitor for the same session suddenly appearing from a different country, ASN, device fingerprint, or impossible geographic sequence.

AI API keys should also be treated with the same seriousness as production cloud credentials. Keys should be stored in secret-management systems rather than documents or code, scoped to the minimum required permissions, assigned spending and rate limits, rotated regularly, and monitored for unusual usage patterns.

Organizations should establish budget alerts specifically for AI consumption. Sudden increases in model calls, unexpected geographic origins, unusual model selection, round-the-clock usage, or consumption that differs dramatically from an application’s historical pattern can indicate LLMjacking before the monthly invoice becomes the first detection system. Accounting departments have suffered enough indignity without being promoted to SOC tier one.

Endpoint security remains essential because much of this credential theft begins with commodity infostealers. Browser credential stores, cookies, developer configuration files, cryptocurrency wallets, password managers, and AI credentials are all harvested during the same infection. A strong AI governance policy does little if employees use approved accounts from infected personal devices.

Organizations should therefore restrict privileged AI access to managed endpoints, maintain current EDR coverage, monitor credential-stealer infections aggressively, and consider conditional-access policies that reject sensitive AI sessions from unknown or unmanaged devices.

When an employee is identified in an infostealer dataset, security teams should not ask only, “What password was stolen?” They should inventory every form of reusable authentication available from the endpoint: passwords, browser sessions, API keys, OAuth tokens, cloud credentials, developer secrets, and AI sessions.

The emergence of underground markets for AI access also means stolen accounts now have an established economic value. Criminal sellers advertise discounted access to AI services, API keys, and authenticated sessions. That creates demand, and demand encourages malware operators to add more AI-specific targets to their stealers.

The cycle is straightforward: corporate AI adoption grows → credentials become valuable → infostealers begin targeting them → underground markets monetize them → more criminals search for AI credentials. This is the same economic process previously seen with banking credentials, cryptocurrency wallets, cloud accounts, and gaming accounts.

The broader cybersecurity lesson is that AI adoption has quietly created a new identity perimeter. Security teams spent years learning that cloud identities, SaaS sessions, and API keys are as important as network passwords. AI accounts now belong in the same category.

The attack chain can increasingly look like:

employee adopts AI tool outside IT → logs in from unmanaged device → commodity infostealer steals session/API key → credential appears in criminal marketplace → attacker replays session → reads corporate AI history or consumes model resources → connected OAuth access enables further compromise

Nothing in that sequence requires compromising the AI provider itself.

The exposure follows the employee.

That is why choosing a “safer AI vendor” does not solve the underlying issue. If users create unmanaged accounts, store credentials on compromised systems, or paste secrets into browsers infected with stealers, attackers will follow them regardless of which model logo appears at the top of the page.

The most important shift for organizations is therefore conceptual: AI identities must be managed as enterprise identities, not consumer web accounts.

That means centralized discovery, SSO, managed endpoints, session controls, API-key governance, spending limits, OAuth monitoring, secret management, and rapid revocation after infostealer infections.

The 80,000+ organization figure sounds dramatic, but the underlying mechanism is remarkably ordinary. No futuristic AI attack is required.

One employee, one unmanaged device, one commodity infostealer, and one saved AI session can be enough to expose corporate data, identity, and compute.

The novelty is not how the credential is stolen.

The novelty is how much an AI credential may now be worth after it is.

Infostealer logs exposed AI account credentials and sessions tied to more than 80,000 corporate domains, creating risks ranging from stolen conversations to LLMjacking. SOCRadar examines the growing market for stolen AI logins and how organizations can identify their exposure. [...]

Source: 80,000+ Organizations Had AI Logins Stolen: From Shadow AI to LLMjacking via Bleeping Computer — published 28 Sep 2026.