If you think “it’s just a ChatGPT login,” you’re already behind. SOCRadar tied over a million infostealer records to AI services across 80,000+ corporate domains, then narrowed it to 482 major enterprises to see what attackers actually get when they buy a stolen AI login . Spoiler: it’s not just a password. It’s your team’s prompt history, live sessions that can sidestep MFA, OAuth grants that reach into other tools, and API keys that can rack up bills and quietly move data. This post breaks down what’s happening, why it’s different from the old “reset the password” playbook, and what a CISO can do this week to cut the risk hard.
What the SOCRadar report actually showed (and why it should bother you)
SOCRadar’s AI Identity Exposure Report (2026) didn’t start with a neat, curated list of “AI breaches.” It started with the messier reality: more than one million infostealer records tied to AI services, spread across 80,000+ corporate domains.
Then it narrowed the analysis down to something security leaders can’t shrug off as “random noise”: 482 major enterprises, many of them large, mature, and global. Within that subset alone, SOCRadar found:
- 5,434 stealer-log records
- tied to 1,500 distinct corporate email addresses
- with 295 of the 482 enterprises showing up in just the last 90 days
Read that again. This isn’t “old data from 2023 resurfacing.” It’s fresh, active credential theft hitting organizations right now.
The part most teams misread: “ChatGPT dominates” doesn’t mean “ChatGPT is uniquely weak”
When SOCRadar broke the dataset down by AI platform, ChatGPT/OpenAI sessions appeared in 358 of the 482 companies, representing roughly 90% of all records in the study. That kind of skew makes people jump to the wrong conclusion: “So OpenAI is the problem.”
SOCRadar’s own framing is more uncomfortable, and more useful: this is a shadow AI signal. ChatGPT’s footprint is huge because employees sign up fast, often with a work email, and often on devices your IT team doesn’t manage. Infostealers don’t “hack OpenAI.” They quietly scrape what’s already sitting on the endpoint.
Also telling: other big-name assistants didn’t top this chart, not because attackers ignore them, but because volume drives harvesting—the moment a platform has enough adoption, it becomes worth scraping at scale.
Why this should bother you even if you “don’t allow ChatGPT”
If your policy says “no unsanctioned AI,” but your domain is in infostealer logs, the policy isn’t protecting you. It’s just paperwork.
What these numbers point to is a simple pattern:
- Employees use AI tools to move faster.
- Some of that use happens off the books (personal laptops, unmanaged browsers, saved sessions).
- Infostealer malware turns that everyday behavior into an account takeover pipeline.
If you want a practical gut-check, this is where tools that reduce account sprawl and limit what an attacker can reuse start to matter. For example, using a service like Cloaked to create separate identities (emails/phone numbers) for signups can reduce how often your real corporate identifiers end up sprayed across external services. It doesn’t replace SSO or endpoint security, but it helps cut down the “work email + random SaaS/AI account” problem that shadow AI thrives on.
The takeaway from SOCRadar isn’t “panic.” It’s: treat AI logins like real enterprise identity. Because attackers already do.
Why stolen AI sessions hit harder than stolen passwords
Once an attacker gets a stolen AI session (not just a password), they aren’t just logging into “one more SaaS app.” SOCRadar’s framing is blunt: an AI account behaves like four assets at once—a searchable archive, an execution engine, a billable resource, and an identity. A replayed session can hand over all of it without another login prompt.
1) Conversation history becomes a data vault
This is the quiet part. Teams treat prompt threads like scratch pads.
SOCRadar calls out what’s living in those threads in real life: source code, customer records, contracts, unreleased plans.
If a stolen session includes access to that history, you’ve got exposure before an attacker ever touches your internal systems.
What makes it worse: people rarely classify a prompt the way they’d classify a document.
2) Session cookies can sidestep MFA
MFA helps when an attacker is trying to authenticate. A stolen session cookie is different—it’s often already authenticated.
SOCRadar puts it plainly: “A stolen cookie is a live session.” And it quotes Okta’s Jeremy Kirk’s point that session tokens and API keys are attractive because they can be replayed to bypass credential-based authentication.
The nasty operational surprise: rotating the password can still leave the intruder signed in.
3) OAuth and agent/automation abuse: “acting as the employee”
Even if the AI tool itself looks contained, the ecosystem around it isn’t.
Automation platforms commonly hold standing access into email, storage, CRM, ticketing—through OAuth grants. SOCRadar highlights the risk in one line: a stolen Zapier session can be used to build a workflow that exports data on a schedule, and it may even run from a vendor’s trusted IP space.
This is why AI credential theft keeps showing up as “nothing happened” right up until it’s too late. It can look like normal automation.
4) API key theft enables LLMjacking (and the bill shows up later)
Passwords get you in. API keys let you run.
SOCRadar notes that keys copied into a notes app or stored in workspace settings can be stolen alongside everything else, then billed to the victim or resold. It also points to underground markets selling discounted access and even “money-back guarantees.”
That’s LLMjacking in practice: stolen AI API keys used for capacity, cash, and cover.
A simple risk reducer that’s easy to miss
A lot of this starts with “someone signed up fast with a work email.” If you can reduce where your real corporate identifiers are used, you reduce what shows up in infostealer logs.
That’s one of the practical places a tool like Cloaked fits: using masked emails/identities for non-approved signups helps limit how often an employee’s real work email becomes the anchor for yet another AI account that security can’t see.
Who’s getting hit (and what that says about your exposure)
If you’re still thinking “this is a tech-company problem,” the sector breakdown should snap you out of it.
SOCRadar found technology and internet-services firms were the biggest cluster: 144 companies accounting for 40% of all stealer-log records in the report’s enterprise dataset.
That’s not shocking. Tech teams are heavy AI users, and they sit on credentials and customer data for everyone else.
What should bother you is what comes next: industrials, financial services, retail, healthcare, and energy all show up heavily too.
Translation: “We’re not a software company” doesn’t buy you safety. It just changes what data gets exposed when the account is taken.
Why sector matters: your blast radius changes by tool type
The report isn’t only about who’s hit. It hints at how the damage plays out.
LLM platform exposure is basically universal
Across sectors, LLM-platform exposure is near-universal, and SOCRadar flags energy as the highest point: 93% of affected energy companies had LLM platform exposure.
For most orgs, this means the baseline risk is always present:
- staff pasting internal material into prompts
- stolen AI logins turning into fast access to that history
Agent/automation exposure concentrates where workflows are dense
SOCRadar calls out something even more operationally risky: agent and automation exposure (the kind that can move data between tools using standing access) is concentrated in healthcare, financial services, and technology.
If you’re in one of those sectors, assume attackers aren’t just looking for an AI chat window. They’re looking for:
- automation accounts tied to email/CRM/storage
- long-lived connections that keep working while everyone’s staring at password resets
What this says about your organization (even before you look at logs)
A clean way to read this:
- If you’re tech/internet services: high likelihood of employee AI usage + developer-adjacent tooling exposure.
- If you’re healthcare or financial services: watch for “helpful” automations that quietly become a data-export pipeline when a session is stolen.
- If you’re energy/industrial: don’t assume lower AI usage equals lower risk—LLM exposure still shows up at scale.
One small but practical signal: if your users are signing up for AI tools outside approved channels, your corporate email becomes the common thread across dozens of third parties. Using masked identities (like Cloaked emails) for non-approved signups can reduce how often your real domain and employee emails get reused as the “account key” across tools—less linkage, less sprawl, less to clean up later.
CISO-ready action plan (what to do next week, not next quarter)
At this point, it’s not about convincing people to “stop using AI.” It’s about treating AI platforms like identity-critical systems, because attackers already do. SOCRadar’s point is simple: the controls aren’t fancy, but they need to be applied in the right order.
1) Lock down identity and sessions (stop treating AI tools like casual SaaS)
Goal: make stolen sessions harder to reuse and easier to kill.
Do these three moves:
- Put every AI platform behind SSO (OAuth2/OIDC).
This is table stakes. SOCRadar explicitly recommends putting AI platforms behind SSO and treating them in the same tier as your IdP and code repos.
- Enforce short-lived sessions + refresh-token rotation.
SOCRadar calls it out directly: use OAuth 2.0 / OIDC with refresh-token rotation so a stolen cookie expires before it can be sold.
Practical note: SSO doesn’t magically fix existing risk—it removes saved passwords, but doesn’t automatically invalidate already-stolen live session cookies, and it won’t cover accounts created before the policy.
- Add detection for session-token reuse.
SOCRadar’s detection hint is clean: if a session changes country or device fingerprint mid-life, treat it as a replayed session.
2) Kill the easy money (keys, bots, and shadow accounts)
Attackers go where the work is minimal and the payoff is predictable.
A. Inventory and remove shadow AI accounts
You can’t rotate or shut down what you don’t know exists. SOCRadar’s advice: find the shadow accounts first, starting with whether your domains already show up in stealer logs.
Two fast checks you can run internally this week:
- Do we have unsanctioned signups tied to our corporate domains?
- Do we have AI accounts outside SSO coverage (created before policy, personal devices, personal browsers)?
This is also where identity sprawl quietly hurts you. If employees keep using their real work email for random tools, every infostealer harvest becomes a cleaner map of your org. A lightweight mitigation some teams use is Cloaked for masked emails/identities when experimenting with non-approved services. It won’t replace SSO, but it can reduce how often your real corporate identifiers become the “glue” across shadow accounts.
B. Scope, cap, and rotate API keys (and watch for LLMjacking signals)
SOCRadar’s prescription is direct:
- Scope/cap/rotate API keys
- Alert on usage from unfamiliar ASNs or at odd hours—a common LLMjacking fingerprint
Keep it tactical:
- Put expiration on keys where possible.
- Reduce key permissions to the smallest workable set.
- Track who owns each key and where it’s stored.
C. Treat stealer-log hits as endpoint compromise, not “password reset”
SOCRadar’s warning matters because it’s the mistake teams keep making: if an employee shows up in stealer logs, handle it as an endpoint incident, not just an account hygiene task.
That means isolating the device, checking persistence, reviewing browser session stores, and looking for follow-on access attempts.
