Miasma shows why credential-less workloads matter for AI pipelines

At a glance

What this is: This is an independent analysis of the Miasma credential-stealing worm and the way it targets AI coding workflows and cloud credentials.

Why it matters: It matters because IAM and NHI programmes still lose when secrets exist on endpoints, runners, and repos that malware can read before any control can intervene.

By the numbers:

• On June 8, GitHub disabled at least 70 Microsoft repositories after the Miasma worm spread through them.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations.

👉 Read Riptides's analysis of the Miasma credential-stealing worm and NHI exposure

Context

Miasma is credential-stealing malware aimed at the places modern engineering teams now depend on most: AI coding tools, CI runners, source repos, and cloud workloads. The core problem is not just code integrity. It is that credentials still exist as files, environment variables, keyrings, and reusable tokens on systems that malware can inspect before any downstream control matters.

For identity teams, this is an NHI governance problem as much as a supply-chain problem. If service accounts, API keys, cloud tokens, and AI-related access paths remain recoverable on endpoints or build systems, the attacker does not need to break the application layer to reach the cloud control plane. That is why this kind of campaign should be read as a reminder to remove static secrets from the runtime path, not merely to harden repositories.

Key questions

Q: What breaks when malware can read secrets from AI coding environments?

A: When malware can inspect AI coding environments, the normal assumption that secrets stay hidden until a legitimate process uses them no longer holds. Attackers can collect cloud tokens, package credentials, and other reusable access before any downstream control reacts. The result is identity compromise through exposure, not through password cracking or application exploitation.

Q: Why do service accounts and CI runners increase cloud breach risk?

A: Service accounts and CI runners often hold the exact credentials attackers want: deploy tokens, publishing secrets, and cloud access with broad authority. If those credentials are stored on disk or in environment variables, malware can replay them outside the original context. That turns a compromised runner into a launch point for wider cloud access.

Q: How do security teams know whether stolen credentials can be replayed?

A: Teams should ask whether the secret is portable, long-lived, and valid outside the original process, host, or network context. If it is, replay is likely possible. Stronger signals include workload-bound identity, short-lived issuance, and credentials that never appear as files or environment variables on the machine.

Q: Who is accountable when a poisoned repository leads to credential theft?

A: Accountability is shared across repository security, endpoint control, and identity governance, because each layer failed to prevent the attacker from reaching reusable credentials. The practical question is not only who introduced the payload, but why the environment still contained access that malware could harvest and reuse.

Technical breakdown

Why AI coding tools change the credential exposure model

The article describes a dropper that fires when an engineer opens a poisoned repository in tools such as Claude Code, Gemini CLI, Cursor, or VS Code. That matters because the execution moment shifts from build time to interactive development time, where local secrets are often present and the user expects normal tool behaviour. The attacker is not relying on a compiler defect. They are using the AI-assisted development session as the delivery surface for credential collection.

Practical implication: treat AI coding environments as live credential exposure points, not passive editors.

How credential harvesters find reusable access on hosts and runners

Miasma is built to inspect common credential locations such as home-directory config files, cloud CLI profiles, environment variables, and keyring storage. On CI/CD runners, the same pattern applies to deploy credentials, publish tokens, and cloud service principals. The mechanism is simple: the malware looks for secrets that can be replayed elsewhere, then exfiltrates them before defenders notice. If those credentials are long-lived and broadly scoped, a single harvest can unlock cloud access far beyond the original machine.

Practical implication: remove static secrets from developer and runner environments, especially where cloud access is needed.

Why workload-bound identity breaks the replay value of stolen secrets

The article’s central technical claim is that credentials issued just in time and bound to a specific workload are not useful to the malware once stolen. If an identity token never lands in user space, and if it is tied to a workload identity rather than a portable secret, the attacker loses the usual replay path. This is the difference between a secret the malware can copy and an identity assertion that only works in the context for which it was minted.

Practical implication: shift high-value workloads and runners toward federated, workload-bound identity instead of stored credentials.

Threat narrative

Attacker objective: The attacker’s objective is to steal reusable credentials that provide cloud access and downstream operational control.

1. Entry occurs when a malicious repository is opened in an AI coding tool or clone workflow and the embedded payload is triggered.
2. Credential access follows as the malware enumerates local secret locations, environment variables, and runner credentials for cloud and developer access.
3. Impact is reached when harvested secrets are exfiltrated and reused for cloud pivoting, package abuse, or broader repository compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static secrets in AI engineering environments are now an identity liability, not just a hardening problem. Miasma succeeds because the environment still contains secrets that a payload can enumerate and reuse. The control failure is structural: credentials are present where runtime malware can read them, so compromise of the code path becomes compromise of the identity path. Practitioners should read this as a reminder that secret location is itself a governance decision.

AI coding tools collapse the boundary between development activity and credential exposure. The article makes clear that the payload fires when a repository is opened in an AI-assisted editor, not when a package is installed in CI. That means the developer workstation has become part of the attack surface for NHI theft. The implication is that endpoint and identity programmes can no longer be separated when the same session can expose both code and access.

Credential replay resistance: This is the named concept Miasma exposes in practice. A stolen secret only matters if it can be reused from a different context, and the article argues that workload-bound identity breaks that assumption. The field should treat replay resistance as a first-class governance objective for cloud and AI workloads, because credentials that cannot be replayed are far less valuable to steal.

CI/CD runners remain one of the highest-value NHI theft targets because they still concentrate deploy and publishing authority. When a runner carries cloud keys, signing tokens, or package credentials, the attacker does not need persistence on the machine for long. The important point is not that CI is broken in general, but that its identity design often still assumes secrets may live on the host. Practitioners should re-evaluate every runner that can reach production or package registries.

This campaign reinforces the broader assumption that credentials should be discoverable by the process that uses them. That premise was designed for convenience and local control, not for hostile code execution inside modern development and build environments. Once malware can inspect the same runtime that engineers rely on, the governance model has to shift toward identities that are issued per context and leave no portable artefact behind. Practitioners should treat that as a programme design issue, not a point fix.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot see where the most exposed non-human identities actually live.
• For a deeper breach lens, see 52 NHI Breaches Analysis, which helps connect exposed secrets to the real-world incidents that follow.

What this signals

Credential replay resistance: the Miasma pattern shows why the next NHI programme milestone is not merely rotation, but removing portability from credentials altogether. When secrets can be copied from a workstation or runner, the attacker is no longer attacking one system. They are attacking every context that accepts the same token.

The strongest programmes will treat AI coding environments, CI/CD, and cloud workload identity as one governance plane, because the malware path crosses all three. That means identity teams need closer alignment with platform engineering and endpoint teams, especially where operational access is still stored on disk or in environment variables.

With 97% of NHIs carrying excessive privileges, per Ultimate Guide to NHIs, the blast radius of any stolen secret is usually far larger than the system that exposed it. The practical signal is simple: if your secrets can be replayed, your privilege model has already failed.

For practitioners

• Remove static secrets from AI development paths Eliminate cloud keys, package tokens, and database credentials from developer workstations, AI coding tools, and build runners where malware can enumerate files, variables, and keyrings.
• Bind high-value access to workload identity Use federated, workload-bound credentials for CI/CD and production systems so a stolen token cannot be replayed from another host or session.
• Harden AI coding environments as exposure surfaces Treat Claude Code, Gemini CLI, Cursor, VS Code, and similar tools as places where repository content and local secrets can collide, then restrict what credentials are present during interactive sessions.
• Review runner authority against blast radius Map which CI/CD runners can publish packages, reach cloud APIs, or sign artefacts, then reduce standing access where the runner does not need permanent privilege.
• Instrument credential discovery events Alert on access to credential files, environment scraping, and unusual exfiltration from developer or runner processes so collection attempts are visible before reuse begins.

Key takeaways

• Miasma demonstrates that credential theft remains effective wherever secrets still live on endpoints, runners, and in environment variables.
• The scale problem is already visible in NHI research, where most organisations still store secrets outside managed vaults and have limited service-account visibility.
• Reducing replay value by using workload-bound identity is the control shift that matters when AI coding tools and CI/CD become part of the exposure path.

Key terms

• Credential replay: Credential replay is the use of a stolen secret, token, or key from a different system or session than the one it was issued for. In NHI environments, replay risk is highest when credentials are long-lived, portable, and not bound to a workload or runtime context.
• Workload identity: Workload identity is the identity assigned to a machine, service, or automated process so it can authenticate without using a stored secret. It shifts trust from copied credentials to an attestable runtime context, which is especially important for CI/CD, cloud services, and AI-enabled workloads.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code repositories, build systems, endpoints, config files, and environment variables. It creates more places for malware to discover reusable access and makes remediation harder because teams often do not know where every secret is stored.
• Standing privilege: Standing privilege is access that remains continuously available instead of being issued only when needed. In NHI governance, standing privilege increases breach impact because any stolen secret or compromised account can be used immediately, often without a second approval or just-in-time control.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Miasma Hit Microsoft. It Came for Credentials. Riptides Has None. Read the original.