AI agents pick, update, and install dependencies on their own. You might review the code they produce, but the packages they pull rarely get the same scrutiny. Agents also let people outside engineering, often called citizen developers, build applications in the same environments your developers use. Their installs cross your trust boundary too.
One unreviewed install is enough. An agent can pull a slopsquatted package, or resolve to a fresh version that carries a self-replicating worm. Shai-Hulud spread this way. It ran its payload through npm postinstall scripts, and later through preinstall scripts.
Securing what agents install takes two steps: find and fix what they’ve already pulled, then set guardrails so every future install starts secure.
If your AI agents have been allowed to pull packages directly from public registries, you might already have risky packages in your environment. The first step toward securing packages AI agents pulled is to identify and track risky packages that already crossed your environment’s trust boundary.
In Cloudsmith, continuous risk detection matches advisories from OSV.dev against every package already in your repository whenever an advisory is published or updated. A match triggers a fresh policy evaluation, and Cloudsmith applies whatever actions your policy defines, such as quarantining or tagging the affected packages. From there, you can remediate by upgrading to a fixed version or removing the package.
Remediation starts with a blast radius analysis. Use client logs to see which tokens, IP addresses, and user agents pulled which package versions. Export the logs before you delete any tokens, because deleted tokens disappear from log entries.
Quarantine malicious and vulnerable packages to mitigate their impact, then invalidate and rotate every credential that’s reachable from any machine, runner, or sandbox that installed a compromised package.
The actual fix may be a patch, upgrade, or roll back. Move to a safe version, then rebuild any artifacts produced while the compromised package was installed.
With the cleanup done, the next step is making sure every new install starts secure by configuring agents to pull packages through your artifact manager.
Agents often run in their own shell, container, or VM. There, they can’t see the .npmrc or pip.conf that points your workstation or CI runner at your private registry. When an agent runs npm install, the package manager goes straight to the public registry and skips your policies entirely.
Close that gap where the agent runs. Sandbox agents by default, and give them access only to the runners and shells they need. When you control the environment, build the registry config into the base layer of the container, devcontainer, or CI runner, and inject a short-lived token issued through OIDC. Then restrict egress (outbound traffic from the agent’s environment) so your private registry is the only package source the agent can reach.
Creating policies at the registry level ensures they apply to all paths that route through the artifact manager, whether a developer or agent wrote the code. Start with a dependency firewall (malware blocking, cooldown, vulnerability and licensing checks) and add policies that align with your organization’s security posture.
For example, a cooldown policy can guard against slopsquatting or install-time attacks by holding newly published packages for a specified period (e.g., 3–7 days). This gives researchers time to identify threats and publish advisories. (Note: a cooldown policy won’t catch a malicious package that ages past your cooldown window.) If your package manager is configured to automatically pull latest, the cooldown policy resolves to the latest compliant version by default.
An agent that approves its own exceptions essentially makes policy optional. Set up a release process for false positives, and put a person at the approval step if possible. When an agent’s request returns a 403, that person reviews the block, raises an allowlist pull request, and approves it. Automation then re-evaluates the policy and releases the package.
AI agents load more than open source packages and dependencies for a project. Other resources may include AI skills, MCP servers, plugins, and IDE extensions from GitHub or other public registries. These resources often enter the development environment without review, but they can inherit the agent’s system access and permissions.
These artifacts and tools deserve the same review and governance that open source packages receive. Governance for this layer of AI-powered development is in its early stages, so teams are primarily limited to restricting the sources agents can access and maintaining an approved list of sources.
AI agents move fast and produce a lot of code, which makes their output challenging to review and secure. Enforce policy at the registry and every agent, workflow, and developer gets the same protections, wherever the code comes from.
Learn more about policy management in Cloudsmith.
