Verify AI-Suggested Packages Before Installing

Treat an assistant's installation command as a proposed dependency change. Before running it, establish that the package exists, belongs to the project you intended to use and supplies a suitable release for your environment.

Start by asking whether the dependency is necessary. A new package introduces an update and review obligation. If the existing standard library or an approved dependency already handles the task, ask the assistant to show that route as well. Compare the actual implementation and maintenance burden before choosing.

Establish identity from the project's own route

Follow the software project's official installation instructions to its package registry entry. Compare the package name character by character, including scope, punctuation and distribution name. A repository name, import name and registry distribution name may differ; resolve that through the project's documentation rather than assuming an exact match.

Check the repository and documentation links on the registry entry, then confirm that the project points back to that distribution. Review the publisher or maintainer identity, release history and the specific version proposed. A polished description or a familiar-looking name is insufficient evidence of that relationship.

Write down any unresolved mismatch. If you cannot establish why the suggested package is the intended dependency, stop the installation and choose a verified alternative or continue the investigation. Do not let a successful download settle the identity question.

The Codex repository workflow note provides the wider review boundary. Dependency changes deserve an explicit place in that review because they bring external code into the project.

Check what the build will retrieve

Version pinning identifies a release, but the installation record should also establish the artefacts and dependencies used. Review the lockfile or equivalent resolved dependency set in the same change as the application code. Look for added packages and altered transitive dependencies that the assistant's summary did not mention.

For Python, pip's secure installation guidance describes hash checking with --require-hashes. Its requirements include pinned versions and hashes for all dependencies, including transitive ones. --only-binary :all: excludes source distributions where that restriction fits the project's supported packages.

Choose that policy deliberately. Requiring wheels can make an otherwise legitimate dependency unavailable for a particular platform. Resolve the packaging requirement in a controlled build process rather than weakening it automatically when an install fails.

A hash is useful only with an understood origin. Pip distinguishes a locally approved hash from a digest supplied by the same remote index: the latter can detect download corruption without providing an independent assurance against a compromised source. Retain the reviewed artefact identity with the dependency decision.

Read provenance for the claim it makes

PyPI's attestation documentation explains records connecting distribution files and their digests to publisher or build information. npm's provenance documentation similarly connects a package with its source and build context, while stating that provenance does not guarantee an absence of malicious code.

Use those records to answer a specific question: does this release connect to the source and publishing process expected for this project? Compare the reported repository, workflow and revision with the release you intended to adopt.

Keep that finding separate from suitability. A correctly published package can still have an unsuitable licence, unnecessary capabilities, a vulnerability or an abandoned maintenance path. Absence of an attestation also needs context; it is a missing piece of evidence, not by itself a verdict on the package.

Trial the dependency in a disposable environment

Use an isolated development or CI environment with fake inputs and only the credentials needed for the test. Keep production secrets out of the first installation and execution. Package installation and application startup should both be part of the review boundary.

Run the smallest useful check for the feature the package is supposed to provide. Then run the project's existing relevant checks. Inspect generated files and the resolved dependency changes, and review any unexpected network or platform requirements.

Make the result reproducible. Record the runtime, platform, package version, artefact identity and approved configuration. A command copied from a chat without those details is difficult for a colleague to assess or repeat.

Make acceptance and removal ordinary changes

The review should end with a short decision: why the dependency is needed, where its identity was verified, what evidence supports the selected release and which checks were actually performed. Retain unresolved limitations instead of converting them into a claim of safety.

Keep the code change small enough to revert with its dependency update. If the package fails the review, remove the proposed dependency and its generated changes together. Ask the assistant for a replacement only after recording why the first suggestion was unsuitable; otherwise the next suggestion may repeat the same unresolved problem under a different name.

References

• Python Packaging Authority, Secure installs. Accessed 17 October 2026.
• Python Package Index, Digital attestations. Accessed 17 October 2026.
• npm, Generating provenance statements. Accessed 17 October 2026.