Cursor security defaults after Chainguard: a checklist for AI-generated dependencies

Posted on by

Cursor’s Chainguard partnership is a useful signal, but it should not make teams treat AI-generated dependencies as automatically safe. The better takeaway is narrower: AI coding agents are now making package and container choices quickly enough that dependency trust has to move closer to the editor, the agent rules, and the CI pipeline.

Axios framed the partnership as an attempt to reduce the risk that developers pull vulnerable or malicious open-source code into projects while using AI coding tools. Chainguard’s announcement describes a trust layer for open source artifacts, including container images and language libraries built from verifiable sources. Cursor’s own security page points users toward agent security, MCP security, hooks, privacy mode, enterprise controls, and related guardrails. Put together, the message is simple: the editor can help, but your release process still has to verify what the agent added.

This article is a practical checklist for teams using Cursor, not a press-release summary. The important question is not “Does Cursor have a security partner?” The important question is “What happens when an AI agent adds a dependency at 4:58 p.m. and the build still passes?” That is where the grown-up work begins, sadly wearing a badge that says package provenance.

The short version

Treat every new dependency proposed by an AI coding agent as a production change, not as autocomplete. The dependency may be popular, but popularity is not provenance. It may install cleanly, but install success is not safety. It may fix the feature, but a feature fix that adds an abandoned package, a typo-squatted package, or a container image with weak maintenance has simply moved the bug into the supply chain.

The Chainguard and Cursor announcement matters because it acknowledges a real shift. AI agents can select dependencies at a scale and speed that manual review cannot comfortably match. That does not mean humans are out of the loop. It means the loop needs automation, evidence, and default-deny rules for the riskiest package changes.

Your baseline should be boring: lockfiles reviewed, package names checked, versions pinned, provenance preferred, SBOMs generated, vulnerability scans run, license checks included, and production deploys blocked when a new dependency lacks an owner. If that sounds like a lot, yes. The software supply chain heard “move fast” and immediately became a paperwork enthusiast.

What changed after the Chainguard news

The partnership does not magically inspect every line of code your agent writes. It focuses on the artifact layer: where open-source images and libraries come from, whether they are built from verifiable source, whether they are maintained, and whether teams can access safer defaults without changing every developer workflow. That is valuable because dependency risk is often invisible at the moment the code looks finished.

Cursor’s public security page also matters because it makes clear that agent security is not a single toggle. Cursor references developer docs for agent security, LLM safety, cloud-agent network security, hooks, MCP security considerations, privacy mode, compliance logging, and enterprise controls. In other words, the secure workflow is layered. If a team only talks about one vendor integration and ignores rules, logs, review, and CI, the workflow is still soft in the middle.

The practical shift is that dependency review should happen before the pull request becomes normal. If an agent adds npm install something, the review should ask why that package exists, who maintains it, whether the project already has an equivalent utility, whether the package is allowed by policy, and whether the lockfile changed only as expected. A dependency is not just code. It is a tiny long-term relationship with a stranger on the internet. Romantic, in the worst possible way.

The dependency decision table

Agent action Default response Why
Adds a small utility package Ask why standard library or existing helper is not enough AI agents over-import convenience
Adds a package with a similar name to a known library Verify spelling, publisher, repository, and download history Typosquatting risk lives in tiny spelling differences
Adds a package with postinstall scripts Block until reviewed Install-time behavior is a common supply-chain risk
Adds a new container image Prefer trusted, maintained, minimal images Image provenance matters as much as package provenance
Updates many transitive dependencies Require a clean lockfile diff and scan result The blast radius is bigger than the direct package
Adds a security tool by itself Review permissions and output path Even security tools can create data and credential exposure

The most useful row is the small utility package row. AI agents often add dependencies because it is the easiest path to a working example. That is not malicious. It is just optimization for completion. Humans and CI need to optimize for ownership, maintenance, and blast radius.

Checklist before accepting an AI-added dependency

First, check whether the dependency is needed at all. If the package replaces five lines of straightforward code, reject it unless there is a strong reason. The best supply-chain risk is the one you never add. This is not anti-library purism. It is just the old engineering rule that every dependency becomes part of your product’s maintenance surface.

Second, verify the package identity. Look at the exact name, publisher, repository, package manager page, release history, and recent security advisories. Make sure the package is the one the agent intended, not a similarly named trap. Agents can autocomplete a convincing dependency name because convincing is different from correct. Computers continue to be very literal and very annoying.

Third, inspect install behavior. Packages with lifecycle scripts, native builds, binary downloads, or broad network behavior deserve extra review. If the project uses containers, check the base image and tags with the same suspicion. A clean import statement can still pull a messy artifact chain behind it.

Fourth, require a scan at the right layer. Use dependency scanning, secret scanning, static analysis, and container scanning where they belong. Do not ask one scanner to be a priest, doctor, lawyer, and firefighter. A vulnerability scan will not tell you whether the package is architecturally unnecessary. A human review will not reliably catch every known CVE. Split the work.

Fifth, write the rule down. If the team decides that agents may not add new production dependencies without explicit mention in the PR summary, make that a Cursor rule, repo instruction, CI check, or review checklist. If the rule only lives in a senior engineer’s eyebrows during code review, it is not a control. It is facial governance.

Cursor rules that help

A useful Cursor project rule can be plain English. Tell the agent not to add new runtime dependencies without explaining why the existing codebase cannot solve the problem. Tell it to prefer built-in APIs and existing utilities. Tell it to list every package or container image it adds in the final answer. Tell it to stop before adding packages with install scripts, native binaries, or security-sensitive permissions.

The rule should also cover lockfiles. Agents can change a lockfile correctly, but lockfile churn is where reviewers get tired. Ask the agent to keep dependency changes minimal and explain whether the lockfile change comes from one direct dependency or a broader update. When the lockfile diff looks like a novel, somebody should read the plot before release.

For cloud or remote agents, add network rules. Cursor’s security page points to cloud-agent network security as part of its security documentation surface, and the lesson applies broadly: an agent that can fetch arbitrary internet content while modifying dependencies needs a narrower trust boundary. If package installation requires network access, make that access purposeful and logged.

CI gates that should exist

At minimum, a pull request with a new dependency should trigger dependency scanning, license checks, secret scanning, and tests. For production services, container builds should also scan the final image, not just the source manifest. If your build ships a container, the container is the artifact users run. The package manifest is only part of the story.

Add a policy check for new direct dependencies. The check can be simple at first: fail or warn when package.json, pyproject.toml, requirements.txt, go.mod, Cargo.toml, Dockerfiles, or lockfiles change without a PR note. This is not glamorous, but it catches the exact moment when an agent quietly expands the supply chain.

For higher-risk repos, require an owner approval when a new dependency crosses a production boundary. A design system package in a prototype branch is not the same as a payment service dependency. The policy should scale with risk. Otherwise the team either blocks too much and bypasses the policy, or blocks too little and calls it velocity. Both are classic ways to let chaos wear a lanyard.

Human review prompts

Ask four questions in review. What problem did this dependency solve? What existing code or standard library option was rejected? What is the maintenance and security posture of the package? What happens if this package disappears, gets compromised, or changes license terms?

Then ask one product question. Is this dependency on the critical path for users, payments, authentication, data export, or deployment? If yes, slow down. The agent may have produced useful code, but production risk is not decided by whether the demo worked. The demo always looks innocent. That is how demos get you.

Finally, ask the agent to explain the dependency after the fact. A good coding agent should be able to summarize why the package is needed, where it is used, and how to remove it later. If it cannot explain that cleanly, the dependency may be doing more than the team understands.

Related Reading

FAQ

Does the Cursor and Chainguard partnership make AI-generated dependencies safe?

No. It can improve the trust layer around selected artifacts for supported workflows, but teams still need package review, CI scanning, lockfile control, and release gates.

Should AI coding agents be allowed to add packages?

Yes, but only with rules. Require the agent to explain why the package is needed, list every dependency change, and run the relevant tests and scans.

What is the biggest risk with AI-generated dependencies?

The biggest risk is silent expansion of the supply chain. A small feature can add packages, install scripts, transitive dependencies, licenses, and container images that nobody meant to own.

What should a PR reviewer check first?

Start with manifest and lockfile changes. Then check package identity, publisher, version, install scripts, vulnerability status, license, and whether the codebase already had a simpler path.

Is this only a Cursor issue?

No. The same pattern applies to Cursor, Claude Code, Codex, Copilot, and other agentic coding tools. Cursor is the news hook, but dependency governance is the real operating issue.

Sources