Last reviewed: July 29, 2026

Direct answer

Treat every dependency name proposed by a coding agent as untrusted input. Put a dependency admission gate outside the agent’s control, and prevent the package manager from resolving or installing a new package until that gate returns an explicit allow decision. The agent may propose an import, manifest edit, or dependency request, but it must not approve its own proposal or execute package code.

The gate should verify the ecosystem, exact registry, package existence, publisher identity, registration history, requested version, allowlist status, and expected project relationship. After identity approval, resolve the dependency in an isolated environment, generate or verify the lockfile, check integrity data, run dependency review, and retain a concise decision record. Missing, conflicting, or unavailable evidence must produce a deny or human-review outcome, never an automatic install.

This is not a theoretical edge case. A USENIX Security study of package hallucinations evaluated 16 code-generating models across Python and JavaScript. It reported average hallucinated-package percentages of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique hallucinated names in its analysis. The Cloud Security Alliance guidance on slopsquatting therefore recommends registry and publisher checks, an allowlist or human gate, committed lockfiles, integrity verification, and software bills of materials for AI-assisted projects.

Who this is for

This guide is for developers, repository maintainers, platform engineers, and security teams that allow coding agents to edit dependency manifests, generate import statements, or invoke package-management tools. It applies whether the agent runs on a workstation, in an isolated runner, or inside CI.

It is especially relevant when an agent can reach public registries or work in an environment containing valuable repository or deployment access. In that setting, a plausible package name is not harmless text: an installation can execute package-controlled code before a pull request receives human review.

Key takeaways

  • Model confidence is not package evidence. Verify the proposed name independently against the intended registry.
  • Separate proposal, approval, and execution. The agent that suggests a dependency should not control the admission policy.
  • Scope allowlist entries by ecosystem, package, permitted source, and version policy. A matching name in another registry is not a match.
  • Registry existence is necessary but insufficient. Review publisher identity, registration timing, project relationship, and requested version before approval.
  • A lockfile preserves an approved resolution; it does not prove the original package choice was legitimate.
  • Run dependency review before merge, but keep a separate pre-install gate because review after execution is too late to prevent package scripts from running.
  • Fail closed when registry metadata, integrity evidence, or policy data is unavailable.
  • Log the decision and reason without copying environment data, complete process output, or authentication material into the record.

Sources checked

Contract details to verify

A dependency gate is an enforceable contract, not a sentence in an agent prompt. The control must cover every route by which the agent can introduce or execute a dependency: manifest edits, lockfile edits, generated setup scripts, direct package-manager calls, shell commands, and delegated tools.

Required admission inputs

For each proposed dependency, collect these normalized inputs before any installation:

  • Repository and agent run identifier.
  • Ecosystem and exact registry selected by repository policy.
  • Exact package name and requested version or version range.
  • Dependency class, such as runtime, development, optional, or build-only.
  • Manifest path and the diff that introduced the request.
  • Current allowlist and policy version.
  • Registry result, publisher result, registration-age result, and project-relationship evidence.
  • Expected lockfile and integrity behavior after approval.

The gate should return one of three outcomes: allow, deny, or human review. Allow means all required evidence matches policy. Deny means the proposal violates policy or presents a clear mismatch. Human review means a legitimate new dependency may be appropriate but has not yet been approved. Only allow may release the installation step.

Happy-path operator workflow

  1. The agent proposes a dependency by changing code or a manifest. The execution layer intercepts the change before a package manager reaches the network.
  2. The gate derives the ecosystem, registry, exact package name, requested version, manifest location, and dependency class from the proposal.
  3. It checks an allowlist scoped to that ecosystem and source. An existing approval for a similarly named package or another registry does not qualify.
  4. It performs read-only registry checks. The exact name must exist in the intended registry, the publisher must match the approved identity, and unexpected registration recency must be reviewed.
  5. For a new direct dependency, a maintainer checks why it is needed, whether the project relationship is credible, and whether an existing approved dependency or standard-library feature can meet the requirement.
  6. After approval, a clean runner resolves the permitted version. Package code remains unable to affect the main agent environment before admission.
  7. The runner creates or verifies the lockfile and integrity data. CI then checks the dependency diff, expected transitive changes, vulnerability findings, license policy, and the software bill of materials where required.
  8. The change proceeds only when the manifest, lockfile, integrity result, dependency review, and approval record agree.

A concrete happy path is an agent requesting an already approved package at a permitted version from the expected registry. Its publisher and registry history match the stored policy, isolated resolution produces the expected lockfile change, integrity verification passes, and dependency review reports no blocking finding. The gate records allow and releases the controlled installation step.

Error-path operator workflow

  1. The agent proposes a package that is absent, appears only in a different ecosystem, has an unexpected publisher, is newly registered without an accepted explanation, or cannot be verified because metadata is unavailable.
  2. The gate records deny or human review before invoking installation. It does not ask the same agent to decide whether its own package suggestion is trustworthy.
  3. Networked resolution and package scripts remain blocked. The proposed diff is preserved so the maintainer can inspect the original name and context.
  4. The maintainer chooses an established package, requests an implementation without a new dependency, or performs a documented exception review.
  5. Any retry starts as a new proposal and passes through the complete gate. Changing the manifest, using a shell command, or calling a delegated tool cannot bypass the decision.

This error path matters because a package can become attacker-controlled under a plausible hallucinated name. A registry response of found is therefore not an automatic recovery from an earlier not-found result.

Sanitized decision logging

A useful record proves what the gate checked and why it decided, without becoming a copy of the execution environment. For example:

event: dependency_admission
run_id: run-042
repository: sample-app
ecosystem: python
package_name: '[REDACTED]'
requested_version: 4.2.0
policy_version: 7
registry_result: found
publisher_check: match
registration_check: established
allowlist_result: approved
lockfile_change: expected
integrity_check: pass
dependency_review: pass
decision: allow
reason_code: existing_approved_package
reviewer_role: maintainer
recorded_at: 2026-07-29T14:00:00Z

Keep only normalized fields needed for review, incident response, and policy improvement. Do not persist complete registry responses, process environments, shell history, home-directory paths, or authentication material. If private package names are sensitive, redact them in broad telemetry and keep the full identity only in the access-controlled approval record.

Pair this gate with guidance to set safe permission and secret boundaries for coding agents . Before merge, use reviewable diff guidance so reviewers can isolate manifest, lockfile, policy, and generated-code changes.

Failure modes

Installation happens before review

A pull-request check cannot undo code that already ran during dependency resolution. The pre-install admission decision must occur before the agent can invoke any package-manager path.

Registry existence is treated as proof

Attackers can register plausible names. A found result must still be paired with the intended ecosystem, publisher identity, registration history, project relationship, and version policy. The Cloud Security Alliance source documents how plausible AI-generated names can propagate into repositories and accumulate downloads.

The right name is checked in the wrong ecosystem

A name may exist in one registry while being inappropriate in another. Normalize the ecosystem first and bind every allowlist entry to its exact source.

The allowlist is too broad

Name-only entries, loose patterns, and organization-wide wildcards can approve an unintended package. Store the exact normalized identity and define how versions, publishers, and registry sources may change.

The lockfile becomes the first control

A lockfile can faithfully preserve a bad initial decision. Approve package identity first; generate and verify the lockfile only afterward.

Registry or policy outages fail open

If metadata, the allowlist, or integrity evidence cannot be retrieved, an automatic install converts missing evidence into execution permission. Queue the proposal or route it to a maintainer instead.

An alternate execution route bypasses the gate

Blocking one command is insufficient if the agent can modify a setup script, call another tool, or directly edit a lockfile. Apply the same admission decision at the execution boundary and validate resulting manifest and lockfile diffs in CI.

Dependency review is buried in unrelated changes

Large generated diffs make a one-line package addition easy to miss. Separate dependency changes, explain their purpose, and require explicit approval for the manifest and lockfile surfaces.

Logs are either empty or excessive

A record without a decision reason cannot support review. A raw dump can expose unrelated operational data. Use normalized fields, stable reason codes, and redaction appropriate to repository sensitivity.

FAQ

Is registry existence enough to approve a package?

No. Existence only proves that a name is currently registered. It does not establish that the package is the one the agent intended, that it belongs to the expected publisher, or that its registration history is credible. Check all of those properties before execution.

Does committing a lockfile solve package hallucination?

No. A lockfile helps reproduce and verify an approved dependency tree, but it can also preserve a malicious or mistaken first choice. Identity approval must come first. Lockfile and integrity checks then protect later resolutions from unexplained drift.

Can a better model replace the dependency gate?

No. The BOUND package-hallucination research reported a 79.9% reduction on edit prompts and a 65.4% reduction on unseen package-recommendation prompts, plus reductions in code generation and installation recommendations. Those are meaningful improvements, but they are not elimination. An external admission control remains necessary.

Where does dependency review fit?

Dependency review is a pre-merge control that makes newly introduced dependencies and relevant vulnerability or license findings visible to reviewers. Use it after the pre-install identity gate and again when reviewing the final manifest and lockfile diff. It complements the execution boundary rather than replacing it.

What should happen when the registry is unavailable?

Return deny or human review, preserve the proposal, and retry verification later. Do not let an agent reinterpret missing metadata as approval, and do not install from an alternate registry unless repository policy explicitly permits that source.

Must an operator reapprove every existing dependency?

Not if the exact ecosystem, registry, package identity, publisher, and version policy already have a valid approval. Reopen review when the source, publisher, permitted version range, integrity result, or policy changes, or when the agent introduces a previously unseen direct dependency.

What should the audit record prove?

It should show the proposal identity, policy version, checks performed, decision, reason, reviewer role where applicable, and time. It should also show that installation was not released before approval. It does not need raw environment data or complete command output.

Reader next step

Start with one repository and place its package-manager execution behind a default-deny wrapper. Seed a narrowly scoped allowlist from dependencies that maintainers have already approved, then test five cases: an allowed package, a nonexistent name, an existing but unapproved name, unavailable registry metadata, and an attempted alternate execution route.

The first case should reach isolated resolution and dependency review. The other four should stop before package code runs, produce a sanitized reason record, and preserve the proposal for a maintainer. Require the manifest, lockfile, integrity result, and admission decision in the pull request. Once those tests pass, extend the same contract to every ecosystem and delegated tool the coding agent can reach.