A software supply chain incident can begin well before an application reaches production. A developer may install a dependency to start a project. A package manager may resolve an updated version. An AI coding agent may prepare an environment so it can complete a task. In each case, third-party software can arrive on a developer’s machine before new code has been committed.
The approach brings a security decision closer to the moment a package is installed. It also puts enforcement on the device where a developer or coding agent runs the installation, instead of relying solely on checks later in a repository or build pipeline.
Cycode says Workstation Protection is available in early access. Its announcement does not provide independent effectiveness tests, a complete list of supported operating systems and package ecosystems, or performance figures. Those details will be important to organisations evaluating it. The launch nevertheless addresses a practical question raised by AI-assisted development: how should security policy apply when both people and automated agents can retrieve software?
Why the workstation is an important control point
Many application security programmes focus on source code repositories, build pipelines and deployed applications. Those are essential places to find vulnerable dependencies, exposed credentials and insecure code. They do not capture every action that takes place on a developer’s workstation before a change is committed.
Package installation is particularly significant because it may do more than copy files. Depending on the package and ecosystem, installation can run scripts or make software available to other tools. A development environment may also contain source code, authenticated sessions and credentials used to access services.
That combination makes the workstation relevant to the wider software supply chain. If harmful code runs there, the consequences may extend beyond an unwanted dependency in one project. The precise impact depends on what the code does and what access is available on the affected machine.
AI coding adds another route to the same decision. An agent asked to build a feature may inspect a repository, propose a library and install it. That can be useful, but it also means the agent’s choice of third-party software becomes part of the organisation’s security process.
The issue is not whether AI agents are uniquely likely to choose harmful packages. It is whether an organisation’s rules are applied consistently when either a person or an agent initiates an installation.
“Agents install packages nobody reviewed,” said Seth Robbins, President of Cycode, in the company’s announcement. He described the workstation as the point at which Cycode wants its new control to intervene.
Cycode says Workstation Protection can be distributed through mobile device management and that security teams can manage policies centrally. It also says developers can keep their existing installation workflows. For organisations with centrally managed devices, that offers a potential way to apply policy without depending on each developer to configure each package manager individually. The extent of that coverage remains a matter for product evaluation.
Two checks for different package risks
Cycode describes two principal controls in Workstation Protection. They serve different purposes.
The first is release-age gating, which the company calls a cooldown policy. An organisation can prevent installation of package versions published too recently to meet its chosen threshold. This creates a waiting period during which a problem with a release might be identified before the version is installed on a managed workstation.
A cooldown is a precaution, not a finding that a package is harmful. It can delay a legitimate release. Equally, a version that passes the waiting period is not guaranteed to be safe. Organisations will have to decide how much delay is appropriate for their development work and how urgent exceptions should be reviewed.
Cycode says the policy is enforced on the device, regardless of the package manager version being used or whether a particular local configuration has been applied. Buyers should verify how that works with the operating systems, package managers and installation methods their teams actually use.
The second control checks versions against Cycode’s continually updated threat intelligence feed. According to the company, a version identified as malicious can be blocked regardless of its publication date. That addresses a limitation of release-age gating: a harmful version might be older than the organisation’s cooldown period, or its nature might become known only later.
Together, the checks address a newly published version whose status is uncertain and a version identified as harmful. They do not establish that every harmful package or every possible delivery method will be detected.
The distinction matters in a production setting. Security teams need to know how quickly a newly identified version is added to the feed and reaches devices. Developers need to know whether a block is caused by a release-age policy or an identified threat. Each situation calls for a different response.
What recent incidents show about timing
Cycode’s announcement refers to recent software supply chain incidents to explain why it is extending protection to workstations. These cases illustrate attack methods and response timelines. They do not demonstrate that the new product was used in those incidents or would necessarily have prevented them.
LiteLLM: malicious versions of a widely used library
In March 2026, two backdoored versions of LiteLLM, a Python library used to work with multiple AI model providers, were published after its publishing credentials were compromised, according to Cycode’s investigation. The company identifies versions 1.82.7 and 1.82.8 and describes code designed to harvest credentials, attempt movement within Kubernetes environments and establish persistence.
Cycode cited approximately 95 million monthly downloads for LiteLLM at the time. That figure describes the library’s general reach. It is not a count of downloads of the affected versions or of compromised systems.
The reported publication and response timeline is more directly relevant to the workstation question. In Cycode’s account, the second affected version appeared 13 minutes after the first. A researcher opened an issue 69 minutes after the first publication, and PyPI quarantined the package after 179 minutes. These are milestones from Cycode’s analysis, not a measurement of how many installations occurred during the interval.
LiteLLM: publication to quarantine
Minutes after the first affected version was published on 24 March 2026.
Source: Cycode’s incident analysis. Reported milestones; the chart does not show downloads or affected devices.
The incident explains the interest in a check at installation. Someone retrieving a package during an unfolding response may not yet have the information that later appears in an advisory. Whether a particular cooldown or threat intelligence rule would have blocked a particular installation depends on its configuration, timing and coverage.
The case also illustrates the need to look beyond workstations. Cycode’s analysis discusses development machines and other environments in which an affected version could run. A control deployed to managed developer devices would need to sit alongside security measures for build and deployment systems.
Keyv: a compromised account and multiple delivery paths
An August 2026 incident involving keyv and related cacheable npm packages raises a related issue. Cycode’s investigation reports that an attacker used a compromised maintainer account to publish harmful releases. It expressly identifies the maintainer as a victim and says the initial route into the account remained unconfirmed.
Cycode also reports harmful changes to AI agent and development environment configuration. According to its analysis, opening an affected repository could present a risk even without a new package installation. That finding limits what can reasonably be claimed for a package-installation control: checking an install may address one route, while repository content and tool configuration require their own scrutiny.
Cycode dates the first harmful commit it identified to 09:02 UTC on 4 August 2026. It reports that agent and development environment hooks followed at 09:04, a trojanised keyv version was published at 09:35, releases in the cacheable family began at 10:09, and an affected ecto version was published at 10:28. The chart shows elapsed time from the first reported commit; it does not indicate the number of people or systems affected.
Keyv: from reported commit to package releases
Minutes after the first harmful commit identified by Cycode on 4 August 2026.
Source: Cycode’s keyv and cacheable investigation. Selected reported milestones; the chart does not show infections.
These milestones show how quickly one investigation says harmful changes and releases appeared. They do not establish when every affected user encountered the packages, or whether a specific security product would have recognised and blocked each route.
Shai-Hulud 2.0: credential theft and further publication
In its account of the Shai-Hulud 2.0 npm campaign, Cycode describes software designed to steal secrets and use compromised npm and GitHub tokens to spread through additional packages. Its incident summary estimated that approximately 350 maintainers were affected. Such figures reflect the information available to Cycode at the time of its analysis and should not be read as an assessment of any particular organisation’s exposure.
The case illustrates why the consequences of an installation may extend beyond one workstation. If harmful code obtains credentials with access to repositories or publishing systems, an organisation may have to investigate what those credentials could reach. A pre-installation check can be valuable, but it belongs alongside credential controls, monitoring and a response process for situations in which prevention fails.
AI agents change how package decisions are made
An AI coding assistant that recommends a dependency influences a development project. An agent authorised to install that dependency takes a further step: it can bring third-party software into the environment where it operates.
That does not mean every package selected by an agent is unsafe. It means the organisation needs to understand what an agent is permitted to do, what information it uses to choose software and which checks apply before installation.
Cycode is positioning Workstation Protection within its wider ADLC platform. The company says that platform provides visibility and governance for AI development tools, including coding assistants and Model Context Protocol servers. It also describes guardrails for actions involving prompts and file access, and security checks for generated code.
The potential value of connecting those controls is context. If a package is blocked, a security team may want to know which device, developer and project were involved, and whether an agent initiated the action. Cycode says its Context Intelligence Graph brings signals from different stages of development into one view.
Organisations should assess that claim against their own workflows. A useful view depends on what the platform can actually observe, how accurately it connects events and whether those connections help staff take an appropriate action.
“Security has to start where risk enters the development lifecycle, not after,” said Dor Atias, Cycode’s Co-Founder and Chief Product and Engineering Officer, in the launch announcement. The statement captures the reasoning behind a check at installation. How comprehensively the early-access capability applies that check remains for customers to evaluate.
Security policies have to work for developers
A package block is only useful if the reason is clear and legitimate work can proceed through a controlled process.
A release-age rule will sometimes delay a safe package. That may be manageable for a routine feature but more difficult if a team needs a newly published fix. An organisation therefore needs a way to review urgent requests without making an informal workaround the easiest option.
Developers should also be able to distinguish a policy delay from a known malicious-version block. Waiting for a cooldown period or requesting a reviewed exception might address the first. The second may require a known-good version and an investigation into whether the affected version has already been installed elsewhere.
Agents create another operational test. If an installation fails, an agent might retry, choose a substitute package or use another available command. Security teams evaluating the product should observe those follow-on actions in their own environments and check whether the intended policy continues to apply.
Coverage is equally important. Cycode says the software can be deployed through mobile device management. That may fit centrally managed laptops, but organisations also use contractor devices and remote or temporary development environments. Buyers should establish precisely which of their environments are protected.
What remains to be demonstrated
Because Workstation Protection is in early access, a useful assessment should focus on observable behaviour rather than assume the announcement proves a particular level of effectiveness.
An organisation should establish which operating systems, package ecosystems and installation methods the product supports. It should then test installations initiated by developers and by the AI agents its teams actually use.
It should examine how quickly policy and threat intelligence updates reach devices, and what happens when a device cannot connect to a service. Clear records of attempted and blocked installations would help teams understand the result of a policy decision.
It should also test exceptions and feedback. A developer needs an understandable reason for a block. Security staff need enough information to assess an urgent, legitimate release without removing protection more broadly than necessary.
Finally, an organisation should determine what happens after a block. Can its security team establish whether other devices encountered the same version? Can it distinguish an attempted installation from one that succeeded elsewhere? These questions determine whether the control helps with an investigation as well as prevention.
Where workstation protection fits
The case for checking packages on developer devices is that some risks arise before repository and build checks can run. That makes the workstation a useful place to apply a rule, but it does not make later controls redundant.
Software composition analysis helps identify dependencies used across projects. Repository and build checks examine other stages of development. Credential controls limit access and support a response if credentials may have been exposed. Each addresses a different part of a possible incident.
The keyv investigation demonstrates that distinction particularly well. Cycode describes affected package releases and a route involving agent or development environment configuration. Package-installation protection is relevant to the first route; organisations need to evaluate other measures for the second.
The LiteLLM case similarly raises the question of where a dependency is installed. A workstation policy applies to the devices it covers. Build and other environments still require their own assessment.
The incident charts explain why Cycode has chosen to intervene early. They show reported actions unfolding over minutes and hours. They do not prove that Workstation Protection would have stopped either attack.
The product’s next test is practical: whether it can apply an organisation’s package rules reliably across its developer devices and agent-led workflows, while giving teams enough information to resolve legitimate blocks and investigate harmful ones. If it does, it could help security teams make an important decision before third-party software reaches a developer’s machine.
