Many small and midsized businesses have adopted multi-factor authentication (MFA) and rightly see it as a major security improvement. It is. MFA makes stolen passwords far less useful and blocks a large share of routine account takeover attempts.
But MFA protects the login process. It does not necessarily protect what happens after a user has logged in.
A recent analysis of information-stealer malware data illustrates the gap. Malware on employee devices can capture browser session tokens, API keys, and related authentication data for AI services and other cloud applications. Criminals can replay those tokens and act as the legitimate user—often without entering a username, password, or MFA code.
For businesses deploying ChatGPT, Gemini, Claude, coding assistants, and AI-enabled productivity tools, the question is no longer limited to whether employees use strong passwords and MFA. Leaders also need to ask what valuable access remains on an employee device after login, and what happens if that device is compromised.
A Session Token Can Act Like a Temporary Master Key
After a user signs in to a web application, the service typically gives the browser a session token. The token tells the application that the user has already authenticated. It allows an employee to move between pages, reopen a browser, and continue working without completing MFA every few minutes.
That convenience creates an opportunity for attackers.
Information stealers such as Lumma Stealer and Vidar are designed to collect data from infected computers, including saved credentials, browser cookies, session data, and API keys. The resulting “stealer logs” are sold in criminal marketplaces. A buyer does not need to infect a victim directly; they can purchase access data collected by someone else.
If an attacker obtains a valid session token, they may be able to replay it in a specially configured browser and appear to the AI provider as an authenticated user. MFA may have worked exactly as intended when the employee logged in. The attacker is reusing evidence that the login already occurred.
In the dataset examined by Okta, thousands of unexpired tokens appeared across a broad range of services, including major cloud, productivity, and AI platforms. Some tokens also contained personally identifiable information in readable form. That creates a second exposure: attackers can use the data to make later phishing or social-engineering messages more convincing.
Requiring MFA is not the end of the identity-security conversation. Passkeys and phishing-resistant MFA remain worthwhile because they reduce password theft and credential phishing. They do not, by themselves, make a stolen active session or exposed API key harmless.
AI Accounts Can Expose More Than Prompts
A compromised AI account can expose more than the account holder’s prompts. The impact depends on how the organization uses the tool.
An employee may have entered customer details, contract language, internal strategy, source code, financial information, or proprietary documents into an AI service. An intruder with access to that account may be able to view conversation history, files, custom assistants, integrations, or project settings, depending on the platform and subscription configuration.
API keys present a different but equally material exposure. They allow software to call AI models programmatically. A stolen key can generate large volumes of AI requests at the victim’s expense—a practice sometimes called LLMjacking. The result can be an unexpected bill, exhausted service limits, or use of the key to support an attacker’s own operations.
The same pattern applies to cloud infrastructure. Google has reported an incident in which an exposed GitHub personal access token gave an attacker an entry point into a cloud environment. The attacker deployed unauthorized AI infrastructure and scaled high-performance computing resources. For an SMB, runaway cloud consumption can become both a financial event and an operational disruption, particularly when critical workloads share the same environment.
There is also a customer-trust issue. Customers may accept that a business uses modern AI tools. They will be far less accepting if their information appears in an unauthorized account or a breach shows that access was loosely managed.
Protect the Device, Then Limit What a Stolen Secret Can Do
The answer is not necessarily an enterprise-scale security program. It is a focused set of controls that treats browser sessions and API keys as valuable business assets.
Start with the employee endpoints where tokens live. Keep operating systems, browsers, and browser extensions updated. Use managed endpoint protection and restrict local administrator rights where practical. Information stealers usually must run on a device before they can collect browser data. Reducing malware infections is central to protecting AI accounts.
Establish clear rules for company AI use. Identify approved AI services, who may use paid or administrative accounts, what business data may be entered, and whether employees may connect these services to email, cloud storage, code repositories, or other systems. Shadow AI makes it harder to revoke access, investigate exposure, or control spending.
Treat API keys like financial credentials. Do not place them in source-code repositories, shared documents, browser notes, or chat messages. Store them in an approved secrets-management tool or, at minimum, protected environment variables. Give each application or developer a separate key where possible. Apply spending and usage limits, and rotate or revoke keys promptly when an employee leaves, a device is infected, or a key may have been exposed.
Administrators also need the ability to terminate active sessions and revoke tokens quickly. For higher-risk accounts—AI administrators, cloud administrators, developers with production access, and finance users—consider controls that restrict access to approved networks or devices. IP allowlisting can reduce the usefulness of a stolen token, though it must be deployed carefully to avoid disrupting legitimate remote work. Short-lived tokens and OAuth-based access flows also reduce the period in which stolen session data remains useful.
Authentication is no longer only about proving who signs in. It is also about controlling the digital proof that remains afterward. As AI subscriptions, model access, and computing capacity become more valuable, attackers have more incentive to steal access rather than buy it. Businesses that manage sessions, keys, devices, and recovery processes accordingly will be harder and less profitable to target.