CRM Costs CRM pricing, add-ons, and support staffing calculators

Agent dependency blast radius

Tensorlake's npm Worm Made AI Agent Dependency Control a Support Gate

The malicious 0.5.144 release was short-lived, but the buyer lesson is durable: AI-agent sandboxes do not protect the workstation, CI runner or app server that installs a poisoned SDK.

Open cost calculator Plan cleanup and agents
Synthetic representative editorial scene of an unbranded support security desk reviewing AI-agent dependency exposure; not Tensorlake staff, Socket staff or an actual compromised host.
Editorial image: synthetic representative support-ops scene, not a photo of the named company or news event.

Direct answer

Tensorlake npm SDK 0.5.144 Shai-Hulud AI agent supply chain compromise: what CRM buyers should take from it

Socket reported on October 8 that tensorlake@0.5.144, the npm SDK for Tensorlake's AI agent infrastructure, shipped credential-stealing ChainDrop/Shai-Hulud malware through a preinstall hook. SafeDep, StepSecurity and The Register independently described the same malicious release, with Socket saying it flagged the package about 11 minutes after publication. The practical buyer issue is not whether every support stack used Tensorlake. It is that an AI-agent SDK can execute during installation on a developer laptop, CI runner or application server before any sandboxed agent code runs. Support and CRM teams should map where the package appeared, whether install scripts ran, which secrets were reachable, whether the worm could spread, and what clean-host recovery evidence exists.

Published 10/10/2026. News event: 10/8/2026.

What happened

  • Socket said Tensorlake npm SDK version 0.5.144 was published on October 8 with a preinstall hook that launched an obfuscated loader and worm payload.
  • SafeDep reported that npm removed the version and that maintainers reverted the source and released 0.5.145 after the malicious build.
  • StepSecurity said the malicious release was built from the project's own main branch and carried npm provenance, underscoring that provenance shows where code was built, not that the source was safe.
  • The Register summarized the incident as a Shai-Hulud-family compromise of AI agent infrastructure, while noting that confirmed impact from the malicious version remained unknown.

Why this is trending

  • AI-agent tooling is moving into support automation, CRM cleanup, ticket routing and back-office workflows, so dependency compromise can become customer-data exposure.
  • The incident reached an SDK used to create and manage isolated AI-agent environments, but the risky execution path was the ordinary package-install step outside the sandbox.
  • The valid-build-provenance detail turns the story from a simple malware alert into a buyer-control question about release trust, install scripts and secret scope.

The CRM Costs take

An illustrative support team may ask a developer or vendor to connect an AI agent to helpdesk tickets, CRM objects, cloud logs or workflow tools. If the SDK install runs on a workstation or build runner with support credentials, the exposure is not limited to the agent sandbox. Buyers need a dependency blast-radius record that separates package presence from script execution, names the hosts involved, lists reachable tokens, confirms whether repositories or packages changed, and documents which environments were rebuilt before access was restored. This framework is a security planning aid, not a finding that any particular buyer installed the malicious release.

AI Agent Dependency Blast Radius Map

An original support-operations map for package exposure, install scripts, host scope, secret reach, spread checks and recovery evidence.

AI Agent Dependency Blast Radius Map framework visual
Cost layer
Buyer question
Risk signal and next step
Package path
Where did tensorlake, related AI-agent SDKs or floating npm ranges appear in manifests, lockfiles, build logs and deployed artifacts?
A dependency can be present indirectly or pulled by a floating range without a support owner noticing.

Search source repos, lockfiles, package caches, build artifacts and vendor delivery notes for affected package names and versions.

Install scripts
Which environments allowed npm lifecycle scripts to run during install, build, test or local development?
The compromise executed through a preinstall hook, so import-time sandboxing would not stop installer-side code.

Record whether scripts were enabled, who ran the install, and which hosts need forensic or rebuild treatment.

Host scope
Was installation limited to an isolated test host, or did it run on a developer laptop, CI runner, support app server or deployment machine?
A host with CRM, helpdesk, cloud or deployment access can turn a package incident into a support-data incident.

Classify each host by reachable systems, network access, cached credentials, mounted secrets and support workflow permissions.

Secret reach
Which GitHub, npm, cloud, Vault, Kubernetes, SSH, AI-tool and CRM integration tokens could the installing process read?
Valid tokens can make malicious actions look like normal automation or a trusted support workflow.

Remove any persistence first where applicable, then rotate reachable credentials in a tracked order with account-activity review.

Spread checks
Did the incident create unexpected repository files, workflows, package publications, public repos or support automation changes?
Self-propagating package malware can move from one install host into source control or downstream packages.

Audit commits, workflow files, package versions, repo visibility, package-publish logs and support automation diffs.

Recovery evidence
Can the team prove affected hosts were isolated, rebuilt or cleaned before support access and deployment secrets were restored?
Deleting a dependency alone may leave persistence, stolen credentials or unexplained workflow changes behind.

Keep rebuild records, isolation times, credential-rotation receipts, log-review notes, restored access approvals and customer-impact decisions.

What buyers should do next

Step 1 Search package manifests, lockfiles, build logs and artifact inventories for tensorlake@0.5.144 and related AI-agent dependency changes.
Step 2 Identify every host where package install scripts could have run, including developer machines, CI runners, app servers and vendor build environments.
Step 3 Map the support systems, CRM integrations, cloud accounts and deployment credentials reachable from each exposed host.
Step 4 Follow incident guidance before revoking tokens when persistence is suspected, then rotate reachable secrets and review account activity.
Step 5 Retain a recovery packet with host isolation, rebuild or cleanup evidence, credential rotation, repository/package audit results and customer-impact decisions.

Buyer FAQs

Does this mean every Tensorlake user was compromised?

No. The public reporting identifies a malicious release and describes what the payload was designed to do. Buyers should verify whether the affected version was installed and whether the install script actually ran in their environment.

Why does this matter to support and CRM teams?

Support and CRM teams often give agent workflows access to tickets, customer records, cloud logs and deployment tools. A poisoned SDK install can expose those credentials before the agent workflow itself is reviewed.

Is npm provenance enough to trust an AI-agent package?

No. Provenance can show that a package came from a particular workflow or source revision. It does not prove that the source revision was safe or that a maintainer account was uncompromised.

Should teams immediately revoke every token?

Teams should follow current incident guidance. Socket and StepSecurity described persistence behavior tied to token revocation, so affected hosts should be investigated and persistence removed where applicable before rotation.