In early September, Google's Threat Intelligence Group disclosed that a financially motivated attacker used an AI coding chatbot and a single written prompt to plan, build, and run a credential-harvesting campaign against developer tools and cloud accounts — in under six hours, with no human working through the steps by hand. The resulting dashboard held more than 23,800 stolen credentials. Days earlier, a separate and unrelated incident showed the mirror-image risk: ordinary infostealer malware sitting on a user's computer lifted the browser session cookie keeping their AI account logged in, letting the attacker act as that user without ever touching a password or an MFA code.
Neither story is really about one AI vendor having a bad week. Together they point at two distinct new failure modes that didn't exist before AI coding tools sat inside a normal software team's workflow: what the tool can reach once it's connected, and what happens when someone else gets hold of the tool's own access. Most teams adopting these tools think hard about the first risk and skip the second entirely.
What actually needs checking before you connect it
The GTIG campaign's credential stealer dropped its files into hidden folders such as .claude and .cursor — the same folders many AI coding assistants use for their own configuration — specifically because that location reads as ordinary tool clutter rather than something worth a second look. That's the pattern worth building a habit around, not the specific vendor names:
- Scope, not the whole repo. Most tools default to reading an entire codebase, including any
.envfile or service-account key sitting in it. Point the tool at the working directory or branch the task actually needs. - Know what secrets are reachable. Before connecting a tool, check what it could read from where you've scoped it — the same blast-radius question we apply to keeping email off a shared hosting account.
- Route the account through SSO where the vendor supports it. A session tied to your identity provider can be revoked centrally the moment a device looks compromised, instead of one more scattered login nobody remembers to close.
- Treat unfamiliar files in a tool's config folder as worth investigating, not routine clutter to ignore, given what's already been found hiding there.
- Review AI-authored changes the same way you'd review a human's, especially anything touching CI/CD secrets or deployment config — don't fast-track it because a person didn't type it.
This isn't a reason to avoid the tools
We use AI coding assistants on our own work, including client codebases. The point of this checklist isn't caution for its own sake — it's the same discipline we'd apply to any third party that needs access to a client's code: scope it narrowly by default, expand only when the job genuinely needs more, and never assume "it's an AI tool" makes the access question different from handing a new contractor the keys on day one. The tools are useful precisely because they can reach a lot of a codebase quickly; that's also exactly why the access they hold is worth deciding on purpose rather than accepting whatever the default happens to be.
Frequently asked questions
Does this mean AI coding tools are unsafe to use?
No — we use them ourselves. The risk isn't the tool, it's giving any tool the same blanket repo and credential access you wouldn't hand a new contractor on their first day. Treat it as an access-scoping problem, not a reason to avoid the category.
What's the single biggest thing to check first?
Scope. Most AI coding tools default to reading an entire repository, including .env files and service-account keys sitting in it. Point it at the specific working directory or branch the task actually needs, not the whole codebase, and check what secrets are reachable from there.
How is this different from a security code review?
A security code review checks how the application itself handles untrusted input, authentication, and data — see our guide on what a security code review actually checks. This is about the access an AI tool holds while it works on that code, a separate question from whether the code it writes is safe.
What should I do if I find an unexpected file in a .claude or .cursor folder?
Investigate before assuming it's routine tool clutter. Researchers have documented credential-stealing malware planted inside these exact folders specifically because they read as ordinary AI-assistant configuration. If anything there is unexplained, treat it as a possible compromise and rotate whatever credentials the tool had access to.
Does putting an AI tool's account behind SSO actually stop this kind of attack?
It narrows the blast radius — a session tied to your SSO provider can be revoked centrally the moment a device looks compromised, instead of you tracking down one more scattered login. It doesn't replace scoping access narrowly or reviewing what the tool changed; it's one layer, not the whole answer.