Slopsquatting

Slopsquatting is a supply-chain attack that exploits hallucinated package names suggested by AI systems. An attacker registers the invented name in a public registry and waits for a developer or build pipeline to install it. The risk sits at the intersection of model error, dependency trust, and software delivery speed.

Expanded Definition

Slopsquatting is a supply-chain attack that turns AI-generated dependency hallucinations into executable trust failures. The term applies when an AI assistant, code generator, or agent suggests a package name that looks plausible but does not actually exist, and an attacker later registers that name in a public registry. It differs from ordinary typosquatting because the malicious name is often created by the model, not by a predictable keyboard error.

In NHI and software delivery contexts, slopsquatting matters because build systems, CI/CD jobs, and autonomous agents often have the authority to resolve, download, and install dependencies without a human reviewing every package selection. That makes package identity a control plane issue, not just a developer convenience issue. No single standard governs this yet, but the risk maps cleanly to dependency verification, registry trust, and release pipeline governance described in the NIST Cybersecurity Framework 2.0. It also intersects with the NHI exposure and secret-handling problems documented in Ultimate Guide to NHIs.

The most common misapplication is assuming an AI-suggested package name is merely a harmless draft suggestion, which occurs when teams let agents auto-install dependencies without registry verification or allow-listing.

Examples and Use Cases

Implementing controls against slopsquatting rigorously often introduces review friction, requiring organisations to weigh faster agentic coding against tighter dependency approval and provenance checks.

• A developer asks an assistant to add a library, the model invents a package name, and a threat actor has already published that exact name in a public registry.
• An autonomous coding agent generates a build manifest and a CI job installs the hallucinated dependency automatically because no package allow list exists.
• A prototype application imports a suggested package during testing, then later the same package is pulled into production because the pipeline treats all dependency resolution as trusted.
• A security team reviews build telemetry after a suspicious package download and traces the event to an AI-generated name, then cross-checks package reputation against the guidance in the Ultimate Guide to NHIs and the dependency safeguards implied by NIST Cybersecurity Framework 2.0.
• A software platform lets agents create infrastructure and code changes end to end, but package verification is still manual, so one hallucinated name becomes a real supply-chain foothold.

In practice, the defensive pattern is to require human validation for new dependencies, pin known-good versions, and reject unapproved package names before they ever reach a registry lookup.

Why It Matters in NHI Security

Slopsquatting is a governance problem because it exploits the trust that organisations place in non-human actors to choose software components correctly. When agents, scripts, and build tools can introduce dependencies, the security model must account for hallucination, not just compromise. That is especially important in environments where secrets, service accounts, and deployment tokens already have broad reach. NHI Mgmt Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 92% expose NHIs to third parties, conditions that make a malicious dependency easier to operationalize once it lands in a pipeline.

The lesson is not only about package hygiene; it is about limiting what autonomous systems can do without verification. If an AI tool can create a dependency chain, then identity, provenance, and approval controls must extend to machine-generated actions as well. The Ultimate Guide to NHIs frames why this matters across lifecycle and exposure management, while NIST Cybersecurity Framework 2.0 helps translate the risk into recoverable governance and supply-chain controls.

Organisations typically encounter the consequence only after a build pulls in a malicious package and the incident response team has to trace whether the dependency was human-selected or AI-invented, at which point slopsquatting becomes operationally unavoidable to address.