Behavioral Risk Brief: MemTensor Packages
The Claim
Governance frameworks that treat an established package’s publishing history as ongoing proof of safety create systemic risk when that same history can be leveraged to distribute a payload that activates automatically at runtime. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does when specific events occur, rather than trusting a package indefinitely once it has been adopted.
The Incident
Unknown threat actors compromised two legitimate, established packages, one on npm and one on PyPI, both used to connect an AI memory service to development and agent tooling and republished them with a hidden Go-based implant called sckit, built to run on Windows, Linux, and macOS. Rather than executing once at install, the malicious code was designed to launch when the tool’s own gateway starts up, and again each time the plugin handles a memory-recall action, passing the user’s own prompt text directly to the malicious executable in the process. The PyPI version instead launches as soon as it’s imported into a project. Beyond credential
theft, the implant shows worm-like behavior, capable of spreading itself further by publishing additional malicious packages and workflow files across GitHub, npm, and PyPI on its own, extending the compromise without requiring any new installation decision from developers
The Governance Failure
The governance failure is not that a package compromise occurred, but that trust in these packages was extended based on their established, legitimate history, with no mechanism evaluating what a specific version does at the exact moments it actually runs. A package adopted once for its stated function is treated as safe going forward, even when new versions introduce behavior tied to events like startup or memory recall, actions that happen repeatedly during normal, ordinary use.
This is compounded by how the payload’s activation is tied to routine operation rather than installation. The malicious code does not simply execute once and finish, it launches at startup and again every time a user submits a prompt that triggers recall. This means the compromise persists and re-activates throughout the tool’s normal lifecycle rather than during a single, reviewable moment.
The underlying breakdown is the absence of a trust decision that evaluates behavior at each of these runtime triggers independently, rather than assuming a package’s function remains constant because its stated purpose hasn’t changed. Worm-like self-propagation through direct publishing compounds this further, extending the compromise into other packages without any new installation decision being made by an affected developer at all.
The Regulatory and Business Exposure
- Credential theft from developer machines and CI jobs, triggered by ordinary, repeated use of a memory integration tool.
- User prompt text passed directly to a malicious executable during a routine recall action.
- Self-propagating spread through direct package publishing, extending compromise without new developer installation decisions.
What Your Auditors Will Ask
- How do you validate what a package does at runtime events like startup or recall, not only at install?
- What controls detect a payload that activates repeatedly during ordinary, expected tool operation?
- How do you account for self-propagating compromise spreading through direct publishing rather than dependency installation?
- What evidence do you maintain that packages performing sensitive data operations, like passing prompt text, were evaluated at that point?
- How do you verify that a package’s established, legitimate history is not the sole basis for trusting new versions?
A consistent signal is that a tool behaving as expected on the surface doesn’t say anything about what triggers during that same expected use.
Zero Trust for Code Value
Zero Trust for Code introduces a trust decision at the point a package’s code actually executes, evaluating behavior at each runtime trigger, startup, or recall, rather than assuming a package remains safe because its stated function hasn’t changed. This means execution is assessed at the moments it actually occurs, not inferred from the package’s history or adoption decision.
This directly addresses the governance weakness this incident exposes: the assumption that an established, legitimate package requires no further evaluation once adopted. By requiring a pre-execution trust decision at each runtime event, organizations can catch behavior tied to ordinary, repeated use, exactly where this payload was designed to activate.
The result is a governance model where trust is evaluated at every runtime trigger a package exposes, closing the space this compromise relied on when it tied malicious execution to routine, expected operation rather than a single installation moment.
Governance Action Brief
- Establish governance controls that evaluate package behavior at runtime triggers, not only at installation.
- Require a pre-execution trust decision for actions tied to routine tool operation, such as startup or recall events.
- Treat an established package’s legitimate history as insufficient evidence for trusting new version behavior.
- Monitor for self-propagating compromise spreading through direct package publishing across ecosystems.
- Maintain a record of runtime behavior evaluated per trigger event, separate from a package’s adoption history.
Sources
Analysis based on The Hacker News (September 23, 2026) reporting on findings from Aikido, SafeDep, Socket, and StepSecurity on the compromised MemTensor packages, CodeHunter Labs evaluation of runtime-trigger execution trust, and alignment with NIST 800-53 and NIST SSDF
