What to ask a tool about AI assistants adding dependencies

AI coding assistants can add dependencies faster than a person reviews them, including packages that are outdated, unmaintained or misnamed. Ask a scanner vendor whether it checks at suggestion time, at pull request time and after merge, and how it treats packages that do not exist or have no history.

Why the old process strains

A developer adding a library once paused to look at it. An assistant proposes one in a second, and the change may arrive in a large pull request that nobody reads line by line. The risks are ordinary ones that arrive faster: known vulnerabilities, abandoned projects, licence conflicts, and look-alike package names. See also the pull request review guide for AI-added packages.

Three checkpoints

1. At suggestion time. Can the tool warn the developer or the assistant before the dependency enters the code? This might work through an editor extension or a connection the assistant can query.
2. At pull request time. Does it flag new or changed dependencies as a distinct item, with their advisories and licences, and can it block under your policy?
3. After merge. Does it keep checking, so a package that was clean on Monday and has an advisory on Friday raises an alert?

A tool strong at only one checkpoint leaves a gap.

Questions to ask

• Can your tool check a package name before installation, including whether it exists and how old it is?
• How do you treat very new packages or ones with no download history?
• Can policy express "no new dependency without review" or "only from approved sources"?
• Is there an audit trail showing which dependencies an assistant introduced?
• Can the assistant itself query the tool, for example through a standard protocol, to check before it proposes a package?
• How do you handle what an assistant does in the terminal, such as running install commands?
• What data from our prompts or code leaves our environment?

What to test

Ask an assistant to add a library for a task, and observe whether your candidate tool catches an outdated version. Try a made-up package name and see whether it is flagged as unknown. Try a package with a licence your policy forbids. Record when each check fires: before the edit, at the pull request or later.

Keep human judgement

Tools reduce risk but do not choose well. A team policy still needs to say what a dependency must have: active maintenance, acceptable licence, reasonable size and a clear owner. Review criteria like those in the pre-adoption checklist apply whether a person or an assistant suggested the package.

Where Safeguard fits: it offers SBOM and dependency scanning, policies and gates that apply to pull requests, and an MCP Guardrail, and the free scan shows how findings look on a public repository.

Try it yourself

Click through it at your own pace, or open it full screen.

Watch when the check happens in the conversation and what the assistant does with the result.

Quick check

Last reviewed: 19 October 2026.