AI Coding Tool Adds a Malicious Dependency: What to Do

Updated 8 November 2026 · Standard formula, shown below

If an AI coding tool adds a dependency that may be malicious or vulnerable, stop using the affected build, preserve the changes and evidence, and verify the package before installing or deploying anything else. Remove or replace it only after you identify what entered the project, whether it ran, and which systems or credentials may have been exposed.

Contain the change without destroying evidence

First, pause the AI tool and any automated job that could repeat the change. Do not run the project, its install scripts, tests, or unfamiliar package commands while you are still assessing the risk. If the dependency is already running in a production environment, follow your organization’s incident-response process; isolation or rollback may be appropriate, but avoid actions that erase useful logs or forensic evidence.

Record the time, tool, prompt or task, changed files, package name, version, and package source. Save the relevant chat, terminal output, and alerts.
Preserve a copy of the working tree and lockfile before editing. Use version control to inspect the diff and identify exactly which files changed.
Tell the project maintainer or security contact. For a company project, involve the security or incident-response team promptly.
If an install or execution may have exposed secrets, revoke or rotate affected credentials from a clean device or trusted environment. Prioritize tokens and keys available to the machine or build job.

A suspicious dependency is not proof that a compromise occurred. Treat the situation seriously, but distinguish confirmed facts from suspicion so that response decisions are proportionate.

Find out what was added and how it arrived

Check the source diff, dependency manifest, and lockfile. The manifest declares requested dependencies; the lockfile usually records resolved versions and may record the registry or source. Compare both with the last trusted revision. Look for additions to direct dependencies as well as changes to transitive dependencies, package-manager configuration, install scripts, build files, and CI workflows.

Confirm the package’s exact identity and provenance. Names can be deceptively similar: a typo, unexpected scope, changed registry, or direct URL can point to a different project than intended. Check the package’s published metadata, maintainers, release history, repository links, and advisory information using trustworthy sources. These clues help, but a familiar name or a clean-looking repository does not establish safety.

Ask how the dependency was introduced. It may be a legitimate library selected for a feature, an unnecessary package invented by the tool, a vulnerable version, or a dependency that was substituted or confused with another package. Also check whether the tool changed versions indirectly through a broad update. The distinction matters: removing one line from a manifest may not undo a lockfile change, and a transitive dependency may need to be fixed through its parent package.

Assess whether it executed or affected anything

Determine whether anyone installed the package, whether lifecycle or build scripts ran, and whether application code imported or invoked it. Package managers and build tools differ in their script behavior and configuration, so inspect the commands and logs actually used rather than assuming installation was passive. Review CI logs, developer-machine history, deployment records, and relevant endpoint or network logs if available.

Consider the access available to the process: environment variables, source code, cloud credentials, signing keys, and access to internal services. A package that was merely added to an uncommitted file presents a different situation from one installed in a privileged build job. If there is evidence of unauthorized access or code execution, handle it as a potential security incident, preserve logs, and follow the organization’s reporting and response procedures.

Do not paste private source code, tokens, or internal logs into a public scanner or an AI assistant to investigate. Share only the information authorized by your organization, and redact secrets before asking for help.

Remove, update, or replace it safely

Once you have a verified remediation, make the smallest controlled change that addresses the problem. If the package is unnecessary, remove it from the manifest and regenerate the lockfile with the project’s established package manager and workflow. If it is needed, update to a version confirmed to contain the fix, or choose a maintained alternative after reviewing its compatibility and provenance. Do not assume that the newest version is automatically safe or suitable.

Make the change on a reviewable branch, not by accepting another unexamined AI-generated patch.
Check that the manifest and lockfile agree and that unrelated dependency changes have not slipped in.
Run the project’s normal tests and dependency or security checks in a controlled environment.
Have a human review the diff, package identity, version, and any scripts or configuration changes.
Deploy or merge according to the project’s release process, and monitor for unexpected behavior.

If exposure is plausible, cleanup is not limited to changing the dependency. Revoke affected credentials, rebuild from a trusted source where appropriate, and investigate whether generated artifacts or releases need to be replaced. Follow incident-response guidance rather than relying on a clean dependency scan as proof that a system is uncompromised.

Prevent repeat additions

AI coding tools can suggest packages based on incomplete context, mistaken assumptions, or plausible-looking but incorrect recommendations. Treat dependency changes as code changes that need review, not as a routine side effect of accepting a feature. Ask the tool to explain why a dependency is needed and to avoid adding one without approval, but enforce that expectation through review and project controls rather than relying on a prompt alone.

Require review for manifest, lockfile, package-source, and CI changes.
Use lockfiles and the project’s normal reproducible-install process; avoid unreviewed version ranges or broad updates.
Limit build and development credentials to the permissions and duration they need.
Use dependency scanning and provenance checks as signals, while recognizing that scanners can miss newly introduced or unknown threats.
Keep package-manager configuration and trusted registries under version control where appropriate, and investigate unexpected source changes.

Pinning a version can make builds more repeatable, but it does not make a malicious version safe. Likewise, a vulnerability alert does not by itself prove that the vulnerable code is reachable in your application. Review severity, affected versions, exploit conditions, and your actual use of the package.

Frequently Asked Questions

Should I delete the dependency immediately?
Stop it from being used, but first preserve the diff, lockfile, logs, and relevant evidence. Then remove or update it through the project’s normal, reviewable process.

What if the package was added but never installed?
Remove or correct the change and check whether automation, teammates, or CI installed it. If it was never executed and had no access to systems or secrets, the risk may be lower, but confirm rather than assume.

Is a vulnerable dependency always an active security breach?
No. A vulnerability is a weakness; whether it creates exposure depends on factors such as version, configuration, reachable code, and execution. A malicious package is a separate concern and may warrant a broader investigation.

Should I rotate all project secrets?
Rotate credentials that the affected process could access if installation or execution may have occurred. Use incident-response guidance to determine scope; indiscriminate rotation can disrupt systems without improving the investigation.

Can an AI coding tool verify that a package is safe?
It can help explain a dependency diff or summarize available information, but it cannot establish safety by assertion. Independently verify package identity, version, source, advisories, and whether it ran.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.