An infostealer now takes AI coding assistant keys. Map what one laptop's tokens can reach

Infostealers have always gone after whatever a laptop is logged into: browser passwords, session cookies, crypto wallets. On October 15, Symantec’s Threat Hunter Team reported that one of them now goes after something newer. Recent samples of a stealer called Aoki take the credential and session files that AI coding assistants keep on a developer’s machine.

At a small company, that laptop is often the same one that is logged into GitHub, the cloud console and the deploy pipeline. So the question for a security lead this week is simple to state: if one developer laptop were infected today, what could the stolen AI tokens open?

What Symantec found

Aoki is a fairly new stealer, first seen earlier in 2026. Symantec says older samples did not look for AI-related files, so this is a recent addition, and it “appears to be expanding.”

According to the report, the newest version collects:

• Claude: the .claude.json file and Claude desktop cookies.
• OpenAI: ChatGPT cookies, plus the Codex config.toml and .env files.
• Tokens for GitHub Copilot, Cursor, Google Gemini, JetBrains AI Assistant and Kiro.
• AWS credentials.

That sits on top of the usual stealer haul: dozens of browsers, more than 50 crypto wallet extensions, password managers, VPN clients, Discord tokens and Telegram data.

Symantec says the malware took credential, token and session files rather than source code. The exception it names is Cursor’s local state database, which can cache chat context and code snippets. Symantec detects the family as Infostealer.Aoki and published file hashes and command-and-control domains. The report does not say how Aoki is delivered, and it gives no infection counts.

Why an AI token is worth stealing

Symantec puts the risk in one line: stolen keys “allow malicious activity to be carried out under a legitimate developer’s identity and API quota.”

The report adds that those keys can expose the repositories, cloud services and CI/CD pipelines linked to the account, and may get past safeguards that assume a request comes from a trusted user.

That is the part that matters for a lean team. A coding assistant is rarely just a chat window. It is usually connected to the code host, sometimes to the cloud, and sometimes allowed to run commands. Its token inherits that reach. A commodity infection that once cost you a few saved passwords can now hand over a credential that exposes repositories, cloud services and CI/CD pipelines.

This also changes what “shadow AI” costs. An assistant someone installed without telling the security team is a policy problem. The same assistant with a long-lived token stored in a plain file is a credential you did not know you had to protect.

A test you can run on one laptop

Pick one developer machine, with the developer’s agreement, and spend an hour on this. The goal is a map of reach, not a forensic exam.

1. List the assistants. Which AI coding tools are installed or signed in? Compare with the list in the Symantec report above.
2. Find where each keeps its credential. Note whether it is a file in the home folder, a .env file in a project, a browser cookie, or the operating system’s keychain.
3. Trace what each credential reaches. For every token, write down which repositories, cloud accounts and pipelines it can read or change. Include anything reached through connected tools.
4. Check its lifetime. Does it expire? When was it last rotated? Is there one place to revoke it?
5. Check the neighbors. Are AWS keys or cloud CLI sessions stored on the same machine? Symantec lists AWS credentials in the same haul.
6. Score it. One decision rule keeps this short:

If a token on this laptop can push to a protected branch, change cloud resources, or trigger a deploy, treat it as a production credential.

Production credentials usually come with expected answers: who owns them, how long they live, where they are logged, and how fast they can be revoked. If the answers for an AI assistant’s token are “no one,” “forever,” “nowhere” and “not sure,” that is the finding.

What this test does not tell you

It does not tell you whether a machine is infected. That is the job of your endpoint tools and the indicators Symantec published. It also covers one laptop, not the fleet. Treat it as a sample that shows how big the gap might be, then decide how far to take it.

What to do this week

• Run the one-laptop test above and write down every token that scores as a production credential.
• Check that your endpoint tooling can use the hashes and domains in Symantec’s report.
• Add AI coding assistants to the list of credentials your offboarding and incident steps revoke.
• Ask your team which assistants they use, so the next inventory starts from an honest list.

If you want a draft acceptable-use policy for the AI tools your staff already use, and a short list of agent permissions to tighten, that is the kind of work we do in a consult block.