HalluSquatting: When AI Agents Install Repos That Do Not Exist

HalluSquatting is a supply-chain attack against AI coding agents. AI coding agents are useful because they turn intent into action. That is also why they are dangerous.

HalluSquatting is a new supply-chain pattern built around a familiar model failure: hallucination. An agent tries to solve a task, invents a plausible package, repository, or tool URL, and then attempts to fetch or execute it. Attackers can pre-register those hallucinated names and wait for automation to arrive.

This is dependency confusion with a new source of confusion: the model itself.

The attack path

The pattern is direct:

• A developer asks an agent to add a library, connect a tool, or install a helper repo.
• The model suggests a package or repository that sounds real but is not.
• The agent, plugin, or developer workflow runs an install command.
• An attacker-controlled project with that hallucinated name executes malicious code.

The dangerous version is not a human reading a bad suggestion. It is a tool-using agent with permission to clone, install, run tests, or execute setup scripts.

Why this is different from ordinary typosquatting

Typosquatting depends on human error. HalluSquatting depends on model behavior.

That matters because the same hallucinated names may appear across many users, models, and agent workflows. If a name is plausible enough to be generated repeatedly, it becomes valuable real estate for attackers.

AI agents also tend to make the workflow feel authoritative. A package name appears inside a confident plan. A repository URL appears beside other correct steps. The install command is wrapped in helpful prose. That lowers skepticism right when skepticism is most needed.

Controls that actually help

Do not rely on "the model should know better." Treat every dependency addition as untrusted until verified.

For developer machines:

• Require human approval before any agent runs npm install, pip install, curl | sh, git clone, or setup scripts.
• Prefer official docs and package registries over model-invented URLs.
• Check repository age, owner, release history, stars, issues, and provenance before installing.
• Disable lifecycle scripts during review when possible.

For CI:

• Pin dependencies and actions.
• Review lockfile diffs like code diffs.
• Block new packages from unapproved registries.
• Fail builds when install scripts appear in newly added dependencies.
• Run security scans on dependency changes before merge.

For agent platforms:

• Log every tool call that fetches code.
• Separate "suggest" from "execute."
• Restrict agents to allowlisted package managers, registries, and repositories.
• Require a signed approval step for new executable dependencies.

What Ship Safe can flag

Ship Safe helps catch the blast-radius pieces around this attack class:

• New dependency and lockfile changes
• Unpinned GitHub Actions
• Dangerous install commands in CI
• Secrets exposed to build or agent contexts
• MCP and agent configs that allow broad filesystem or network access

Run:

npx ship-safe scan
npx ship-safe ci --fail-on high

HalluSquatting is a reminder that agent safety is not only about prompts. It is about whether a generated command can cross from text into execution.

If you are hardening AI-assisted development more broadly, read our related post on MCP security and the Ship Safe docs for local scan setup.

A realistic failure mode

Imagine a developer asks an agent:

Add a GitHub issue summarizer and wire it into our release notes job.

The agent searches its training-shaped memory, decides a package named github-issue-summarizer-js exists, and proposes:

npm install github-issue-summarizer-js

If the package does not exist yet, an attacker can publish it. If the agent is allowed to install and run tests, the install path becomes code execution. If CI has release tokens, the blast radius is no longer the developer laptop.

That is the core pattern: hallucinated dependency, real package, automated execution.

How this differs from dependency confusion

Dependency confusion usually exploits naming overlap between private and public packages. HalluSquatting exploits naming generation.

That means the defensive control cannot be "spell better." The control has to sit at the execution boundary.

Policy examples

For local agent work, a simple rule goes a long way:

Agents may suggest dependencies, but only humans may install new executable packages.

For CI, enforce a stricter version:

# Example policy shape
dependency_changes:
  require_review: true
  block_install_scripts_until_approved: true
  allowed_registries:
    - https://registry.npmjs.org/
  require_lockfile_diff: true

For GitHub Actions, prefer pinned SHAs:

# Risky
- uses: vendor/ai-release-helper@v2

# Safer
- uses: vendor/ai-release-helper@3f4c2d1e9a0b... # reviewed v2.1.0

Questions to ask before accepting an agent's install plan

• Did the agent cite official documentation or invent a package name?
• Is the package old enough to have real usage?
• Is the maintainer connected to the project it claims to support?
• Does the package run install scripts?
• Does it request network access during installation?
• Does the lockfile add unexpected transitive dependencies?
• Will CI expose tokens while this package runs?

This is not about rejecting AI help. It is about keeping generated suggestions away from automatic execution until provenance is clear.

What to log from agent workflows

If your team uses coding agents, keep an audit trail for package-changing actions:

• The prompt that requested the change
• The package or repository name proposed
• The command the agent wanted to run
• Whether a human approved it
• The resulting lockfile diff
• Any lifecycle scripts introduced by the dependency

These logs help in two ways. First, they make review easier. Second, if a malicious package lands, you can answer the incident-response question quickly: where did this name come from?

How to review a suspicious dependency

When a package looks plausible but unfamiliar, check it like this:

1. Search for official documentation that names the package.

2. Compare the package owner to the project owner.

3. Check publish date and version history.

4. Inspect install scripts and postinstall behavior.

5. Read the tarball contents, not only the README.

6. Confirm the package is used by real projects.

7. Run it in a sandbox before letting it near CI secrets.

For npm, a surprising number of attacks hide in lifecycle scripts. For GitHub repos, look for setup scripts that fetch remote payloads or ask for broad tokens.

A safer agent instruction

You can also harden the agent prompt itself:

When adding dependencies, do not invent package names. Use official documentation,
verify the package exists, explain why it is trusted, and wait for approval before
running installation commands.

This is not a complete defense, but it improves the default behavior. Pair it with technical enforcement so the agent cannot install first and explain later.

The product lesson

HalluSquatting is a product-design problem as much as a package-security problem. If your agent UI makes execution feel like the default next step, users will approve too quickly. Better interfaces slow down only the dangerous moments: new package, new repo, new shell command, new credential request.

That is the balance to aim for. Let agents move fast on reading, summarizing, and editing. Add friction when generated text becomes executable trust.

FAQ

What is HalluSquatting?

HalluSquatting is an attack where a model invents a plausible package, repository, or URL, and an attacker registers that hallucinated name so an agent or developer installs malicious code.

Is HalluSquatting the same as dependency confusion?

No. Dependency confusion abuses registry resolution and private package naming. HalluSquatting abuses model-generated names that sound real but may not exist yet.

How do you prevent AI agents from installing malicious packages?

Require approval before install commands, review lockfile diffs, pin trusted actions, block risky lifecycle scripts, and scan dependency changes in CI. For team workflows, start with Ship Safe or compare cloud options on pricing.

Scan dependency changes before merge

Run npx ship-safe ci --fail-on high in pull requests, then use PR Guardian when you want findings and remediation hints beside the code review.

Source

• Tom's Hardware: HalluSquatting attack against agentic AI workflows