In this article
Last updated September 18, 2026
3 min read
A package recommendation looks like a small part of generated code.
It crosses a large trust boundary.
The name may not exist. It may be close to a trusted package. It may have been registered by an attacker. It may exist,
resolve successfully, and still be abandoned, vulnerable, incompatible, or unnecessary.
A language model’s confidence cannot answer those questions.
What the USENIX study found
Researchers presenting at USENIX Security 2025 generated 576,000 code samples across 16 models in Python and
JavaScript.
In that benchmark, the average percentage of hallucinated packages was at least 5.2% for commercial models and 21.7%
for open-source models. The study also examined repeated hallucinated names and mitigation strategies.
These figures belong to the evaluated model snapshots, prompts, languages, and method. They are not a production
incident rate and should not be generalised to every coding assistant request.
The study establishes a practical threat: plausible nonexistent package names occur, and repeated names can create an
opportunity for supply-chain abuse.
Existence is only the first check
A registry lookup can show whether the exact package currently exists.
It cannot show whether the package is the one the team intended.
Use a dependency evidence chain:
Identity
- Exact registry and package name.
- Namespace or organisation.
- Publisher identity where available.
- Similar names and typosquatting risk.
History
- Release history and age.
- Maintainer changes.
- Repository activity.
- Sudden ownership or packaging changes.
Security
- Known advisories.
- Integrity and lockfile data.
- Install scripts and suspicious behaviour.
- Dependency tree and transitive risk.
Project policy
- Licence compatibility.
- Supported runtime and framework versions.
- Maintenance expectations.
- Approved registries and sources.
Necessity
- Why the dependency is needed.
- Whether an existing project dependency already provides the capability.
- Whether a small local implementation is clearer and safer.
Do not trust a green install
Successful installation proves that the registry served a package under that name.
It does not prove legitimacy.
An attacker can register a hallucinated or typo-like name, create a convincing repository, and publish documentation.
A simple allow-list also has limits if the allow-list accepts the wrong package after registration.
Dependency checks need provenance and policy, not only existence.
Put the decision in the workflow
When generated code adds or changes a dependency:
- Detect the manifest and lockfile change.
- Query the correct registry.
- Collect provenance, history, advisory, and licence evidence.
- Compare with existing dependencies and project policy.
- Route high-risk or ambiguous cases to a human owner.
- Record the decision and evidence.
- Re-run build, tests, security, and documentation checks.
This should happen before the dependency becomes normal context for future agents.
Keep the claim boundary honest
A workflow can reduce risk and make evidence visible.
It cannot guarantee that a dependency is safe. Registries can be compromised, advisories can arrive later, maintainers
can change, and a legitimate package can contain a defect.
Record verification time and revalidation triggers.
How paqad-ai fits
paqad-ai’s current public documentation describes dependency advisory triage and security workflow steps alongside
planning, checks, decisions, and an audit record.
The useful product position is not “AI will never hallucinate a package.”
It is that dependency decisions should pass through a team-owned evidence process instead of relying on the model that
suggested the name.
The model can propose.
The registry, repository, policy, checks, and human owner determine whether the proposal belongs in the system.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- USENIX Security 2025, package-hallucination study.
- USENIX overview of package-hallucination risk.
- Eliyce/paqad-ai, first-party security-workflow description.