Threat dossier · P1

Slopsquatting and package hallucination

Agents generate and install dependencies autonomously, so a plausible hallucinated name becomes an install intent with no human ever noticing the package did not exist.

Direct answer

What is slopsquatting and package hallucination?

Slopsquatting is the supply-chain attack in which attackers register package names that AI models reliably hallucinate; when an agent writes an import for a package that never existed, the attacker’s registered code installs instead.

Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.

Copied text includes the canonical source and review date.
Reviewed Reviewer: HOL Guard EngineeringReview cadence: 30 days

Representative attack path

Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.

  1. Step 1

    A model hallucinates a convincing but nonexistent package name while writing code.

  2. Step 2

    The agent adds the dependency and runs the package manager install.

  3. Step 3

    An attacker has already registered the hallucinated name.

  4. Step 4

    Install scripts or imported code execute with the developer’s access.

Coverage boundary

What this control can cover

  • Package-manager install intents on supported surfaces can be policy-checked before execution.
  • Unknown or newly registered packages can be routed to review instead of silent install.

What it does not prove or prevent

  • A registry-wide database of hallucinated or malicious package names.
  • Preventing the model from hallucinating dependencies in the first place.

Policy pattern

Policy pattern for slopsquatting and package hallucination

Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.

Use when: Agents generate and install dependencies autonomously, so a plausible hallucinated name becomes an install intent with no human ever noticing the package did not exist.

Decision pattern

  1. Identify the trust boundary and consequential action class.
  2. Apply least privilege and the narrowest supported policy.
  3. Require review for sensitive or ambiguous actions.
  4. Preserve only redacted, versioned evidence needed to reproduce the decision.

Limitations

  • A registry-wide database of hallucinated or malicious package names.
  • Preventing the model from hallucinating dependencies in the first place.

If you suspect prompt injection

  1. Step 1

    Response 1

    Remove the package and audit lockfiles for other suspicious entries.

  2. Step 2

    Response 2

    Rotate credentials accessible during the install window.

  3. Step 3

    Response 3

    Pin known-good versions from verified maintainers.

  4. Step 4

    Response 4

    Rescan and retest the project in isolation.

Sources and mappings

Related dossiers

Neighboring threat classes that share attack paths or trust boundaries with this dossier.