“One package was compromised” sounds like a bounded incident. On a developer workstation, that package may run beside cloud profiles, repository tokens, an SSH agent, model-provider keys, and release credentials.
The package is the entry point. The identities available to its process determine how far the incident can travel.
Draw the connections before counting machines
The Shai-Hulud campaign involved malicious npm releases, install-time execution, credential theft, and propagation through development and CI access.
The elementary-data compromise targeted data-engineering environments containing warehouse profiles, cloud credentials, API keys, SSH material, and other secrets.
Agent workflows can bring additional integrations into those environments. The following diagram models potential reach after a malicious install; it is an exposure model, not a claim that every incident used every branch.
Trace each identity to a business action
| Identity available to the process | Follow-on action to investigate |
|---|---|
| Source-control token | Repository changes, added keys, workflow edits |
| Package publishing token | New releases and changed package ownership |
| Cloud profile or workload token | Resource access and newly issued credentials |
| MCP or SaaS credential | Reads, writes, messages, and exports in that service |
| Model-provider key | Unauthorized use and the data submitted through it |
An incident inventory should distinguish “credential was accessible,” “credential was copied,” and “credential was used.” Those are different levels of evidence. Unknown use still needs a response when the secret was plausibly exposed.
Change where the keys meet
Separate dependency installation, untrusted analysis, signing, and publication. Avoid attaching release credentials to a general agent workstation just because an occasional task needs them.
Short-lived credentials reduce the useful lifetime of theft. They do not make a currently compromised runner safe. Issue them only to the phase that needs them, with the narrowest practical scope.
Protect release environments, review workflow changes, and validate provenance for the artifacts that leave the build. A clean package reinstall does not prove the release built during the incident is trustworthy.
Recovery follows the graph
Contain the affected hosts and jobs. Establish a clean administrative path. Revoke or rotate the identities reachable from the compromised environment, then investigate the actions those identities could authorize.
For dependencies between secrets, use the rotation sequence. The right scope is every reachable trust relationship, even when the first alert names only one package.