Our analysis of recent information-stealer collection rules found a much newer category alongside the familiar browser, wallet, and credential targets: local data associated with Claude, Cline, Codex, Continue, Cursor, OpenCode, and other AI-assisted development tools.
This was not an isolated experiment: over a three-month period, our Windows telemetry recorded Amatera and Remus detections among tens of thousands of protected users. Amatera targets data associated with Cline and Continue, while Remus targets Claude, Cursor, and OpenCode. The figures may overlap and describe detections rather than successful infections, but they show that AI agent data has already entered the information-stealer economy.
What the malware is collecting goes far beyond harmless preferences. Depending on the agent and its configuration, local files may contain access and refresh tokens, credentials stored in MCP configurations, prompt histories, conversation databases, account details, and traces of the projects a developer has been working on. In one archive, an attacker may obtain both the means to access an account and the context needed to understand what is valuable behind it.
Our findings focus primarily on locally installed coding agents and agentic developer tools, and they do not point to a new way of compromising the device or to a vulnerability in an AI model or agent. The information stealer is already running; what has changed is the concentration of valuable information in predictable locations, sometimes in plaintext, and the ease with which those locations can be added to an existing collection list.
The collection rules have already changed
CallbackBeaver, a fast-emerging stealer, has added Cursor and Claude to its collection scope, and we observed more than 5,000 samples during a recent 30-day period. Lower-prevalence families, including BeeStealer, STG Stealer, HydraStealer, APEX Stealer, and Otter Stealer, show that the behavior is spreading beyond one or two larger operations The pace of adoption is striking, with AI agent data appearing in the collection rules of another stealer almost every day.
The same behavior is visible across operating systems, with Djinn Stealer on macOS associated with collecting data from Claude, Codex, Gemini, Cline, OpenCode, and Kilo.
The reconstructed rules below show how directly several AI-assisted development tools have been added to a stealer's collection scope. The list is a snapshot rather than a complete map of the ecosystem, but it makes the change visible: agent data is now sitting alongside the targets that information stealers have pursued for years.
The targeting of AI agent data is emerging within a much larger infostealer problem. During the first half of 2026, our telemetry recorded infostealer detections among more than 3.3 million unique protected users, with the monthly number consistently exceeding 500,000. These figures cover all infostealer families, not only those known to target AI agent data, but they show the scale of the ecosystem in which this behavior is spreading.
Access and context in the same archive
An agent's local directory contains far more than interface preferences. The exact files, paths, and protections differ between products, operating systems, and user settings, but the material we found falls into two broad categories: access to accounts and connected services, and context that can compromise a user’s privacy by revealing who they are and what they are working on.
Some agents cache access tokens or other login details locally so that the user does not have to authenticate for every session. An access token may let an attacker use the account until it expires, while a refresh token can sometimes be exchanged for new access tokens and extend the window of abuse. Stolen tokens can be used to consume paid API capacity, while working access to an account may be packaged and resold so that someone else can use a commercial AI service at the victim’s expense. The outcome depends on the token's scope, lifetime, and the service's own controls, so stealing a file does not guarantee lasting access, but the file can still be as sensitive as a password store.
The Model Context Protocol, commonly known as MCP, can extend that access beyond the AI service. It allows an agent to connect to external tools and data sources, and local configurations may include endpoints, headers, environment variables, API keys, or other authentication details. A stolen configuration does not automatically unlock every connected service, because some integrations use short-lived credentials, OS-protected storage, or an interactive authorization flow. Where reusable secrets are stored locally, however, the compromise may reach source control, ticketing platforms, databases, cloud services, or collaboration tools connected to the agent, potentially broadening the attack surface.
The context can be just as valuable, because developers use AI assistants to review code, interpret logs, troubleshoot incidents, summarize internal documentation, and reason through unfinished work. Their prompts and transcripts can contain proprietary source code, repository names, internal hostnames and API keys or other secrets pasted into a conversation. If an employee has used the assistant while developing a confidential proof of concept, the stolen history could expose an unpatented invention or another trade secret, with consequences far beyond the theft of an AI account. A transcript may also provide reconnaissance that an attacker would otherwise spend days collecting, including the structure of a codebase, known technical problems, security tooling, and the people involved in a project.
Local data may also expose an email address, account or organization identifiers, display name, subscription type, billing status, seat tier, rate limits, user preferences, and a history of recent files or projects. None of these fields is as dramatic as a token, but together they can undermine the user’s privacy by building a detailed picture of who they are and what they do. Combined with personal information stolen elsewhere from the device, they may also contribute to identity theft, while helping criminals identify valuable victims and make targeted/spear phishing or extortion attempts more convincing.
The danger lies in combining access with context: a browser cookie can open a door, but an AI-agent archive may also tell the attacker whose door it is, which projects are behind it, and which connected systems may be reachable from the same workspace. Incident responders should therefore treat agent credentials and local histories as part of the broader identity and access surface, not as an isolated AI account.
Adding the next agent may take one configuration update
Many information stealers already receive remotely managed collection rules specifying directories, filenames, extensions, databases, search depth, or file-size limits. Once an operator learns where an agent stores useful data, expanding that list can be as simple as adding another path.
The malware may not need to be rebuilt or redistributed. An updated rule can be delivered to existing installations, allowing the operator to start collecting a newly popular agent's files across already compromised devices. This does not apply to every stealer, and some tools need product-specific parsing or decryption, but the basic barrier to entry is low when the target is a predictable local file.
If a major stealer does not collect a particular agent today, its absence from the list should be treated only as a snapshot, not as evidence that the agent will remain outside the collection scope once criminals see enough users, valuable accounts, or resale demand.
What users and security teams should do
AI-agent data should be included in the same security conversations as browser profiles, developer credentials, password stores, and cloud command-line tools. The response needs to cover both prevention and the actions taken after a suspected stealer infection.
- Know what is stored locally. Inventory the agents in use, review their retention and history settings, and understand where they keep credentials, conversations, project records, and MCP configuration.
- Prefer protected credential storage. Where a product offers a choice, use the operating system's credential store, keychain, or keyring rather than file-based token storage. A local authentication file containing access tokens should be treated like a password.
- Keep secrets out of prompts and histories. Avoid pasting passwords, private keys, API secrets, or customer data into a conversation. If a secret has been exposed for troubleshooting, rotate it and remove the retained conversation where possible.
- Limit what connected tools can do. Give MCP integrations only the permissions they need, favor short-lived and narrowly scoped tokens, and separate personal, development, and production access. Review old servers and revoke connections that are no longer used.
- Protect the endpoint. Keep the operating system and applications updated, use reputable endpoint protection, and be particularly cautious with ClickFix/FakeCaptcha instructions, cracked software, unofficial installers, and other common routes used to deliver information stealers.
- Expand incident response. After a stealer infection, changing browser passwords alone is no longer enough. From a clean device, revoke AI-service sessions, rotate API keys and other credentials used by MCP connections, review connected applications and account activity, and assess whether local prompts or transcripts exposed company information. Multi-factor authentication remains important, but it may not stop abuse of a session token that has already been stolen.
Safer defaults have to come from the products too
Users cannot carry this responsibility alone, so agent developers should minimize the amount of sensitive information kept locally, separate authentication material from ordinary history, use OS-protected credential storage wherever possible, and make retention controls easy to find and understand. Tokens should be short-lived, scoped to the smallest practical set of permissions, and simple to revoke. MCP connections need equally clear visibility, so users and administrators can see what is connected, what it can access, and when it was last used.
Encryption at rest can help, but it should not become a reassuring label without a threat model behind it. If the decryption key is stored beside the database, or the application automatically unlocks everything for any process running as the user, an information stealer may still obtain the data. Reducing what is retained and limiting the value and lifetime of credentials are just as important as encrypting the file.
AI agents are becoming a new layer of working memory on our devices, storing not only what we ask them, but also who we are, what we are building, and which services we have allowed them to reach. Information stealers have already adjusted their collection rules to reflect that value, and because another agent can sometimes be added with a simple configuration update, the target list will continue to change as adoption grows.
Once an AI agent holds credentials, conversation history, and a map of the user’s work, its local files are no longer merely configuration. They have become another high-value data store on the device, and attackers are already treating them that way.
