Stolen AI Session Tokens Bypass MFA: A CISO's Guide
By Yonatan Hoorizadeh CISSP, CISM, CRISC, AAISM
Published By: Purple Shield Security
Published: September 10, 2026
Last updated: September 10, 2026
Stolen AI session tokens let attackers skip passwords and MFA entirely because the token proves a login already happened. In one 7 GB infostealer dump, Okta found 555 JSON Web Tokens (JWTs) likely tied to AI authentication and 24 still-valid AI API keys. Businesses should put AI tools behind SSO, shorten session lifetimes, and rotate AI keys now.
What did Okta find in the infostealer logs?
Okta found 555 JSON Web Tokens (JWTs) likely tied to AI service authentication and 24 still-valid API keys for AI services inside a single 7 GB infostealer dump, The Hacker News reported this week. Infostealers are malware that quietly copy saved passwords, browser cookies, and session tokens from an infected computer and send them to criminals, who resell the bundles as ready-made access kits.
A JWT is a signed digital pass that a web application issues after a user logs in. The AI service checks the pass on every request instead of asking for the password again. If an attacker replays that pass from another machine, and the service doesn't check where the request comes from, the service treats the attacker as the employee.
Infostealer volume is large enough that Okta's finding will repeat across many companies. Constella Intelligence's 2026 Identity Breach Report processed 51.7 million infostealer packages in 2025, a 72% increase over the prior year, according to a CybelAngel analysis of the report. Constella found that 98.6% of those packages contained active passwords.
Infostealer operators have also started aiming at AI tools directly. The OECD AI Incidents Monitor logged a February 2026 case, first reported by TechRadar, in which infostealer malware took configuration files, keys, and memory logs from the OpenClaw AI assistant.
How can a stolen AI session token bypass MFA?
A stolen AI session token bypasses multi-factor authentication (MFA) because MFA only guards the moment of sign-in. After a user enters a password and approves the MFA prompt, the AI service issues a session token so the user isn't challenged on every click. An attacker who copies that token from an infected laptop inherits the finished login, including the MFA step the real user already completed.
AI API keys are a separate and often more dangerous exposure. An API key is a long-lived credential that developers use to connect applications to AI platforms such as OpenAI or Anthropic. API keys have no MFA at all and usually keep working until someone rotates them, which is why the 24 still-valid AI API keys in Okta's sample matter as much as the tokens.
Session theft through an employee's personal footprint has caught identity companies too. In Okta's own 2023 support-system breach, which exposed files tied to 134 customers, Okta chief security officer David Bradbury said an employee "had signed-in to their personal Google profile" on a company laptop where a service account password was saved, Dark Reading reported. Personal browser profiles on work devices remain one of the most common paths from one infection to company-wide access.
Why is an AI workspace a bigger prize than a typical SaaS login?
An AI workspace is often a bigger prize than a typical SaaS login because employees paste their most sensitive work into it. Chat histories hold contract drafts, financial models, patient summaries, and strategy memos that were never meant to sit in one searchable place. A replayed AI session token hands an attacker that history, plus any email, file, or CRM connectors the user has authorized.
Connectors widen the exposure. Many business AI tools now link to Microsoft 365, Google Workspace, SharePoint, or Salesforce so the assistant can search company files and draft from them. A token for an AI account with those connectors can work as a side door into systems the identity team hardened separately.
Most companies have never classified AI chat history as a data store. AI tools rarely appear in the data inventory, the retention schedule, or the incident response plan. As a result, a token replay against an AI tool may never be investigated as a possible breach, because nobody thought of the AI tool as a place where regulated data lives.
The controls that matter most here are identity controls: who can sign in to each AI tool, from which devices, for how long, and what the tool is connected to. Solid AI security services start with that inventory of tools, accounts, and connectors before anyone debates model risk. That sequencing is the practical core of AI security governance for a mid-market firm.
Which companies are most exposed to AI token theft?
Companies are most exposed to AI token theft when employees use AI tools on personal accounts or personal devices, when AI tools sit outside single sign-on (SSO), and when developers keep AI API keys in code or local files. Regulated firms in healthcare, legal, and financial services face the highest consequences because data in AI chat histories can trigger notification duties.
For HIPAA-covered entities and business associates, a replayed token against an AI tool that holds protected health information (PHI) is a potential breach. Under the HIPAA Breach Notification Rule, unauthorized access to PHI is presumed reportable unless a documented risk assessment shows a low probability that the data was compromised.
For law firms, American Bar Association Model Rule 1.6(c) calls for reasonable efforts to prevent unauthorized access to client information. A firm that allowed attorneys to use personal AI accounts for client matters will struggle to explain that choice after an infostealer incident.
For companies of roughly 50 to 500 employees with an IT team but no security leader, AI token risk tends to fall between chairs. IT owns the identity provider, legal owns the confidentiality obligations, and nobody owns the AI tools. Fractional CISO services fit this gap: a part-time security executive sets the AI access policy, assigns owners, and reports the risk to leadership in business terms.
For companies under 50 people, the priority is simpler. Pick one sanctioned AI tool that supports SSO and business-grade data terms, move everyone onto it, and remove the personal accounts from company devices.
How would a vCISO triage an AI token exposure in the first 72 hours?
A vCISO (virtual Chief Information Security Officer) treats any infostealer infection on a device used for AI tools as a compromise of every AI account on that device. The first 72 hours focus on three jobs, in order: revoke sessions and keys, scope what the attacker could see, and decide whether legal notification obligations apply.
In the first 24 hours, the priority is containment. Revoke all active sessions for the affected user in the identity provider and inside each AI tool, because many SaaS and AI applications keep their own sessions alive after an SSO logout. Rotate every AI API key that lived on the device or in any repository the user could reach.
Between 24 and 72 hours, the priority is scoping. Pull the AI tool's audit logs where the subscription tier provides them, look for sign-ins from unfamiliar devices or locations, and list every connector the account had authorized. The connector list shows whether the incident stays inside the AI tool or reaches email, files, and customer records.
The step most teams skip is the notification analysis. If the chat history or connected systems held regulated data, legal counsel needs the facts early enough to meet HIPAA, state breach law, or contractual notice deadlines.
Purple Shield Security runs this playbook through its vCISO services, and the playbook only moves fast when AI tools are already written into the incident response plan before an infection happens. Adding AI accounts to the plan takes an afternoon. Figuring it out during an incident takes days.
What your business should do this week
This week, a business should find out which AI tools employees actually use, put the sanctioned ones behind SSO with device checks, shorten AI session lifetimes, and move AI API keys into a secrets manager. Most mid-market firms can do all of this with settings already available in Microsoft Entra ID, Okta, or Google Workspace, without buying new software.
Inventory AI use, including personal accounts. Ask teams what they use, then check your identity provider's OAuth app grants for AI tools that employees connected on their own. The gap between the two lists is your shadow AI exposure.
Require SSO for every business AI tool. Choose the subscription tiers that support SSO so a single revocation in your identity provider reaches the AI tool.
Tie AI sessions to managed devices and shorten their lifetime. Use conditional access to block unmanaged devices, enable token protection where your identity provider offers it, and require reauthentication at least daily for AI tools with sensitive connectors.
Separate work and personal browser profiles. Block personal Google or Microsoft account sign-ins in browsers on company laptops, the same fix Okta applied after its 2023 breach.
Rotate and vault AI API keys. Move keys out of code, .env files, and developer laptops into a secrets manager, and set spend alerts, since an unexpected usage spike is often the first visible sign of a stolen key.
Write AI tools into the incident response plan. Add a line item: any infostealer finding on a device triggers AI session revocation, key rotation, and a connector review.
Monitor for your domain in stealer logs. Many identity providers and breach intelligence services now flag company accounts that appear in infostealer dumps. Turn that feature on and route alerts to someone who owns them.
Frequently asked questions
Does MFA stop someone who steals my AI session token?
No. Multi-factor authentication runs at sign-in, and a stolen session token represents a sign-in that already passed MFA. Phishing-resistant MFA such as FIDO2 passkeys does block the phishing-proxy route to token theft, but it does not stop an infostealer that copies a token off the laptop after login. The controls that limit replay are device-bound sessions (for example, token protection features in Microsoft Entra ID), short session lifetimes, and conditional access that rejects unmanaged devices.
How do I know if an employee's AI session token has been stolen?
Most companies find out indirectly. The usual signals are an endpoint detection alert for infostealer malware, a breach intelligence service flagging your domain in a stealer log, AI tool audit logs showing sign-ins from an unfamiliar device or location, or an unexplained jump in AI API spending. Treat any confirmed infostealer infection as token theft for every application that device had signed into, including AI tools, and act before you have proof of misuse.
Is a replayed AI session token a reportable data breach?
It can be, and the answer depends on what the AI account held or could reach. Under the HIPAA Breach Notification Rule, unauthorized access to protected health information is presumed reportable unless a documented four-factor risk assessment shows a low probability of compromise. State laws such as California Civil Code Section 1798.82 turn on the specific personal information exposed. Bring legal counsel in within the first few days so notice deadlines don't run out while IT is still scoping.
Should we ban personal AI accounts at work?
A ban with no approved alternative usually pushes AI use onto personal phones, where you have even less visibility. The order that works is to give employees one sanctioned AI tool with SSO and business data terms, then block personal-account sign-ins to AI services on company devices, then write the policy. Enforcement through the identity provider and browser management holds up far better than a policy memo alone.
If your team can't say with confidence which AI tools hold company data or who can sign in to them, that's the place to start. Purple Shield Security's AI security services begin with exactly that inventory, and our fractional CISO and vCISO services turn the findings into an access policy your leadership can defend to a client, an auditor, or a regulator.
