When Malware Borrows Your AI Coding Agent to Find Your Secrets

The QUIETVAULT supply-chain malware, a credential stealer delivered through npm compromise reported by Mandiant in their M-Trends 2026 report, is a clear example of AI coding agents and other AI developer tools being turned into attack surface. Instead of carrying its own secret-hunting logic, it asks AI command-line tools already present on a compromised machine to do its work: find configuration files, with secrets like tokens for GitHub and the npm package registry. And it’s a pattern we’ve seen repeated, with the Nx s1ngularity incident following eerily similar patterns.

But the good news is that this isn’t a whole new attack, just a clever variant on using a compromised host’s installed tools against it. And that means the controls that limit this risk are familiar.

QUIETVAULT lives off the land, and the land has AI features

In my last post, I argued that the incident data doesn’t show AI creating “super attackers,” but does show AI tools becoming new attack surface inside organizations. And this variant on an old malware tactic is a perfect example of that.

Mandiant and the Google Threat Intelligence Group (GTIG) describe a credential stealer called QUIETVAULT in their M-Trends 2026 report. It arrived through a compromised npm package. Once active, it checks whether an AI command-line interface (CLI) tool is installed, and if so, it runs a predefined prompt that has the tool search for configuration files. Then it tries to collect GitHub and npm tokens and copy them to a publicly accessible GitHub repository.

The tactic is familiar: making use of tools and facilities already on a compromised host is called “living off the land,” and we’ve seen it before in supply-chain malware. For example, the paperclip-host-utils compromise, disclosed in July 2026, used the common local find utility to identify files likely to contain credentials. What’s new is the use of local AI tools specifically. This likely exploits the reduced scrutiny many organizations give to local AI agents: a suspicious find command might trigger an alert, but AI agents searching for files are likely to be ignored by most endpoint controls.

• It’s not a new tactic. It’s still living off the land, just using AI tools rather than common system utilities.
• It’s not a new goal. Obtaining and exfiltrating credentials is a well-established adversary goal.
• It doesn’t require new controls. Well-designed secrets management, well-configured endpoint controls, and a strong least-privilege approach together provide significant resistance.

Why QUIETVAULT is significant

Mandiant’s report includes the result of their investigation into an npm supply-chain compromise that led to QUIETVAULT being installed. M-Trends lists it as an example of threat clusters relying on AI tools inside the compromised environment, not just using AI for reconnaissance, social engineering, or malware development; and I agree.

The behavior, as Mandiant describes it, is a short chain:

• A compromised npm package installs QUIETVAULT.
• QUIETVAULT checks the machine for installed AI CLI tools.
• If it finds one, it runs a predefined prompt to search for configuration files.
• It attempts to collect GitHub and npm tokens.
• If it finds tokens, it copies them to a publicly accessible GitHub repository.

Unfortunately for defenders, M-Trends doesn’t name the compromised package, list which AI CLIs QUIETVAULT looks for, or publish the prompt. That means we haven’t analyzed a QUIETVAULT sample ourselves, and we’re relying on Mandiant’s internal analysis, sourced from their investigative engagements. So while it’s a good example of how adversaries can capitalize on AI tool attack surface, it doesn’t really tell us how common similar tactics are.

But it certainly isn’t the only example.

A similar attack: Nx and s1ngularity

There’s no direct evidence that QUIETVAULT is the malware from the Nx compromise. But the Nx incident, nicknamed s1ngularity, is well documented enough to highlight the similarities with QUIETVAULT, which makes it useful for seeing the pattern.

In August 2025, malicious versions of the Nx build tool (a very popular open-source build system for TypeScript and JavaScript-focused monorepos) were published to npm. According to Infosecurity Magazine’s coverage, the malicious code invoked AI coding agents (and possibly other AI CLI tools) installed on the machine, including Claude, Gemini, and Amazon Q. A purpose-built prompt told them to scan for sensitive files. The targets included GitHub and npm tokens, SSH keys, and environment variable secrets.

Exfiltration through the victim’s own account

The Nx malware didn’t send data to a server the attacker controlled. Kaspersky’s analysis describes it using stolen GitHub tokens to create a public repository in the victim’s own account, named s1ngularity-repository, and upload a single encoded results file. That removed the need for attacker infrastructure, and the traffic went to the GitHub API, a destination most organizations allow. QUIETVAULT’s copy-to-a-public-repository step, as Mandiant describes it, looks similar.

Scale, and the root cause

BleepingComputer, citing Wiz, reported that the incident exposed data from 2,180 accounts and 7,200 repositories across three phases. The initial compromise came from a flaw in Nx’s own GitHub Actions workflow: a pull request title injection combined with insecure use of pull_request_target, which exposed the npm publishing token. Nx has since adopted npm’s Trusted Publisher model, which hopefully should provide some resistance to this type of attack in the future.

Defenses that fit this pattern

These controls are even more important than ever, but may need small changes to make sure AI attack surface isn’t getting a free pass that attackers can take advantage of.

Reduce what a stolen token can do

Credential-stealer malware only succeeds if it finds a token worth stealing. Prefer short-lived credentials to long-lived ones, scope GitHub and npm tokens to the narrowest permissions that work, and keep personal access tokens off machines that don’t need them. Where you can, publish packages with npm’s Trusted Publisher model instead of stored tokens; other registries may have similar systems. Occasionally test your ability to rotate tokens rapidly, so you aren’t learning how (or debugging your process) during an active incident.

Reduce what runs at install time

The delivery step here is a compromised package. Consider a delay before newly published versions are adopted, which several package managers and registry proxies support. Vet packages before they enter the build. Checkmarx MPP and preventative MPIAPI can help with that.

Constrain AI coding agents

Inventory the AI coding agents on developer machines and in CI; use tools like our own AI Supply Chain Security offering to see what’s in use and confirm it’s adequately controlled. Where you can, run agents in a container or dev container that mounts only the project, with no access to the token and config files in your home directory. Alternatively, use an enterprise AI agent platform or similar system to manage agents centrally.

Detect the exfiltration step

Use your endpoint security tools, monitor logs, and so on. Don’t give AI tools special privileges without also giving them special scrutiny. Splunk’s QuietVault analytic story includes detections that may be a useful starting point for endpoint monitoring.

Conclusion: Put AI coding agents in your threat model

The next time someone describes an AI coding agent on a developer machine as a productivity feature, add a second question: what can it read, and who else can ask it to? An AI coding agent is a process that often is allowed to use your credentials, and a supply-chain compromise can issue it instructions in ways that can be difficult to distinguish from legitimate use.

Shift anti-malware controls closer to developers, make sure your endpoint, network, and other controls can detect and limit malicious behavior, and don’t give AI tools a free pass.